Framework-Specific Routing Patterns

Every JavaScript framework solves the same underlying problem — mapping a URL to a piece of UI — yet each one wraps the browser’s navigation primitives in a different abstraction. React Router exposes routes as components and configuration objects, Next.js and SvelteKit derive them from the file system, and Vue Router blends declarative config with imperative navigation guards. Once you see that all of them are thin layers over the same pushState, popstate, and matching machinery, switching between frameworks stops feeling like learning a new language and starts feeling like learning a new dialect.

The Mental Model #

There are really only two ways a router can learn what routes exist. In a declarative configuration model, you hand the router an explicit list — an array of objects or a tree of JSX/template elements — that names each path and the component it renders. React Router and Vue Router both work this way: the route table is data your application code constructs at runtime, which means you can generate it, filter it, or compose it from multiple modules. In a file-system model, the router infers the route table from the directory layout at build time. Next.js and SvelteKit both take this path: a folder named [id] becomes a dynamic segment, a layout file becomes a wrapping shell, and you never write a route table by hand.

Both models ultimately produce the same three things at runtime. First, a matcher that turns the current pathname into a matched route plus extracted parameters. Second, a navigation function that changes the URL without a full page load by calling the browser’s history methods. Third, a history listener that reacts when the user presses back or forward. React Router’s useNavigate and Vue Router’s router.push are navigation functions; Next.js’s useRouter().push and SvelteKit’s goto are the same idea under different names. The popstate listener that synchronises UI with the address bar is present in all four — it is just hidden inside the library.

Holding this model in your head is what lets you read any framework’s routing code quickly. When you encounter an unfamiliar API, ask which of the three roles it plays: is it describing routes, triggering navigation, or responding to history changes? Almost every routing function maps cleanly onto one of those, and the differences that remain — server rendering, data loading, layout nesting — are refinements layered on top of this shared core.

It helps to picture the difference between the two models as when the route table comes into existence. In a configuration-object router the table is constructed while your application boots: you import an array, the router walks it, and from that moment the matcher has a complete picture of every path. Because this happens at runtime, the table is just data — you can splice in routes after fetching a user’s permissions, merge tables exported by separate feature modules, or strip out routes that a given build should not expose. In a file-system router the table is frozen at build time. The bundler reads the directory, emits one chunk per route, and writes a manifest that the runtime consults; there is no array to manipulate because the directory is the array. This is why dynamic, permission-driven navigation feels natural in React Router and Vue Router, while Next.js and SvelteKit instead express such cases through redirects and conditional rendering inside otherwise-static routes.

The payoff of recognising these roles is that your knowledge transfers. A developer who understands that Vue Router’s beforeEach guard is “code that runs between matching and rendering” will immediately recognise SvelteKit’s load function and Next.js’s Server Component data fetching as the same checkpoint, even though the syntax and execution environment differ wildly. The rest of this guide leans on that transfer: each section names a concept once, shows it in one framework’s syntax, and then points out where its siblings live in the other three.

Shared Browser Foundations #

No framework router invents navigation from scratch; they all build on the browser primitives covered in History API & State Management. The central pieces are history.pushState(), which adds an entry to the session history stack and changes the visible URL without a request; history.replaceState(), which rewrites the current entry in place; and the popstate event, which fires when the user moves through that stack with the back and forward buttons. A client-side router is, at its heart, code that intercepts link clicks, calls pushState, runs its matcher, and swaps the rendered view — then listens for popstate to reverse the process. The mechanics of those calls are detailed in pushState & replaceState usage and popstate event handling.

The other half of the foundation is matching: deciding which registered route a given pathname belongs to and pulling out its parameters. The broader design space — static versus dynamic segments, specificity ordering, and the data structures that make lookups fast — is the subject of Routing Architecture & Fundamentals, and the algorithmic details live in route matching algorithms. Most production routers resolve paths through a trie (prefix tree) rather than testing each route’s regular expression in turn, because a trie gives O(k) lookups where k is the number of path segments, independent of how many routes you have registered.

// framework-agnostic trie matcher — no runtime deps
interface RouteNode {
  children: Map<string, RouteNode>;
  handler?: () => void;
  paramName?: string; // present for dynamic ':segment' nodes
}

class RouteTrie {
  private root: RouteNode = { children: new Map() };

  addRoute(path: string, handler: () => void): void {
    let current = this.root;
    for (const segment of path.split('/').filter(Boolean)) {
      const isDynamic = segment.startsWith(':');
      const key = isDynamic ? ':' : segment;
      if (!current.children.has(key)) {
        current.children.set(key, {
          children: new Map(),
          paramName: isDynamic ? segment.slice(1) : undefined,
        });
      }
      current = current.children.get(key)!;
    }
    current.handler = handler;
  }

  match(path: string): { handler: () => void; params: Record<string, string> } | null {
    let current = this.root;
    const params: Record<string, string> = {};
    for (const segment of path.split('/').filter(Boolean)) {
      if (current.children.has(segment)) {
        current = current.children.get(segment)!;
      } else if (current.children.has(':')) {
        const dynNode = current.children.get(':')!;
        if (dynNode.paramName) params[dynNode.paramName] = segment;
        current = dynNode;
      } else {
        return null;
      }
    }
    return current.handler ? { handler: current.handler, params } : null;
  }
}

Every framework router contains a more elaborate version of this — handling wildcards, optional segments, and specificity — but the shape is universal. The variation in dynamic route segments is mostly syntactic: React Router writes :id, Next.js and SvelteKit write [id], and Vue Router writes :id with optional regex constraints.

Specificity is the one place where the universal shape hides genuine disagreement, and it is worth understanding because it explains a class of “why did the wrong page render” bugs. When two routes could both match a URL — say /products/new and /products/:id — the router must decide which wins. Most frameworks rank a static segment above a dynamic one above a catch-all, so /products/new is preferred and :id only catches values that are not new. React Router computes a numeric score per route and sorts the table, so registration order does not matter; Vue Router historically respected the order in which you declared routes, which means an over-broad route placed first could shadow more specific ones below it. File-system routers sidestep most of this by deriving precedence from the folder structure, but they introduce their own rules for ranking [id] against [...slug] catch-alls. Whenever you add a route and a different page renders than you expected, the cause is almost always a specificity rule, and the fix is either reordering, narrowing the dynamic segment with a constraint, or renaming the file.

Declarative vs File-System Routing #

The clearest dividing line between the four frameworks is whether routes are objects you write or files the build tool discovers. The trade-off is concrete: configuration objects can be generated and composed at runtime, while file-system routes are statically analysable, which makes per-route code splitting and prefetching automatic.

The annotated example below puts a configuration-object router (React Router) next to the directory convention it replaces. The left half is real code; the right half is the file tree a file-system router would use to express the same routes.

// react-router-dom v6.22 — declarative configuration object
import { createBrowserRouter, RouterProvider } from 'react-router-dom';

const router = createBrowserRouter([
  {
    path: '/',
    element: <RootLayout />,        // wraps every child route
    children: [
      { index: true, element: <Home /> },       // matches "/"
      {
        path: 'products/:id',                     // dynamic segment -> params.id
        element: <Product />,
        loader: async ({ params }) =>             // data fetched before render
          fetch(`/api/products/${params.id}`).then((r) => r.json()),
      },
      { path: '*', element: <NotFound /> },       // catch-all fallback
    ],
  },
]);

export const App = () => <RouterProvider router={router} />;

/*
  The same route table expressed as a file-system tree (Next.js App Router):

    app/
      layout.tsx          -> RootLayout, wraps every page
      page.tsx            -> Home, matches "/"
      products/
        [id]/
          page.tsx        -> Product, params.id from the folder name
          loading.tsx     -> streamed fallback while the segment loads
      not-found.tsx       -> NotFound, the catch-all fallback

  Nothing in the directory is "configuration"; the folder names ARE the route
  table, and the build step discovers them.
*/

Both approaches express identical concepts — a shared layout, a dynamic segment, a loader, and a fallback — but they distribute the information differently. The configuration object keeps everything in one file, which is easy to grep and to generate programmatically; this is why dashboards with permission-driven menus often favour React Router or Vue Router. The file-system tree spreads routes across the disk, which scales better for large teams because two people editing different routes never touch the same file, and it lets the bundler split each route automatically without you marking the boundaries. SvelteKit follows the same file-system philosophy as Next.js, using +page.svelte, +layout.svelte, and [slug] folders, while Vue Router mirrors React Router’s object-array style. Deciding between the two families is partly a question of SPA vs MPA trade-offs, since file-system routers tend to assume server rendering as the default.

Performance & SEO Implications #

Routing is one of the largest levers you have over a frontend’s performance budget, because the router decides what JavaScript ships and when. The single most effective technique is per-route code splitting: rather than bundling every screen into one file, each route loads its own chunk on demand. File-system routers do this automatically — every page file becomes a separate chunk — whereas configuration-object routers ask you to opt in with lazy imports.

// react-router-dom v6.22 — lazy route with a Suspense boundary
import { lazy, Suspense } from 'react';
import { createBrowserRouter } from 'react-router-dom';

const Reports = lazy(() => import('./routes/Reports')); // separate chunk

const router = createBrowserRouter([
  {
    path: 'reports',
    element: (
      <Suspense fallback={<Skeleton />}>
        <Reports />
      </Suspense>
    ),
  },
]);

Server rendering changes the calculus further. Next.js’s App Router defaults to React Server Components, which run on the server and send serialised UI rather than executable JavaScript, so a route that is mostly static ships almost no client code. SvelteKit renders on the server by default and hydrates the result, while React Router and Vue Router are client-first but can be paired with server frameworks. The key behaviour to understand across all of them is hydration: the server sends HTML, then the client attaches event listeners to make it interactive. A mismatch between the server’s and client’s route trees forces a full client re-render and is one of the most common production bugs in server-rendered routing.

For perceived speed, prefetch-on-hover (and on viewport entry) is now standard. When a link enters the viewport or the pointer hovers over it, the router fetches that route’s chunk and data during idle time, so the navigation feels instant when the click finally lands. Next.js prefetches links automatically in production, SvelteKit exposes data-sveltekit-preload-data, and React Router and Vue Router expose APIs to trigger it manually. The discipline here is restraint: prefetching every visible link on a dense page can saturate a mobile connection and starve the resources the user actually needs, so production routers throttle requests, cancel prefetches for links that scroll out of view, and respect the user’s data-saver preference. A reasonable default is to prefetch only on intent — pointer hover or focus — rather than on mere visibility, which keeps the cheap win without the bandwidth tax.

The matching SEO concern is that crawlers must still find content. Three rules cover almost every case. First, internal navigation must use real anchor elements with href attributes, because a crawler follows links, not click handlers attached to <div>s. Second, when a route genuinely does not exist, the server must return a real 404 status rather than a 200 with an error page painted client-side, or search engines will index the soft error as valid content; the strategies for distinguishing these cases are covered in fallback routing strategies. Third, deep linking must work — every URL the application can produce should render correctly when typed directly into the address bar or shared as a link, which means the server (or your static export) has to know how to serve that path without relying on client navigation having happened first. Frameworks that render on the server satisfy these by default; client-only configurations need a catch-all rewrite on the host so that a refresh on /products/42 still serves the application shell.

Accessibility Considerations #

Client-side routing breaks an assumption that assistive technology relies on: in a full page load, the browser automatically resets focus and announces the new document. When a router swaps content without a reload, none of that happens for free, so two things must be handled deliberately in every framework.

The first is focus management. After a navigation, focus should move to a sensible landing point — usually the page’s main heading or the <main> element — rather than being stranded on the link that was clicked. A common pattern gives the route container tabindex="-1" and focuses it after the new view mounts, scheduling the move with requestAnimationFrame so it runs after the DOM has settled.

The second is route-change announcements. Screen readers will not announce a soft navigation unless you route the change through an ARIA live region. The robust approach is a visually hidden element with aria-live="polite" whose text content you update with the new page title on every navigation.

// react-router-dom v6.22 — focus + live-region announcement on navigation
import { useEffect, useRef } from 'react';
import { useLocation } from 'react-router-dom';

export function RouteAnnouncer({ title }: { title: string }) {
  const location = useLocation();
  const liveRef = useRef<HTMLDivElement>(null);
  const mainRef = useRef<HTMLElement>(null);

  useEffect(() => {
    if (liveRef.current) liveRef.current.textContent = `${title} page loaded`;
    requestAnimationFrame(() => mainRef.current?.focus({ preventScroll: true }));
  }, [location.pathname, title]);

  return (
    <>
      <div ref={liveRef} aria-live="polite" className="sr-only" />
      <main ref={mainRef} tabIndex={-1}>
        {/* routed content */}
      </main>
    </>
  );
}

Next.js’s App Router and SvelteKit both ship built-in route announcers, which is a real advantage; with React Router and Vue Router you typically wire this up yourself. Whatever the framework, also coordinate announcements with scroll handling so the two do not fight — the patterns in scroll restoration strategies cover restoring position without yanking focus away from where it belongs.

Common Pitfalls & Edge Cases #

Each framework family has characteristic mistakes that recur in production code.

React Router (configuration-object family).

• Forgetting <Suspense> boundaries around lazy routes, which throws instead of showing a fallback.
• Reading params from the wrong level of a nested route and getting undefined because the segment belongs to a parent.
• Treating the loader as if it re-runs on every render — it runs on navigation, not on re-render, so client state changes will not refetch it.

Next.js App Router (file-system family).

• Mixing Server and Client Components incorrectly — calling a browser API in a Server Component, or marking an entire subtree 'use client' and losing the server-rendering benefit.
• Expecting useRouter from the Pages Router to behave identically in the App Router; they are different modules with different APIs.
• Hydration mismatches from rendering time-, locale-, or random-dependent values during server rendering.

Vue Router (configuration-object family).

• Async navigation guards that never call next() or resolve, silently hanging the navigation.
• Relying on <keep-alive> to cache a component while also expecting fresh data on every visit — the two goals conflict.
• Forgetting that route params changing does not remount the component, so you must watch the param to refetch.

SvelteKit (file-system family).

• Confusing +page.ts (runs on both server and client) with +page.server.ts (server only), and leaking secrets into the universal load.
• Returning data from a layout load and assuming child pages automatically invalidate it when the URL changes.
• Disabling preloading globally and then wondering why navigations feel slower than the defaults.

A pitfall shared by all four families is leaking listeners. Any popstate, resize, or IntersectionObserver you attach inside a routed view must be cleaned up when that view unmounts, or long-lived sessions accumulate handlers and degrade over time. Equally universal is the redirect loop: an authentication guard that sends an unauthenticated user to /login, while /login itself runs a guard that bounces authenticated users back to /, can ping-pong forever if the session check momentarily disagrees with itself. The defence is to make guards idempotent — never redirect to a path that would re-trigger the same guard — and to track in-flight navigations so a pending redirect can be cancelled rather than stacked on top of another.

Two more cross-cutting edge cases deserve a mention. The first is trailing slashes: /about and /about/ are different strings, and frameworks disagree on whether they collapse to the same route. Inconsistent handling produces duplicate URLs that split SEO ranking and confuse caches, so pick one canonical form and redirect the other at the edge. The second is scroll and focus colliding on back navigation: when the user presses back, the browser wants to restore scroll position, the router wants to manage focus for accessibility, and a naive implementation does both and ends up doing neither correctly. Coordinating the two — restore scroll first, then move focus only if the user did not arrive via the back button — avoids the disorienting jump that plagues many client-rendered sites.

Framework Capability Matrix #

The table summarises how each framework handles the routing capabilities that matter most when choosing one. “Built in” means the framework provides it without extra libraries; “manual” means you can achieve it but must wire it up yourself.

No row makes one framework strictly better; they reflect different defaults. The file-system routers lean toward server rendering and automatic optimisation, while the configuration-object routers trade some of that automation for runtime flexibility.

Explore the Topics #

• React Router Implementation — how React Router v6’s data router, loaders, actions, and nested routes turn the configuration-object model into a complete application shell.
• Next.js App Router vs Pages Router — the differences between the two Next.js routers, including Server Components, streaming, and when migrating is worth it.
• Vue Router Configuration — composing route tables, navigation guards, and <keep-alive> caching to manage state across transitions in Vue applications.
• SvelteKit Routing Conventions — the +page, +layout, and +server file conventions, universal versus server load functions, and zero-config preloading.

Related #

• Routing Architecture & Fundamentals — the framework-neutral concepts of matching, dynamic segments, and rendering models that every router in this guide builds on.
• History API & State Management — the browser primitives (pushState, popstate, scroll restoration) that all four framework routers wrap.
• Next.js App Router vs Pages Router — a deep dive into the file-system family’s most influential implementation.
• React Router Implementation — a deep dive into the configuration-object family’s reference implementation.