My Experience with Svelte and SvelteKit

Recently, I launched a web version of my book “Refactor Like a Superhero”.

To build it, I used SvelteKit. In this post, I want to share my experience with Svelte and SvelteKit, and explain why I liked this technology so much.

Why Svelte

When I thought about building a web version of the book, I knew I would need to choose a tech stack. I wanted something simple, lightweight, and fast.

Before, I already had projects written in React with Next and some written in vanilla technologies, and I wanted something simpler.

For this project, I felt like React with Next was going to be an overhead: too heavy, too much stuff I would not use, and too strong a commitment to follow every major version bump.

On the other hand, vanilla technologies require infrastructure: some builder with Gulp, for example, that I would need to set up manually.

Fortunately, I wanted to try Svelte for some time and heard many good reviews about it, so I decided to use it for this project.

“It Just Works”

I can describe the main expression from SvelteKit in one phrase: “Wow, it just works.”

For the whole time I have been building the app, I felt like any problem I came up with was already solved, and I just needed to look at the docs for the solution.

For instance...

Styles

Let's start with styles because those are one of my main pains with React ecosystem.

In React, there is no obvious or standard way to use styles. There are many options like CSS-in-JS (with or without runtime), CSS modules, style attribute, global CSS, etc.

In Svelte, on the other hand, you've got a built-in way to handle style—the style tag.

For example, here's the logo component from the book's source code:

<a href="/" class="logo" aria-label="Logo">
  <span aria-hidden="true">🧑‍💻 🦸</span>
</a>

<style>
  .logo {
    font-size: 3rem;
    line-height: 1;
    text-decoration: none;
  }
</style>

No need for additional infrastructure setup, “it just works.”

The styles are scoped by default, so I don't need to worry about isolation—safe defaults for the win. There's a way to escape the scoping if you want to, of course, but by default, the main issue with styling is solved beforehand.

Prerendering and SSG

The second thing is easy prerendering and SSG. To turn prerendering on, in most cases, you'll need one line of code.

Not all pages are suitable for it, but in my case, I had the whole site prerendered out of the box with no sweat.

By default, the prerendering starts with the root path of your site “/.” In my case, I needed to start not from the root but from 2 inner paths: “/en” and “/ru.”

I expected to waste hours trying to fix this, but SvelteKit's docs already had the solution. There's entries setting for the prerendering that solves that problem.

It felt like SvelteKit foresaw the problems I could face and carefully solved them beforehand. “Just works.”

For SSG, by the way, there's the static adapter. I haven't tried it yet but got plans to do so.

...And, well, I have a hunch that I'll have the same feeling of “just works” again.

Size and Speed

With Svelte, my whole application page (including routing, event handling, localization, prerendering, etc) is less than React alone 😅

(You could also totally remove JavaScript from the final build in some cases. I want to try it too.)

At the same time, SvelteKit is really fast. It uses Vite under the hood, and it's just ridiculously fast. I didn't have to “wait until it recompiles” to see the results of my changes like I need with Next, for instance.

I've got another project similar in complexity but written in React and Next. And I've got to say SvelteKit is much faster 😅

Platform Features

I really like how SvelteKit didn't try to invent the wheel with route transitions. We can use good-ol <a> tag to navigate between pages. No framework-specific stuff, just HTML, “just works.”

The same goes for the “form actions”, which are basically seamless API controllers. It isn't a unique feature, many frameworks have similar stuff, but I like how SvelteKit emphasizes the web platform features like standard request and response interfaces.

Amount of Code

The next thing is reactivity. I'm not really a fan of two-way data binding because I had a hard time debugging some stuff back in the day. But now I slowly change my mind.

It just takes less code to implement a feature with Svelte than with React. Just compare the amount of code needed to create a simple login form.

With React:

import { useState } from "react";

export const LoginForm = () => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  return (
    <form>
      <input
        type="email"
        name="email"
        value={email}
        onChange={(e) => setEmail(e.currentTarget.value)}
      />

      <input
        type="password"
        name="password"
        value={password}
        onChange={(e) => setPassword(e.currentTarget.value)}
      />

      <button>Submit</button>
    </form>
  );
};

...And with Svelte:

<script>
  let email = ""
  let password = ""
</script>

<form>
  <input 
    type="email" 
    name="email" 
    bind:value={email} 
  />

  <input 
    type="password" 
    name="password" 
    bind:value={password} 
  />

  <button>Submit</button>
</form>

Much more concise, compact, and declarative.

Accessibility

Speaking about safe defaults, Svelte has the accessibility linting built-in.

There are some obvious rules like “don't forget alt for images,” but also more nuanced ones like role and DOM structure checks.

Conclusion

So far, I really enjoy building the app with Svelte and SvelteKit. The process is much simpler and takes less time.

I'm not completely sure yet if Svelte can be used for large apps but for medium-sized apps and simple, mostly-static ones, it definitely is a good choice.

But What About Drawbacks?

Svelte has something I can rant about, too 😃

But I left those for another post and another time. Subscribe, and stay tuned!