When we rebuilt our company website earlier this year, we had to pick a framework. The safe choice would have been Next.js — it is the default for most teams, has the largest ecosystem, and every developer has at least some experience with it. We chose SvelteKit instead. Here is why, and what we learned after shipping with it.
The Candidates
We evaluated three frameworks seriously:
- Next.js 15 — The industry standard. React-based, massive ecosystem, Vercel-backed.
- Nuxt 4 — Vue-based, strong conventions, good DX.
- SvelteKit 2 — Svelte 5 with runes, compiled output, minimal runtime.
All three could have done the job. The decision came down to a few factors that mattered specifically to us.
Why SvelteKit Won
Bundle Size and Performance
Our site is a static marketing site with a contact form. It does not need a 90KB JavaScript runtime. Svelte compiles components into vanilla JavaScript with no framework runtime overhead. Our entire site ships under 30KB of JavaScript (gzipped). The equivalent Next.js build would be 3-4x larger before we even add our own code.
For a company that sells performance-focused software, shipping a bloated website would be a bad look.
Svelte 5 Runes
Svelte 5 introduced runes — $state(), $derived(), $effect(), $props() — which replaced the old reactive declarations. This was a gamble: we adopted a framework version that was still maturing. But the new reactivity model is genuinely better. It is explicit, TypeScript-friendly, and easier to reason about than React hooks or Vue's Composition API.
There is no rules-of-hooks mental overhead. No stale closure bugs. No dependency arrays to get wrong. You declare state with $state(), derive values with $derived(), and run side effects with $effect(). It just works the way you expect.
Static Site Generation Done Right
SvelteKit's adapter system is elegant. We use adapter-static to prerender every page at build time, then deploy to Cloudflare Pages. The build outputs plain HTML, CSS, and minimal JavaScript. Server-side logic (our contact form API) runs as a Cloudflare Pages Function, completely separate from the static build. Clean separation, no compromise.
Tailwind CSS Integration
Tailwind v4 with the Vite plugin works seamlessly with SvelteKit. No PostCSS configuration, no build step weirdness. Scoped styles and Tailwind utilities coexist without conflicts. This sounds minor, but CSS tooling friction can waste hours on a project.
What Surprised Us
The Ecosystem Is Smaller Than Expected
React has a component library for everything. Svelte does not. We used lucide-svelte for icons, but for most UI needs we wrote our own components. For a marketing site this was fine — we wanted custom design anyway. For a complex application with data tables, date pickers, and rich text editors, the ecosystem gap would matter more.
TypeScript Support Is Excellent
We expected some rough edges with TypeScript in Svelte 5, given how new runes were. We were wrong. svelte-check catches everything at build time. Props are typed with standard TypeScript interfaces. The developer experience is on par with — and in some cases better than — Next.js with TypeScript.
Error Messages Are Clear
When something goes wrong in SvelteKit, the error messages are specific and actionable. Compare this to React's component stack traces or Next.js hydration mismatch errors, and the difference is stark. We spent almost zero time debugging framework issues.
Build Times Are Fast
Our full build — including OG image generation, type checking, and static rendering of all pages — completes in under 10 seconds. Vite's dev server starts in under a second. For a team that values fast iteration, this matters more than it sounds.
What We Would Do Differently
Start with a Component Library Sooner
We built components ad hoc as pages needed them. By the time we had five pages, we had inconsistencies in spacing, button styles, and card layouts. If we started over, we would define a component library with typed props and documented variants before writing any page content.
Use mdsvex for Blog Content
Our blog posts are currently stored as HTML strings in TypeScript files. This works but is awkward to author. We should have set up mdsvex (Markdown for Svelte) from the start. Writing blog posts in Markdown is a better experience than editing HTML in template literals.
Would We Recommend It?
For marketing sites, documentation sites, and small-to-medium web applications: yes, without hesitation. The developer experience is the best we have used. The output is fast. The learning curve is gentle if you already know HTML, CSS, and JavaScript.
For large applications with complex state management needs and a team that already knows React: probably stick with Next.js. The ecosystem advantage is real, and hiring React developers is easier than hiring Svelte developers.
For us, SvelteKit was the right call. Our site is fast, maintainable, and a pleasure to work on. That is not something we have said about every framework we have used.