1) Some of the most popular map library frontends like Leaflet support only raster tile layers out of the box.
2) Quality vector generalization (feature-dropping) is much more difficult than raster generalization.
3) A large fraction of use cases just need a "good enough" basemap without those extra features.
I at least would find it interesting to see the two compared by someone other than me ;).
https://github.com/protomaps/protomaps.js
TBH, the blocker is not demand for vector rendering but the technical difficulty and performance constraints of doing rasterization in the browser.
Do you think it's still too early to switch to vector map data for all clients then? Maybe render raster tiles on demand on the server to those clients that can't handle it?
There are a couple great public raster services like osm.org's default style and http://maps.stamen.com. These are 100% free to use, so they get used everywhere, but incur significant expense to the organizations running (paying) for them.
There aren't equivalent solutions in vector-land yet... I wrote a bit about this previously: https://protomaps.com/blog/free-tier-maps
Their stack is open sorce, described there: https://github.com/Qwant/qwantmaps#tile-server
[1]: https://github.com/SpatialServer/Leaflet.MapboxVectorTile
So lets optimize the browsers SVG rendering?
I maintain a heavily used map of the US, and I found that storing data/serving in vector format seems to be the most efficient (on AWS s3 / DO spaces), and converting to raster in the browser or with a service call / lambda really opens the doors to a lot more use cases. I suspect parent can talk more about this than I can.
Things that are mandatory for map display, like:
- Label priority and positioning
- Display of internationalized, RTL, and Bidi text
- Geometry rasterization and styling
Are outside the scope of Leaflet's core design and can be implemented by plugins, one of which I have linked in a sibling comment.