Svelte: first impressions

[cross-posted from my web site.]

Svelte is "a tool for building fast web applications." Here are a few
thoughts after running through the (excellent) tutorial. Just to get this out of the way: If it seems like I'm wrong about something, I probably am! All I did was read the tutorial.

---

The first thing everyone tells you about Svelte is that... you know what? Let's skip that. You've already heard it, or if you haven't I'll tell you later.

I'm excited by what reactivity feels like in Svelte. Here's some code from the tutorial:

<script>
  let count = 0;
  $: doubled = count * 2;

  function handleClick() {
    count += 1;
  }
</script>

<button on:click={handleClick}>
  Clicked {count}
  {count === 1 ? 'time' : 'times'}
</button> 

<p>{count} doubled is {doubled}</p>

count is declared as a variable in a Svelte component. That's all it took to make it reactive. Now when it's incremented in handleClick,
the button text is automatically updated.

The $ label signifies a reactive declaration. doubled is not just initialized but defined as count * 2 – meaning that whenever count changes, doubled is recomputed. And when doubled changes, the paragraph below the button is automatically updated too.

All the modern frameworks have some version of this, and the differences are subtle. All I can say is that this feels good to me.

---

(By the way, how does Svelte get away with reactivity that feels this simple? Because it's not "just JavaScript." The code above looks like slightly funky HTML with an embedded script, and syntactically the script is valid JavaScript. But semantically it's different – variable assignment triggers code execution! – and that's because Svelte isn't a framework, it's a compiler. But we'll get to that.)

---

Just as reactivity within components feels simple, so does data management outside of them. Here's another sample from the tutorial:

function createCount() {
  const { subscribe, set, update }
    = writable(0);

  return {
    subscribe,
    increment: () => update(n => n + 1),
    decrement: () => update(n => n - 1),
    reset: () => set(0)
  };
}

OK, that doesn't make a lot of sense out of context. But it creates a data store with a standard interface (subscribe and unsubscribe), and a custom interface (increment, decrement, reset).

I don't know what it's like to use this for complex applications, but at this level, it's very appealing.

---

This is just a standalone feature, not a basic concept like reactivity and data stores. But I love that Svelte templates have built-in syntax for promises:

{#await promise}
  <p>...waiting</p>
{:then number}
  <p>The number is {number}</p>
{:catch error}
  <p style="color: red">
    {error.message}
  </p>
{/await}

This makes a no-brainer out of the "loading" indicators I often put off until later because they feel like tedious boilerplate.

Also, bonus points for doing some basic accessibility checks at build
time.

---

The first thing everyone else tells you about Svelte is that it's "compiled." Most web development frameworks consist of a large bundle of code that has to be downloaded and parsed by every user's browser, and that code in turn has to interpret your application code to figure out what to put on the page from moment to moment. Svelte doesn't do that. Instead, you use Svelte to translate your application code into a small bundle of very efficient code that already knows how it has to manipulate the page.

The second thing everyone tells you is that, because it's compiled, Svelte is much faster than most frameworks.

To me, those aren't the most exciting things about Svelte. There are three reasons for that:

• While Svelte delivers an impressively small bundle, that's only one component of perceived and actual performance.
• Performance is important, but it's not the only important thing. Robustness matters. Developer experience matters.
• I don't know, it's just not what I think is fun.

To be clear, I'm not saying that Svelte's overall performance isn't great, or that it isn't robust, or that the developer experience is bad. (In fact, most of this post is in praise of the developer experience!) I'm just saying that the "compiled, therefore performant" story itself doesn't grab me.

---

There are at least two things I'm curious about:

• What is debugging like? Is it harder because the compiled JavaScript is further removed from the source code?
• What is testing like? (Sounds like it's a work in progress.)

Overall, though, I'm impressed with Svelte. I'm looking forward to building something with it, and I recommend front-end developers check it out.

Comments

[Munawwar]

Well, size isn't the only metric. CPU usage on re-render especially on low perf mobile devices is something to look into.
And from my analysis svelte's way of updating DOM elements (which btw is the heaviest operation during re-renders) is O(1) for primitive data type. i.e. if you update "count" variable, svelte knows exactly which DOM elements to update.

Contrast this with React or Vue which renders a virtual DOM in memory and then diffs and finds which real DOM elements to update (the diff algo is O(n)). The react/vue approach has an overhead. Yes, with redux + having smaller redux props will mitigate this, but the overhead is still there.
Svelte makes performance the default which makes it attractive for say embedded systems, low perf phones etc.

Also, yes, robustness matters, developer experience matters... but I think svelte as an idea is indeed unique.

[Erik Ostrom]

Thanks for this. I agree, Svelte is unique, and from what I've seen it's great.

I believe your analysis of the DOM update algorithm. Of course, theoretically, depending on the application, it may not have a significant effect on overall performance. O(1) can be worse than O(n) if its constant factor is greater and n is always sufficiently small, and anyway, DOM updating is only one of many things going on in an application.

That's just an academic argument, though. The most persuasive factor for me is not specifically that Svelte has an O(1) update algorithm, or that it's compiled. It's that Rich Harris and the Svelte team take performance seriously, and it's evident throughout their work and in the way they discuss it. The algorithm and the compiler are results of that underlying attitude.

[Munawwar]

"Of course, theoretically, depending on the application, it may not have a significant effect on overall performance."

Yes, like I said, if you are targeting low perf devices/embedded devices, it would matter.

But again... in some cases it's better to have perf as default rather than later realizing and spending significant effort on perf optimisation.
Some would be quick to call it "premature optimisation!".. it's not, if its free.

"That's just an academic argument...
It's that Rich Harris and the Svelte team take performance seriously.."

I think most of the frameworks take perf seriously. But not all of them are equal in the end. How would you know how much they achieve in perf, without, say, benchmarking.. or dissecting their work and reviewing it? 🙂

[Erik Ostrom]

Fair enough.

[Zane Milakovic]

Great write up.

Svelte is interesting for me. For one, I feel React, Vue and other SPA are becoming too thick. Do you have a good idea of the bundle size output?

I am also sad Sapper is not further along. Server Rendering is a go to for me at this point.

[Erik Ostrom]

Thanks! I think the Size metric from FreeCodeCamp's RealWorld framework comparison is indicative. It's very impressive. As they say, the framework compiles itself away. However, an even realer real-world app might use more external libraries in addition to the framework, which would make the framework savings somewhat less significant.

FWIW, Vue 3.0 is supposed to be about half the size of Vue 2 – and it was already one of the smaller ones, although not like Svelte.

I haven't looked into Sapper yet. Where does it fall short for you?

[Jimmy Utterström]

Regarding testing, I think the Svelte adaptation of Testing Library seems to be working pretty well! And in general I think Kent C. Dodds' (the original author of react-testing-library) approach to testing front end components is very sound and reasonable. Read for example kentcdodds.com/blog/write-tests.

So I'd recommend going with svelte-testing-library, standard Jest unit tests for isolated logic, and probably Cypress if you want some E2E tests.

[Erik Ostrom]

Thanks!