I recommend that maplibre-gl includes a complete and robust expression API that enables style designers to manipulate tile attributes programmatically, in accordance with the original language vision. This feature would give style designers the flexibility to determine which processing should occur on the tile generation side and which should take place in the user's web browser. A powerful expression language would be a significant capability differentiator that would influence a style implementer to select maplibre-gl over mapbox-gl. A strong expression language is vital for the sustainable growth of vector tile-based maps, as it enables new use cases. For instance, a community organization can host a vector tile server with a centralized schema, with [OpenMapTiles](https://openmaptiles.org/) being a leading candidate. Hosting a vector server has been a long-standing vision within the OpenStreetMap project. More recently, the Operations Working Group of the OpenStreetMap Foundation has been investigating the hosting of a vector tile server (https://github.com/openstreetmap/operations/issues/565). The aim is to facilitate community-driven style development providing a tile server with a standard schema that anyone can use. If maplibre-gl incorporates a complete and robust expression language, it will empower such centrally-hosted tile servers to support multiple styles with different requirements without needing to customize the delivered tiles. Maintainability is a concern when expanding the style specification. However, testing individual style expressions is straightforward since they usually map to single functions in the implementing language. Thus, expressions are easier to maintain compared to other parts of the codebase. A robust expression language has been a priority for mapbox-gl well before the maplibre fork. Unless there is a compelling reason to change course, we should follow the consensus established by the community when mapbox-gl was still an open project. The following tickets provide evidence of the pre-fork community support for a robust expression language, as well as the ongoing customer demand for it: * https://github.com/mapbox/mapbox-gl-js/issues/6484 * https://github.com/mapbox/mapbox-gl-native/issues/11786 * https://github.com/mapbox/mapbox-gl-js/issues/5853 * https://github.com/mapbox/mapbox-gl-js/issues/6155 * https://github.com/mapbox/mapbox-gl-js/issues/5676 * https://github.com/mapbox/mapbox-gl-js/issues/4100 * https://github.com/mapbox/mapbox-gl-js/issues/6062 While we should have a constructive debate about including individual expressions, it's crucial that maplibre-gl's broadly-stated strategic goal is to enable expression logic on the client side. This will provide style developers with a wider range of options when deciding where to implement different aspects of cartographic decision-making in their technology stack. Let's engage in a healthy discussion on this matter.