[wiredfool]

Partially because they're completely different stacks -- the client side is WebGL + Javascript, and the server side is whatever they've been doing for 15 years.

They're probably missing a raqm/freebidi or something in the stack on the client side.

[lxgr]

Ah, so the input into the client-side isn't OSM-like data (i.e. OSM XML or some high-level transform of that), but rather something closer to a vector graphics format like SVG?

That makes sense then, thank you!

[wiredfool]

It's a mapbox mvt, which is protobuf. It contains the OSM data (obviously), but it's a specific format that's in wide use (mapbox-gl, maplibre, and many other open source versions). There are similar versions in pmtiles, which is basically the same thing in a http range friendly big single file which can be hosted on S3-like storage and used directly.

The difficulty is that the stack for rendering vector tiles in the browser is different than the legacy vector->png generation that's been done for ages.

[sp8962]

> It contains the OSM data (obviously) ...

Not really. You need to build geometries from raw OSM data (aka the stuff that you edit) then transform those geometries into MVT format adding appropriate attributes from the original data. In general you actually will want to normalize the data and throw out anything that is not included in the vector tile schema you are using. The net result is quite far from raw OSM data in any case.

PS: I maintain a project that stores actual OSM data in MBTiles format for offline editing, and yes proper editing apps have to do the above on the fly and it is the main reason they are not lightning fast.