Sapper vs. svelte-routing vs. svelte-spa-router: Architecture and Usage Compared

When navigating the Svelte ecosystem, choosing the right routing solution depends entirely on whether you need server-side rendering (SSR) and how much framework structure you want. sapper, svelte-routing, and svelte-spa-router solve the same problem — moving users between views — but they do it in fundamentally different ways. Let's break down their architectures, trade-offs, and code patterns.

🏗️ Core Architecture: Framework vs. Library

sapper was a full-stack framework. It didn't just handle routing; it managed your server, your build process, and your deployment. Routing was tied directly to your file system.

• You created files in a routes folder, and sapper automatically turned them into URLs.
• It handled SSR, pre-fetching, and code splitting automatically.
• Status: Deprecated. It has been replaced by SvelteKit.

// sapper: File-based routing structure
// routes/about.svelte
<script>
  export let segment;
</script>

<h1>About Page</h1>

svelte-routing is a library designed to work with SSR. It treats routes as regular Svelte components.

• You define routes using <Route> components inside your main layout.
• It works in both Node.js (server) and the browser, making it safe for SSR.
• You have full control over where the router lives in your component tree.

// svelte-routing: Component-based definition
<script>
  import { Router, Route } from 'svelte-routing';
  import Home from './Home.svelte';
  import About from './About.svelte';
</script>

<Router>
  <Route path="/" component={Home} />
  <Route path="/about" component={About} />
</Router>

svelte-spa-router is a lightweight library built strictly for Single Page Applications.

• It assumes all rendering happens in the browser.
• It uses a simple JavaScript object or array to map paths to components.
• It does not support SSR; trying to run it on a server will cause errors.

// svelte-spa-router: Code-based configuration
<script>
  import Router from 'svelte-spa-router';
  import Home from './Home.svelte';
  import About from './About.svelte';

  const routes = {
    '/': Home,
    '/about': About
  };
</script>

<Router {routes} />

🔄 Navigation and Links

How you move between pages differs slightly in syntax, though the user experience is similar.

sapper uses a special <a> tag replacement.

• You import sapper's anchor component to enable client-side navigation without page reloads.
• It automatically handles prefetching when the user hovers over a link.

// sapper: Specialized anchor component
<script>
  import { a } from 'sapper/app';
</script>

<a href="/about">Go to About</a>

svelte-routing provides a <Link> component.

• It works similarly to standard HTML links but intercepts clicks for client-side navigation.
• It supports an active class prop to style links when their route is matched.

// svelte-routing: Link component
<script>
  import { Link } from 'svelte-routing';
</script>

<Link to="/about" let:active>{active ? <b>About</b> : "About"}</Link>

svelte-spa-router also uses a <Link> component.

• It is very minimal and focuses purely on changing the URL and rendering the component.
• It supports passing props directly through the link to the destination component.

// svelte-spa-router: Link with props
<script>
  import { Link } from 'svelte-spa-router';
</script>

<Link to="/user/123" params={{ id: 123 }}>View User</Link>

📥 Handling Dynamic Parameters

Extracting data from the URL (like /user/5) is a common requirement. Each package handles this differently.

sapper exposes params via export let based on the filename.

• If your file is named [id].svelte, the variable id is automatically available.
• This is very clean but tightly coupled to the file name.

// sapper: Dynamic file naming [id].svelte
<script>
  export let id; // Automatically populated from URL
</script>

<h1>User {id}</h1>

svelte-routing passes params as props to the component.

• You define the parameter in the path string (e.g., /user/:id).
• The component receives id as a standard exported prop.

// svelte-routing: Path parameters
<!-- Route definition -->
<Route path="/user/:id" component={User} />

<!-- User.svelte -->
<script>
  export let id;
</script>

<h1>User {id}</h1>

svelte-spa-router passes params via a params prop.

• You define parameters in the path using standard syntax (/user/:id).
• The target component receives a params object containing all dynamic values.

// svelte-spa-router: Params object
<!-- Route definition -->
const routes = { '/user/:id': User };

<!-- User.svelte -->
<script>
  export let params;
</script>

<h1>User {params.id}</h1>

🛑 Critical Warning: The Status of Sapper

It is vital to understand that sapper is no longer maintained. The Svelte team officially transitioned to SvelteKit, which offers the same file-based routing and SSR capabilities but with a modern architecture, faster builds, and active support.

If you are starting a new project today:

• Do not choose sapper.
• Choose SvelteKit for full-stack needs.
• Choose svelte-routing if you need SSR in a custom setup without SvelteKit.
• Choose svelte-spa-router for simple client-side dashboards.

// DO NOT START NEW PROJECTS WITH THIS
import { a } from 'sapper/app'; 

// INSTEAD, USE SVELTEKIT FOR FULL STACK
// routes/about/+page.svelte (SvelteKit)

🌐 Real-World Scenarios

Scenario 1: Marketing Site with Blog

You need excellent SEO, fast initial loads, and content fetched from a CMS.

• ✅ Best choice: SvelteKit (Successor to sapper)
• Why? You need SSR and static generation. svelte-spa-router won't work because search engines can't execute JS to see content. svelte-routing works, but SvelteKit provides the build tools you need out of the box.

Scenario 2: Internal Admin Dashboard

Your app is behind a login screen. SEO doesn't matter. You just want it to feel snappy.

• ✅ Best choice: svelte-spa-router
• Why? It's lightweight and easy to set up. You don't need the complexity of a server-rendered app. You can define your routes in one file and go.

// Dashboard setup with svelte-spa-router
const routes = {
  '/': DashboardHome,
  '/settings': Settings,
  '/users/*': Users // Catch-all for nested user routes
};

Scenario 3: Custom SSR Integration

You are embedding Svelte into an existing Node.js or PHP application and need specific control over the HTML shell.

• ✅ Best choice: svelte-routing
• Why? It allows you to render the route tree on the server manually. You aren't forced into a specific folder structure or build pipeline like sapper (or SvelteKit) demands.

📊 Summary Table

💡 Final Recommendation

The choice here is less about "which is best" and more about "what architecture do I need?"

1. If you need Server-Side Rendering: Avoid svelte-spa-router. If you can, use SvelteKit. If you have a strict constraint preventing SvelteKit, use svelte-routing.
2. If you are building a Client-Side Only App: svelte-spa-router is often the fastest way to get up and running. It removes the boilerplate of SSR you don't need.
3. If you see sapper in a tutorial: Remember that it is outdated. Any new project requiring its features should use SvelteKit instead.

By matching the tool to your rendering needs (SSR vs. SPA), you avoid unnecessary complexity and ensure your application is built on a supported foundation.