SvelteKit's Default SSR Worldview — and Where It Bites You
SvelteKit's Default SSR Worldview — and Where It Bites You
SvelteKit’s design is internally coherent: SSR on by default, a load function that runs on both server and client, form actions preferred over raw REST, progressive enhancement as the baseline. Server handles data fetching, auth, and redirects; client takes over interactivity after hydration. +page.server.ts for server-only logic, +page.ts for isomorphic code, endpoints only when you actually need an API surface. Honestly, it’s one of the more thoughtfully designed meta-frameworks I’ve used. The form actions layer in particular feels good — it keeps you out of the habit of reaching for fetch before you need to.
The issue is that all those defaults come with assumptions baked in. When the environment diverges from those assumptions, things go sideways fast. The worst case I hit personally: a back-office app running on a network drive (NAS mount at a client site). SvelteKit’s dev server spins up Vite, which crawls the module graph and starts transforming dependencies. On a local SSD that’s three seconds. On a slow NAS it hung past sixty seconds, and sometimes simply never came back. Not a SvelteKit bug — Vite’s dev server is inherently I/O heavy, and slow storage punishes that. Production builds were the same story: vite build turned every deploy into a waiting game.
In the end I scrapped that SvelteKit setup and rewrote the back-office as a plain Svelte SPA — no SvelteKit, no Vite-dependent routing. I wrote a hash router in about eighty lines, zero external dependencies, all state on the client, API calls going straight to backend endpoints. Half a day’s work, and we never saw the Vite hang again. That’s not a general recommendation — it’s what made sense in that specific environment, on that specific storage setup.
The point isn’t that SvelteKit is broken. It’s that you should know what it’s defaulting into on your behalf: Vite’s dev server, SSR’s module system, hydration overhead. Those have costs, and certain environments amplify them to the point where the framework’s strengths become liabilities. If you understand what you’re opting into, you can make a deliberate choice to opt out — rather than spending two days tuning Vite cache settings and hoping for the best.
Key Takeaways
- SvelteKit’s SSR + form actions model is well thought out; server handles logic first, client takes over interaction after.
- Vite’s module transformation is I/O-heavy, and running it on a network drive or slow storage can make development unusable.
- A plain Svelte SPA with a minimal hash router is sometimes the most pragmatic call for back-office tooling and low-interactivity pages.
- Framework defaults are optimised for mainstream environments, not guaranteed to work well in every context.
- Knowing what defaults you’re stepping out of matters more than blindly adopting or rejecting the framework.
Sheng’s take, drafted with Claude · part of the 2026-06-13 blog renovation, paint still drying.