On a recent project, our clients needed a marketing-style website, without a ton of bells and whistles. They highly valued SEO visibility, accessibility, and development speed, as it was a short engagement. SvelteKit, a framework based on the language Svelte and released in December 2022, seemed to fit all these requirements.
Although our internal team was unfamiliar with it, we decided to spike out some work and see how viable SvelteKit could be. SvelteKit has impressed us, from how easy it was to get started with, to its intentionality with server-side rendering, and its emphasis on accessibility. We were even impressed with its quick fixes to bugs we stumbled upon along the way. These are just a few of the observations I’ve made about SvelteKit development.
It’s easy to learn and use.
As a small team with a short timeline, ease of adaptation was a concern for us when weighing frameworks to choose from. While we still run into knowledge gaps, we find SvelteKit approachable. Yet, it remains flexible enough to not feel like its simplicity is restrictive.
I particularly like the file-system based route definitions. The path of each file indicates its route, and the naming structure (+page.server.ts, +page.svelte.ts, etc) indicates its role (server vs UI, in this example). You can also use these conventions with +layout.svelte files to pass along common components throughout the child routes. SvelteKit takes all the tedious work out of organizing both routes and the codebase. The framework even leaves flexibility to decouple the route definitions from the file system structure. Simply add parentheses around the directory to exclude from the route: /new/(route)/here → /new/here
For the most part, it has been easy to integrate SvelteKit with the other tools and languages I’m accustomed to using like React, Storybook, and Typescript. The component libraries also seem well-designed. I am looking forward to trying out Skeleton, for example.
There are benefits to SvelteKit’s server-side rendering.
SvelteKit originally won our team over with its server-side rendering features. Having access to the load() function has been a great asset. That’s because it can query the database and send the information back to the component side as props, all during server-side rendering. This once again speeds up development by removing the need to write endpoints. This also means that the data is all cached. All the server-side rendering benefits that SvelteKit offers allowed our team to easily improve SEO and accessibility, both high on our client’s list of priorities.
Some parts of SvelteKit, like the +layout.svelte files are both client and server-side rendered. There are also options to restrict where pre-rendering should or should not happen. Being attentive to how to maximize SvelteKit’s rendering advantages is a new experience. But, overall, their documentation of this is very helpful.
It’s still new.
SvelteKit was just released officially in December of 2022, and the language Svelte came out in late 2016. Consequently, there are still occasional bumps to work out. Our team spent half a day figuring out why some server-side code was being skipped. We finally discovered that using a new Date() call was causing the Svelte compiler to indirectly strip out the following line of code! Thankfully, the Svelte development community is involved and attentive. A fix for this was rapidly deployed.
Overall, any bumps with SvelteKit have been far outweighed by intuitiveness and speed of development. It retains the familiarity of React development while streamlining more straightforward development projects. I’ve been impressed with SvelteKit and look forward to continuing to use it.