Sapper: Build Tooling & Migrating to SvelteKit

SSR + Hydration + Code-Splitting

• SSR: pages render to HTML on the server for the initial request -- faster first paint, better SEO than a blank-until-JS-loads client-only SPA.

• Hydration: the same server-rendered markup becomes interactive client-side without a full re-render.

• After hydration, internal link clicks are intercepted for client-side navigation -- SPA-like feel, only fetching the new page's data rather than a full document reload.

• Code-splitting: JavaScript bundled per route automatically -- a visitor to one page doesn't download the whole app's JS upfront.

• export(): could pre-render pages to static HTML at build time for content not needing per-request rendering -- a precursor to SSG modes in later frameworks.

Build Tooling: Rollup, Not Vite

// Sapper predates Vite's rise -- original tooling centered on
// Rollup (Svelte creator Rich Harris also created Rollup), with
// webpack supported as an alternative later.
// rollup.config.js -- typical Sapper project structure
import svelte from 'rollup-plugin-svelte';
import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';

export default {
  client: { /* ... */ },
  server: { /* ... */ },
  serviceworker: { /* ... */ },
};

// SvelteKit was built from the start on Vite -- part of why it
// wasn't just an incremental update to Sapper's existing architecture.

Why SvelteKit Replaced Sapper (Not Just Iterated On It)

• Sapper never reached a stable 1.0 -- gave the Svelte team latitude to make a larger architectural break rather than being bound by strict backwards-compatibility.

• SvelteKit's adapter system (pluggable deployment targets -- Vercel, Netlify, Node, static) was hard to bolt onto Sapper's original design.

• Same core team (Rich Harris and the Svelte project) built both -- SvelteKit is the official successor, not a competing outside fork.

• load functions (SvelteKit) are the direct conceptual continuation of preload() (Sapper), refined and extended.

Migrating an Existing Sapper App

• Not a pure rename -- SvelteKit revised routing file-naming conventions and the data-loading API (load replaces preload).

• The official Svelte migration guide documents the concrete file/API mapping from Sapper to SvelteKit.

• Realistic reason to still learn Sapper today: maintaining or migrating a pre-existing production Sapper codebase -- never for a new project.