SvelteKit

SvelteKit is the official framework for building full-stack applications with Svelte. It layers a filesystem-based router, server-side rendering, load functions, form actions, and a pluggable adapter system on top of Vite, so a project gets routing, data loading, and a production build pipeline without hand-wiring any of it. Rather than shipping its own bundler or dev server, SvelteKit builds directly on Vite and a dedicated Svelte plugin, giving it fast HMR and access to the wider Vite plugin ecosystem while keeping the framework’s own surface area small.

Deployment is decoupled from the framework core through adapters — separate packages (adapter-node, adapter-vercel, adapter-cloudflare, adapter-netlify, adapter-static, adapter-bun, adapter-auto) that translate a built SvelteKit app into the shape a given host expects. Newer additions like typed remote functions let client code call server logic through a single function declaration instead of hand-rolled API routes, continuing the project’s pattern of removing boilerplate rather than adding configuration surface.

What You Get

• A filesystem-based router driven by +page, +layout, +server, and +error files under src/routes, with no manual route registration
• Server-side rendering, client-side rendering, and build-time prerendering, configurable per route via page options
• Typed load functions and generated ./$types per-route types for zero-config type inference on page data and params
• Typed remote functions for calling server-side logic directly from client code without hand-written API endpoints
• A pluggable adapter system (Node, Vercel, Cloudflare, Netlify, Bun, static, or auto-detected) that decouples the app from any specific hosting target
• Built-in support for form actions, hooks, service workers, image optimization, and environment-variable modules ($env/static, $env/dynamic)

Common Use Cases

• Building full-stack web applications that need both server-rendered pages and API endpoints in one codebase
• Migrating a React/Next.js or Vue/Nuxt team to Svelte while keeping an equivalent meta-framework feature set
• Shipping statically prerendered marketing or documentation sites via adapter-static, with SSR available for the parts that need it
• Deploying the same codebase to different hosts (Vercel, Cloudflare Workers, a Node server) by swapping the adapter, not the app code

Under The Hood

Architecture SvelteKit’s core lives under packages/kit/src, split into core/ (config resolution in core/config, manifest generation in core/generate_manifest, dev/build type sync in core/sync, and adapter orchestration in core/adapt), runtime/ (client and server request handling, hooks, app state under runtime/client and runtime/server), and exports/ (the public API surface: exports/index.js/public.d.ts, the Vite plugin in exports/vite, Node-specific helpers in exports/node). Filesystem routing scans src/routes, builds a manifest mapping route files to route nodes, and the Vite plugin wires that manifest into a custom dev/build pipeline. Hosting-specific output is delegated to separate adapter packages (adapter-node, adapter-vercel, adapter-cloudflare, adapter-netlify, adapter-static, adapter-bun, adapter-auto) consumed through core/adapt, so the framework core has no knowledge of any specific host. Changing the manifest or routing abstraction would ripple through every adapter and the Vite plugin, since they all consume its generated shape directly.

Tech Stack The runtime is authored in plain JavaScript with JSDoc-based typing rather than TypeScript source, with generated .d.ts declarations (via dts-buddy) giving consumers full editor type-checking. It builds on Vite (peer dependency) and a dedicated Svelte plugin, with Svelte itself as a peer dependency. Direct dependencies are narrowly scoped to specific problems: devalue for serializing data across the server/client boundary, cookie for cookie parsing, sirv for static asset serving, mrmime for MIME resolution, esm-env for environment detection, and @standard-schema/spec/valibot supporting the newer remote-functions validation. The monorepo uses pnpm workspaces with changesets for release management, and oxfmt alongside eslint for formatting and linting.

Code Quality The test suite spans 58 colocated .spec.js unit tests run via Vitest (covering the router, URL helpers, shared runtime utilities, and more) plus a separate integration/E2E layer using Playwright that exercises full built applications in both dev and build modes. CI runs a dedicated workflow matrix per adapter (Node, Vercel, Netlify, Bun) alongside a general platform-tests-all job and a security audit workflow, plus an autofix-lint job. Error handling goes through typed helpers rather than ad hoc throws, and naming is consistently kebab-case for files, camelCase for functions. Overall this reads as a mature, actively and professionally maintained codebase with extensive automated coverage across both unit and cross-platform integration layers.

API Design The public API is deliberately minimal and convention-driven: routes are discovered by file naming rather than registered by hand, and $app/*/$env/* virtual modules expose framework internals (navigation, environment variables) without manual wiring. Generated per-route types give full inference on load return values and page props with no manual type annotations required. The newer remote-functions API further collapses client-server RPC boilerplate down to a single function declaration. Getting started is a single npx sv create command, though the file-naming conventions (+page, +layout, +server, +error) do require some upfront learning, which the extensive getting-started and core-concepts documentation sections are built to address.