Download websites that use Sapper

The maintainers of Sapper are the people who told everyone to stop using it. Built by the Svelte team as the framework that gave Svelte projects server rendering, file based routing and code splitting, Sapper was superseded by SvelteKit, which took over as the official way to build such applications. Nothing new starts on it any more.

A framework with no incoming installs has a property that active ones lack. Every site running it was built before the successor existed, and every site still running it has chosen, actively or through neglect, not to migrate. The population can only shrink, so comparing the same list across two dates measures a migration rate directly, which is a number no individual domain can give you.

Detection of a build time framework is inferential by nature, and pretending otherwise would be dishonest. Sapper leaves traces in generated JavaScript bundles, route manifests and the shape of its client runtime, but a project exported to static files, or one whose build was customised heavily, can pass unrecognised. As of October 2026 we detect it on 750 sites, a count of pages still carrying the fingerprint rather than a census of repositories.

Three readings of the list follow from that. Audit teams care because an MIT project that receives no further releases also receives no security fixes, and finding unpatched dependencies is a job that needs the whole set rather than one example. Agencies care commercially, since a codebase with a known ageing problem and a known destination is the cleanest possible migration pitch, and the framework's own maintainers have already made the argument for them. Researchers care about the rate itself, how fast a community actually moves when its maintainers declare a successor, which is a question about a whole population and cannot be answered one domain at a time. Released in 2017, Sapper now works mainly as a marker of when a codebase was written and how long it has been left alone.