For at least a decade, web mapping has predominantly relied on the use of raster tiles to distribute information to browsers. Whether pre-generated or rendered on the fly, this means significant server resources to produce non-interactive images which quickly go out of date. A generally better method, vector tiles, has been available for several years now, but still has pretty low uptake outside of large consumer-oriented mapping applications. Why? Because adapting existing infrastructure and pipelines from raster tiles to vector tiles is much more challenging than it first looks.
With raster tiles, you store all your data in one place, accessible to the tile rendering pipeline. Challenges include designing cartography that works at a fixed number of scales, using mature, but ageing, server-side technologies, and maintaining the computing resources required. The browser-side display process is trivial.
With vector tiles, data is potentially never brought together until the browser. The hard questions are about exactly how much data to cram into each vector tile, what tradeoffs to make, and how to build the pipeline. The server-side technologies are much newer and there are fewer established practices. There is much greater flexibility on the browser side (although fewer libraries to choose between), but generally more complicated code.
I will show how I crossed the gulf, with a couple of websites I originally developed using raster tiles, then subsequently re-architected using vector tiles, including openbinmap.org and opentrees.org. The end result means the sites can be hosted for free using Github Pages and Mapbox.
I will also outline several challenges that remain in my ongoing quest to rebuild another former raster-tile-based site, cycletour.org.