Using JOSM for your 1st edit is definitely not recommended.

Doing the same with iD (the editor embedded in the OSM website) is faster and there's even a tutorial that will explain a bit about how things work.

The main purpose of the maps on the site is, besides showcasing some topical uses of OSM data, rapid feedback to contributors, which is something that required specific development so that can be provided with vector tiles too.

The 'late to the game' narrative seems to be a bit misplaced in any case given that OSM data has powered essentially all vector tile use outside of Google over more than a decade.

The whole point of OSM is that you can take the data and build / design your own things. Yes it would be nice if there were multiple viable google alternatives based on OSM and other open data, but that is likely just a pipe dream, the economics don't really work.

Paul has written a blog post or two on the subject https://www.openstreetmap.org/user/pnorman/diary

Doesn't seem to make sense when you can just run a nominatim or photon instance locally. Not to mention that currently you would typically have to add additional address data to the mix to get the quality of commercial geocoding services which makes the doing it via tiles even less attractive.

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.

Tippecanoe takes geojson and splits it up into tiles, we are talking about doing that with OSM data here. Typically you will want to apply some normalisation of the input data, then you need instantiate the geometry of the OSM objects, then split things up according to the vector tile schema in use and then write the tiles.

It is difficult to beat raster tiles in that respect. vector tiles split up responsibility for what you get visually over multiple moving pieces with different provenance and operators.

Further point: the data available in the vector tiles is defined by the vector tile schema and by far doesn't contain "everything".

One of the downsides of MVTs and the typical max zoom level of 14 is that that they do require more local resources than simply rendering a 256x256 bitmap.

For OSM the question is naturally would a complete migration (aka turning off raster tile support) exclude any noticeable number of people from contributing.

But right now that decision is still a long way off, the vector tile service hasn't even been integrated in osm.org yet.

MVT format vector tiles are not remotely suitable for navigation or search (not ruling out that something could be hobbled together, but it would be a bit of a stretch).

Static or infrequently updated vector tiles can be generated from OSM data by a number of tools, but those most popular right now are https://github.com/systemed/tilemaker and https://github.com/onthegomap/planetiler

The actual -new- thing is that the work Paul has done for the OSMF allows on the fly (aka in minutes) updates of the vector tiles. This is important for OSM contributors as a feedback mechanism and the main reason the OSMF operates the current raster tile service.

What is currently a bit out in the open is which usage restrictions will apply to to using the vector tile service as, just as with the raster tile service, the intent is not to compete with or replace third party services and a vector tile service could potentially do that.

Except that the numbers show the opposite.