From Next.js 15 to SvelteKit: Why We Rewrote Rsale.net's Frontend

Hey dev.to! Maksim here again, author of the previous article "From Idea to MVP: Building a Classified Platform in Serbia" about Rsale.net, a classified platform for Serbia. In that post I described the stack: Next.js 15 + React 19 + ASP.NET Core microservices + AI translation.

A few months later, the frontend has been fully rewritten on SvelteKit 2 + Svelte 5 (runes). The Next.js codebase is gone. In this article I'll walk through why we did it, what we gained, and where it hurt.

Project status: the backend is still being finished, the site shows test data. But the new frontend is already in production-ready shape.

TL;DR

We migrated from Next.js 15 / React 19 to SvelteKit 2 + Svelte 5 runes. Bundle size dropped, DX improved, the Server/Client Component dualism disappeared, and i18n became a 50-line file instead of a separate library. No regrets.

Why we left Next.js

Next.js 15 is a great framework. But on a real project, a classified board with three languages, ISR, SignalR chat, geolocation, image upload, a sell wizard, three pain points piled up.

1. The Server/Client Component dualism. In the previous article I called it the "Server-First + Client Wrapper" pattern. Sounds elegant on a slide. In practice every new component requires a decision: 'use client' or not? Can I import it from a server component? Why did the bundle suddenly grow by 40 kB? Why does this hook break SSR?

// Next.js 15, a typical "wrapper" because we need one onClick
'use client';
import { ServerThing } from './server-thing';
export function Wrapper({ children }) {
  return <div onClick={...}>{children}</div>;
}

In SvelteKit there is no such dichotomy. A component is just a component. SSR happens by default, hydration too, and reactivity works the same on the client and the server.

2. Bundle size and React runtime. React 19 + the Next.js runtime + next-intl + zustand + framer-motion, even with aggressive code-splitting the baseline JS for an empty page was around 99 kB. For a classified board where users open 20–30 listings in a session, that's a real cost on Serbian 4G.

Svelte is a compiler. There is no "framework runtime" shipped to the browser, only the code your components actually need.

3. RSC, caching and the "magic". fetch overrides, revalidate, unstable_cache, dynamic = 'force-dynamic', ISR with on-demand webhooks, Next.js gives a lot, but every "why isn't this updating" debugging session takes an hour. SvelteKit's model is honest and explicit: the load function, export const prerender, export const ssr, export const csr. That's it.

Why SvelteKit

Compiler instead of runtime. Svelte compiles components to plain JS that mutates the DOM directly. No virtual DOM, no reconciler, no Fiber. For a content-heavy site, that's a free performance win.

Svelte 5 + runes. Runes ($state, $derived, $effect) replaced the magic $: and stores from Svelte 4. The model is closer to Solid/MobX, explicit, debuggable, and works the same in .svelte and .svelte.ts files.

Here's our auth store. It's a regular .svelte.ts file, no writable, no providers, no useContext:

// src/lib/stores/auth.svelte.ts
let currentUser = $state<AuthUser | null>(null);

export const auth = {
  get user() { return currentUser; },
  get isAuthenticated() { return currentUser?.isAuthenticated ?? false; },
  get isAdmin() { return currentUser?.role === 'admin' }
};

export function notifyAuthChanged() {
  getChannel()?.postMessage('auth:changed');
}

Any component just imports auth and reads auth.user, reactivity is automatic. Compare with React: useContext + Provider + useSyncExternalStore for cross-tab sync.

File-based routing without [locale] everywhere. In Next.js the i18n routing scheme is app/[locale]/..., every route lives under a dynamic segment. In SvelteKit we handle locale in hooks.server.ts via cookie + Accept-Language and prefix URLs with a helper lp('/category/cars'). Route folders stay clean: routes/category/[id], not routes/[locale]/category/[id].

i18n in 50 lines instead of a library. We dropped next-intl and wrote our own thing. Three dictionaries, one t() function, runes for reactivity:

// src/lib/i18n/index.svelte.ts
export type Locale = 'sr' | 'ru' | 'en';
const allTranslations: Record<Locale, Translations> = { sr, ru, en };

let currentLocale = $state<Locale>('sr');

export function setLocale(locale: Locale) {
  currentLocale = locale;
  document.cookie = `locale=${locale}; path=/; max-age=31536000; SameSite=Lax`;
}

export function t(key: TranslationKey, params?: Record<string, string | number>): string {
  let text = allTranslations[currentLocale]?.[key] ?? allTranslations['sr'][key] ?? key;
  if (params) {
    for (const [k, v] of Object.entries(params)) {
      text = text.replace(`{${k}}`, String(v));
    }
  }
  return text;
}

That's it. No ICU MessageFormat (we don't need plural rules in this domain), no providers, no next-intl config files. Type-safety comes from TranslationKey = keyof typeof sr, TypeScript yells at any unknown key.

SSR by default, no 'use client'. Every +page.svelte is rendered on the server, gets hydrated on the client, and reactivity just works. No mental tax on whether to put 'use client' at the top.

<!-- routes/category/[id]/+page.svelte -->
<script lang="ts">
  import { t } from '$lib/i18n/index.svelte';
  import { auth } from '$lib/stores/auth.svelte';
  let { data } = $props();
</script>

<h1>{t('category.title')}</h1>
{#each data.products as product}
  <a href="/listing/{product.id}">{product.title}</a>
{/each}
{#if auth.isAuthenticated}
  <button>{t('add_favorite')}</button>
{/if}

This component runs on the server and on the client. No directives, no wrappers.

Stack: before and after

SignalR for chat stayed, it's a client library, framework-agnostic. The ASP.NET Core backend with microservices and the AI Translation Service didn't change at all, the rewrite was purely frontend.

The migration in practice

What was easy:

• Routing. app/[locale]/products/[id]/page.tsx became routes/products/[id]/+page.svelte. Conceptually 1:1.
• Server-side data loading. Next's async function Page() became SvelteKit's load() in +page.server.ts. Same idea, cleaner separation.
• API routes. route.ts with GET/POST became +server.ts with the same exports.

Where we had to think:

• ISR analog. Next had revalidate: 600. SvelteKit doesn't have ISR out of the box with adapter-node (it does with adapter-vercel if you host there). For static pages (about, terms, blog index) we use export const prerender = true, for dynamic ones plain SSR-on-demand. With proper Cache-Control headers and a CDN in front, the practical effect is the same.
• Image optimization. No next/image. We use sharp at upload time + a small <img> wrapper with srcset. Less magic, more control.
• Sell wizard state. Our sell wizard was a tangle of Zustand slices. Moving it to a single sell-wizard.svelte.ts with $state actually shrank the code by about 40%.

What genuinely hurt:

• Smaller ecosystem. No shadcn/ui, no react-hook-form. You write more by hand. For us this was a plus, fewer black-box deps, but on a deadline-driven project it would hurt.
• Svelte 5 is fresh. Some libraries (Leaflet wrappers, for instance) hadn't been updated to runes yet. We use vanilla Leaflet directly, works fine.
• Ecosystem search. "How do I do X in SvelteKit" Google results often return Svelte 4 / SvelteKit 1 answers. Always check the version.

Numbers (dev environment, same machine)

The build-time numbers are the ones that changed daily life the most. vite build finishes before you alt-tab to the browser.

What stayed from the previous architecture

• ASP.NET Core microservices. Untouched. The frontend rewrite didn't ripple into the backend at all, that's the upside of a clean REST contract.
• AI Translation Service. Still translates listings between Serbian, Russian and English on submit.
• SignalR for chat. Library is frontend-agnostic, just a different import path.
• Three-language UX with Cyrillic-first Serbian. That's a market decision, not a tech one.

Would I recommend the move?

If you're starting from scratch in 2026 and your project is content-heavy with SSR/SEO requirements, try SvelteKit first. The DX is genuinely better, the bundle is smaller, the mental model is simpler.

If you have a working Next.js project that ships features, don't migrate for the sake of migrating. We rewrote because we were still in MVP, there are only two of us (me and my backend friend), and 2–3 weeks of rewriting paid for itself in faster iteration after.

If your team is large and React-shaped, the hiring market reality is real. SvelteKit devs exist but there are fewer of them.

What's next

• Finishing the backend (transition from test data to real listings).
• On-demand cache invalidation: ASP.NET webhook to a SvelteKit endpoint that purges CDN entries.
• PWA and offline-first for mobile.
• Improving AI translation with category context.

The architecture lesson from both articles is the same: boring backend, sharp frontend choices. The stack you pick on the frontend is the one users actually feel.

If you're considering the same migration, drop questions in the comments. The site lives at rsale.net, still on test data, but the SvelteKit build is what's serving it.