A component at a time,
the app still running
We build apps in Svelte and SvelteKit, move them to Svelte 5 and SvelteKit 3 a step at a time, and render each page the way it needs, so each step can ship on its own.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When one upgrade waits on another
Many apps built with Svelte 3 or 4 and SvelteKit 1 or 2 work well, and their components are written in the syntax of the version they started on.
SvelteKit 3 can only go in once the app is on a recent release of Svelte 5 and on newer releases of Node, TypeScript and Vite, so the move comes as a chain: each part waits on the one before it.
Svelte 5 still runs components written in the older syntax, so the app can move first, and its components one at a time after it. That makes the order the real work: which part moves first, what each step needs, and how the app keeps shipping in between. How long that takes depends on the app: on its size, its tests and the libraries it relies on.
What we build
Every change is made on a branch, checked by the type check and the tests, and reviewed by a person before it ships.
New apps and sites
Apps and sites in SvelteKit, from the first route on, with tests from the first commit.
Upgrades, a step at a time
The app moved to Svelte 5 and the latest SvelteKit 2 release first, then to SvelteKit 3, each step on a branch with the tests passing, and its components moved to the new syntax one at a time.
Each page rendered the way it needs
Pages built ahead of time, made on the server when they’re asked for, or made in the browser, set page by page or for a group of pages at once.
Forms that work before the scripts load
Form actions that send with the page alone, before its scripts have loaded, and once they have, send without reloading the page.
Components your apps share
A component library built and packaged with its own tests, so each app takes a new version when it’s ready.
Faster pages, measured first
Where the time goes is measured first, then each change is compared with the page as it was.
APIs and integrations
The APIs and services behind your pages, called from code that runs only on the server, and every answer checked before a page shows it.
Checks on every change
The type check, the tests and the compiler’s accessibility warnings, run in CI on every change, and a change merges once they pass.
AI where it helps
Changes drafted by an AI coding assistant go through the same type check, tests and review as everyone else’s before they merge.
- For hosting and deploys:Cloud, DevOps & Security
- Pages measured and made faster:Performance & Optimization
- APIs between your systems:Systems & API Integration
- The tests behind each change:QA & Test Automation
- 3D inside the app:3D web development, with three.js
- The app on the desktop:Desktop app development, with the Electron® framework
- Developers in your own team:Developers for Svelte and SvelteKit apps
Each page, made the way it needs
By default, SvelteKit makes each page on the server and sends it as a finished page. Then the browser runs the page’s scripts to make it interactive, a step the docs call hydration.
Each page, or each group of pages, can instead be built ahead of time, when the app is built, or made in the browser alone, and one app can mix all three.
A page can be built ahead of time when every visitor gets the same page. A page that shows each person their own data, reads what was typed into a search box, or takes a form needs a server. A page made in the browser alone shows nothing until its scripts and data arrive, which costs speed and can cost search rankings, so it suits pages behind a sign-in.
So we decide page by page, and set the options where the app groups its pages. Below are six pages of a site of our own, each where it fits best: move one, and see what changes.
To move a page, drag it to another column, or tap it and then tap a column. With a keyboard, Space picks it up, the Left and Right arrow keys move it, and Space puts it down.
Built ahead of time
Made on each visit
Made in the browser
HomePool guideClass searchYour bookingsBook a swimStaff schedulein Built ahead of timein Made on each visitin Made in the browser
How it’s made: The page is made once, when the app is built, and every visitor is sent the same finished file.How it’s made: The server makes the page when it’s asked for and sends it finished; then the browser makes it interactive.How it’s made: The server sends an empty shell, and the page appears once its scripts and its data have loaded.
This page: Every visitor gets the same home page, so it can be built once and sent as it is.This page: It works here too, but every visitor gets the same page, so making it again on each visit is work the server doesn’t need to do.This page: Visitors would see nothing until the scripts and data load, which costs speed and can cost search rankings, for a page everyone could be sent finished.This page: The guide is the same for every reader, so it’s built once, and built again with each release.This page: It would work, but the guide is the same for everyone, so there’s nothing to make for each visit.This page: Readers and search engines would wait for the scripts before seeing the guide’s words, which a page built ahead of time sends at once.This page: Its results depend on what each person types into the search box, and a page built ahead of time can’t read that, so this page needs a server.This page: The server reads what was typed into the search box and sends the results as a finished page, so they show without waiting for scripts.This page: It would work once its scripts arrive, but each first search would wait for them; made on each visit, the results show sooner.This page: Each person sees their own bookings, and a page built ahead of time is the same for everyone, so this page needs a server.This page: The server checks who is signed in and sends their own bookings as a finished page.This page: It’s behind a sign-in, so search rankings don’t matter here, and it works in the browser; made on each visit, the bookings would show sooner.This page: A page with a form that sends to the server can’t be built ahead of time, since a server has to receive what the form sends.This page: The form sends to the server, so it works before the page’s scripts have loaded, and once they have, it sends without a reload.This page: The form would need its scripts before anyone could use it, and if they failed to load, it couldn’t be sent at all.This page: The schedule changes through the day, and a page built ahead of time shows only what was true when it was built.This page: It works here: the server sends the schedule finished, though only signed-in staff ever see it.This page: It’s behind a sign-in, so search engines never need it, and staff keep it open all day, so waiting for its scripts once costs little.
Fits best: Built ahead of time: the same page for everyone.Fits best: Built ahead of time: the same for every reader.Fits best: Made on each visit: it reads the search box.Fits best: Made on each visit: each person’s own bookings, sent finished.Fits best: Made on each visit: a form that needs a server.Fits best: Made in the browser: behind a sign-in, kept open all day.
We set this page by page, and check each choice before launch.
{{ rdStatus }}
In order, one step at a time
Svelte 5 still runs components written in the older syntax, and mixes them with components in the new one, so an app can move to Svelte 5 first and its components after it, one at a time.
SvelteKit 3 asks for more first: a recent release of Svelte 5, and newer releases of Node, TypeScript and Vite. The SvelteKit team recommends moving to the latest 2.x release before version 3, for its deprecation warnings, which point to what the move will change.
Each framework has a migration tool that makes many of the changes itself, and SvelteKit’s lists what it couldn’t finish, for a person to work through.
So we move one step at a time, on a branch, with the tests and the type check passing at each step, and the app shipping between steps.
Start with the components and the routes
The review covers the Svelte, SvelteKit, Node, TypeScript and Vite versions in development, in CI and in deploys, against the latest releases; the components still written in the older syntax, and anything still using $app/stores; the configuration, and what SvelteKit 3 moves into the Vite config; each route’s page options, and whether each page is made the way it needs; the forms, and whether each works before the scripts load; server-only code, and where it lives as SvelteKit 3 reads it; environment variables, and which ones reach the browser; the CSRF settings and the origins they trust; the adapter, the part that builds the app for where it runs; the dependencies that are behind or no longer maintained; the type check, tests and the compiler’s accessibility warnings in CI; performance, measured as a baseline for the review; and logs, errors and traces.
The first step is one of these, each tried on a branch: the app on the latest SvelteKit 2 release, with its deprecation warnings cleared; Svelte 5 in place with every component still in the older syntax, and the tests passing; one component moved to the new syntax, with its tests; one group of pages set to be built ahead of time, measured before and after; or the type check, tests and the compiler’s accessibility warnings added to CI.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Do our components have to be rewritten for Svelte 5?
No. Svelte 5 still runs components in the older syntax beside components in the new one, as its migration guide says, so they can move one at a time, each with its tests.
Should we move to SvelteKit 3 now?
It depends on what your app needs from it, and on whether its adapter and tools are ready for it. We move to the latest 2.x release first, as the migration guide recommends, then run the migration tool on a branch and finish what it lists.
Is Svelte a good fit for us?
It depends on the work and the team. Svelte and SvelteKit can build anything from a single component to a full app. Where your team already works well in another framework, we’d usually keep it, and use Svelte where it fits.
Should every page be rendered on the server?
No. Each page can be made the way it needs: built ahead of time when every visitor gets the same page, made on each visit when it’s personal or takes a form, and made in the browser when it’s behind a sign-in.
Will search engines see our pages?
Pages built ahead of time or made on the server arrive finished, their words already in the page. Pages made in the browser alone can harm search rankings, as the SvelteKit docs say, so we keep those to pages behind a sign-in.
Can it work with our existing back end?
Yes. The app’s server code calls your APIs and services, in code that never reaches the browser, and the pages show what comes back.
How do you keep it fast?
We measure first, change what the measurements point to, and compare each change with the page as it was.
Do you check accessibility?
Yes. The compiler warns about some accessibility problems as the code is built, and those warnings run on every change. Many problems only show when the app runs, so tests and a person’s review cover the rest.
Can AI assistants help with our Svelte code?
Yes. Whatever an assistant drafts goes through the type check, the tests and the compiler’s warnings, and a person reviews it before it merges.
Can you take over our existing app?
Yes. First we read it: its components, its routes and page options, its tests, and how it’s built and deployed. Then we agree on a first piece of work, name the person on our side who owns it, and work alongside any developers you already have.
What does it cost?
It depends on the app and on the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire developers for our own team?
Yes. We introduce developers for Svelte and SvelteKit apps within 48 hours of your request, each working in your time zone, and you meet them before deciding who joins.
Webair is independent of the Svelte project, and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us what your app does, which versions it runs on and how it’s deployed, and we’ll suggest a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}