Continuing my series on Svelte, I want to dig into how SvelteKit handles routing and how it compares with Next.js and Astro. These are the frameworks I am most familiar with, so apologies if you wanted a different framework.
\nLet’s start with everybody’s favorite topic: routing. Okay, maybe I’m the only one excited about this, but stick with me.
\nAstro’s routing feels the most traditional of the three. You have a src/pages/ directory, and the file name is the route. So src/pages/dashboard.astro maps to /dashboard. If you’ve worked with PHP or other languages with file-based routing, this will feel immediately familiar.
Inside the .astro file, you separate your backend logic at the top of the file with --- fences. That code runs entirely on the server, and everything below is your HTML template. Clean and straightforward.
Next.js (the current versions, at least) uses the App Router. The structure is folder-based: app/dashboard/page.tsx maps to /dashboard. The key difference from Astro is that the folder name determines the route, but the file must always be called page.tsx.
By default, everything in the app directory is a server component, meaning it runs on the server. If you want client-side interactivity, you explicitly add "use client" at the top of the file. You can also set "use server" if you want to be explicit, but it’s the default. I think Next.js does a really good job of making it clear what runs where.
SvelteKit also uses folder-based routing, similar to Next.js. The structure is src/routes/dashboard/, but instead of page.tsx, SvelteKit uses a reserved + prefix for its special files:
+page.svelte — Renders on the server, then hydrates on the client+page.server.ts — Runs only on the server (data loading, form actions)+server.ts — A raw API endpoint with no UIThere’s no "use client" or "use server" directive. The file naming convention itself tells SvelteKit what should run where. If you fetch a database record in +page.server.ts, that data is returned as an object, fully typed, and available in your +page.svelte via the $props rune. It just works.
I can see if some people get annoyed that every route has files named +page.svelte and +page.server.ts. The files will all look the same in the IDE, but there’s a real advantage here: you can group all related components in the same route folder.
For example, if you’re building a dashboard, you can keep your DashboardChart.svelte, DashboardFilters.svelte, and other components right alongside your +page.svelte and +page.server.ts. You always know which file is the route entry point, which handles server logic, and which are supporting components. It encourages logical grouping instead of scattering related files across the project.
| Feature | \nAstro | \nNext.js | \nSvelteKit | \n
|---|---|---|---|
| Route structure | \nFile name = route | \nFolder + page.tsx | \nFolder + +page.svelte | \n
| Server/client split | \n--- fences | \n"use client" directive | \nFile naming convention | \n
| API routes | \nsrc/pages/api/ | \napp/api/route.ts | \n+server.ts | \n
| Default rendering | \nServer | \nServer | \nServer + hydration | \n
All three frameworks use file-based routing, but they each have a slightly different philosophy about how to organize and separate concerns. Astro keeps it simple with traditional file mapping. Next.js gives you explicit directives. SvelteKit leans on naming conventions to keep things clean.
\nI think I can get used to the + prefix convention in SvelteKit. The type safety between your server file and your page component is nice.
Next up in the series, I’ll dig into how each framework handles data loading and forms.
\n", "date_published": "2026-04-10T10:00:00-05:00", "url": "https://llbbl.blog/2026/04/10/routing-in-sveltekit-vs-nextjs.html", "tags": ["Astro","svelte","Web development","Sveltekit","Nextjs"] } ] }