Why We Ditched Next.js for a Vite SPA (And Built a Layout System in 7 Lines)

Next.js is the default choice for React apps in 2026. We chose Vite + Tanstack Router + SPA instead. And our entire layout system is 7 lines of code.

Repo: https://github.com/rogasper/labas-bahasa

Key Takeaways

• Tanstack Router's staticData pattern lets each route declare its layout mode (app/public/fullscreen) in a single line, with the root layout resolving the deepest match replacing Next.js layout components with 7 lines of configuration and ~30 lines of resolution logic.
• For an exam practice platform. SSR provides no SEO benefit (the app is behind authentication) and adds complexity (server components, hydration mismatches, data fetching on server). A SPA with lazy-loaded routes delivers the same user experience with simpler architecture.
• DevTools (Tanstack Router DevTools, React Query DevTools) are production-gated via import.meta.env.DEV a pattern that ships zero dev-only code to production while keeping the developer experience rich.

The Decision: SPA vs SSR

In 2026, the React ecosystem has largely standardized on Next.js as the default framewok. Its App Router, Server Components, and SSR capabilities are powerful but they're designed for a specific use case: content-heavy, SEO-critical, publicly-accessible websites.

Labas is the opposite:

• Authentication-gated. Most routes require login. Google can't crawl them anyway.
• Interactive. The exam interface, AI generator, and analytics dashboard are cloent-heavy applications.
• Single-user. Each session is personalized there's no shared TML to cache at the CDN egde.

For this use case, SSR adds complexity without benefit. Server Components can't run client-side exam timers. Hydration mismatches are common with real-time state. And the App Router's layout system while powerful is overkill forn an app with three layout modes.

So we chose a SPA: React 19 + Vite + Tanstack Router. No SSR. No Server Components. No App Router.

The Route Shell System: 7 Lines

The entire layout system lives in apps/web/src/lib/route-shell.ts:

export type RouteShell = "public" | "fullscreen" | "app";

export const routeShell = {
  public: { shell: "public" as const },
  fullscreen: { shell: "fullscreen" as const },
  app: { shell: "app" as const },
};

That's it. Three layout modes, exported as constants. Each route file declares which shell it uses:

import { routeShell } from "@/lib/route-shell";

export const Route = createFileRoute("/dashboard")({
  staticData: routeShell.app,  // ← one line
  component: DashboardPage,
});

The root layout (__root.tsx) reads the staticData from the deepest matching route and conditionally renders the appropriate shell:

function resolveShell(matches: AnyRouteMatch[]): RouteShell {
  for (let i = matches.length - 1; i >= 0; i--) {
    const shell = matches[i]?.staticData?.shell;
    if (shell) return shell as RouteShell;
  }
  return "app"; // default
}

The resolveShell function walks matches from childmost to parentmost, finding the deepest staticData declaration. This means a nested route can override its parent's shell a /login route inside an app shell parent can declare routeShell.public and get the bare layout.

The Three Shells

The app shell includes the sidebar navigation, responsive margins (md:ml-64), and an accessibilty SkipLink that jumps to #main-concent. The public shell is a bare wrapper no sidebar, no navigation. The fullscreen shell is h-screen overflow-y-auto designed for the exam interface where every pixel matters.

File-Based Routing Without the Magic

Tanstack Router uses file-based routing like Next.js, but it's a SPA no server-side rendering, no App Router conventions, no page.tsx vs layout.tsx distinction.

The route structure looks like this:

apps/web/src/routes/
  __root.tsx              # Root layout (reads staticData, renders shell)
  index.tsx               # Landing page → redirects to /dashboard if logged in
  index.lazy.tsx          # Lazy-loaded landing page component
  dashboard.tsx           # Authenticated home page
  login.tsx               # Login page (routeShell.public)
  generate.tsx            # AI Generator wizard
  bank.tsx                # Question Bank browse
  bank.$id.tsx            # Package detail
  builder.tsx             # Test Builder
  builder.combo.tsx       # Package Combiner
  exam.$id.tsx            # Exam Interface (routeShell.fullscreen)
  exam.$id.attempt.$attemptId.tsx  # Exam attempt (routeShell.fullscreen)
  analytics.tsx           # Deep Analytics dashboard
  settings.tsx            # Settings (API keys, profile)
  $.tsx                   # Catch-all 404 (routeShell.public)

The $.tsx file is the catch-all 404 route. It declares routeShell.public so no sidebar appears on 404 pages. We deliberately don't put a notFoundComponent in __root.tsx the 404 is handled exclusively by the splat route.

Lazy Loading: The .lazy.tsx Pattern

Heavy route components are split into two files:

generate.tsx          # Thin route file (staticData, loader, component reference)
components/routes/GeneratePage.tsx  # Heavy component (wrapped in Suspense)

The route file is thin:

export const Route = createFileRoute("/generate")({
  staticData: routeShell.app,
  component: GeneratePage,
});

const GeneratePage = lazy(() => import("../components/routes/GeneratePage"));

The heavy component lives in components/routes/ and is wrapped in Suspense with a loading skeleton. This pattern keeps route files focused on routing logic while deferring component code splitting to the lazy import.

DevTools: Production-Gated

Tanstack Router DevTools and React Query DevTools are invaluable during development. But they shouldn't ship to production. We gate them with import.meta.env.DEV:

{import.meta.env.DEV && (
  <>
    <TanStackRouterDevTools />
    <ReactQueryDevtools />
  </>
)}

When NODE_ENV=production, import.meta.env.DEV is false the DevTools are never imported, never bundled, and never shipped. Vite's tree-shaking removes them entirely from the production build.

This is pattern that Next.js handles automatically (DevTools are dev-only by default). In a Vite SPA, we need to be explicit but the result is the same: zero dev-only code in production.

The Tradeoffs: What We Gave Up

Choosing SPA over SSR isn't free. Here's what we sacrificed:

1. No SSR for SEO. Our landing page (/) is a SPA route Google crawls it via Javascript rendering. For a product page, this is fine. For a content blog, it wouldn't be.
2. No Server Components. We can't run database queries directly in components. All data fetching goes through tRPC -> Tanstack Query. This is actually a benefit for our architecture (clear API boundary), but it means we can't user Server Component patterns.
3. No App Router convetions. No loading.tsx, no error.tsx, no not-found.tsx automatic conventions. We handle loading states with Suspense, errors with route-level errorComponent

For our use case, these tradeoffs are acceptable. The landing page is the only public route that benefits from SSR and it's a simple page that renders quickly even as a SPA.

Frequently Asked Questions