Svelte - First Go

In recent years most of my frontend development has been in ReactJs, which was a completely different way of writing front-end code to Angular or plan html and JavaScript. It did take some getting used to, but it worked very nicely most of the time. The biggest downside as all the state management and memoization to keep performance up. I have written a couple of blog posts about this in the past. There have been some major changes with the introduction of a React compiler, mostly because of the rising popularity of Svelte, and since I heard many good things about Svelte, I decided to use it for a new project.

There is always a learning curve when using a new framework, but I feel that the tutorial section of Svelte guides you very well into getting to know the core concepts and how to write your first application. The fact that they already changed the paradigm with the introduction of runes does mean that you will find some code and articles that are no longer relevant, so sticking to the official documentation seems best for new users.

Svelte is an opinionated framework, in that sense that routes are defined by the file structure and the name of the files. It also uses server side rendering out of the box, which seems to run perfectly fine in my experience, but more about that later. Both are rather minimal changes compared to React, the real change is in how the framework works and how your code is structured.

Svelte uses runes to keep track of state, perform effects, etc. If you are familiar with React, you will actually recognise a lot of the rune names, but where React has you jump through hoops to keep your state consistent and make sure everything is updated, Svelte does this automagically for you. Just compare these two code snippets (Svelte on the left, React on the right).

<script> let count = $state(0); </script> <button onclick={() => count++}> clicks: {count} </button>

const [count, setCount] = useState(0); <button onClick={() => setCount(prev => previous + 1)}> clicks: {count} </button>

This is still very similar, although Svelte already feels more natural since you are simply updating the variable directly. The difference however becomes more interesting if you want to perform an effect.

$effect(() => { if (count > 5) { // do something } });

useEffect(() => { if (count > 5) { // do something } }, [count]);

As you can see, the major difference is that in Svelte you don't have to add the dependencies yourself, which I have found are often the cause of errors.

Another major difference is that even though Svelte combines the html and JavaScript in a single file it does so in a more plain way. It uses a <script> tag for the JavaScript at the top of your file, that combined with the more plain html (compared to the JSX components in React) makes it feel more lightweight. You don't have to define components in their own class (or function), but they are wrapped automatically. I really like this basic, back to the roots, approach of writing html and JavaScript, even though that in the past I would not have liked it, but with the introduction of Typescript and how JavaScript has evolved over the years, having to deal less with magical syntax is a relief.

The only thing that I do find to be a bit confusing is to figure out when something is rendered on the server and when it will be done on the client. There are some clear indicates, such as naming files .server.ts, but even then I don't know what happens to the dependencies. Does the initial rendering happen on the server and subsequent renders on the client? This is a domain which I should read up on a bit more, but the truth also is that it actually doesn't matter that much, unless of course you really want to optimise your application. I personally haven't had any issues yet where I tried to do something on the client side that wouldn't work because it could only be executed on the server end or the other way around, but then again, I haven't gone that deep into the whole system.

Another issue I have found is that there aren't that many libraries yet that work very nicely with Svelte, so that may be a challenge, or you may have to try out some more experimental libraries. Testing is also not really on par yet. Event he documentation of Svelte itself only mentions end-to-end tests with Playwright. If you know me, you will know that I like to have a lot of unit testing, even for my front-end. In React, I was able to mock components but the same approach didn't work for Svelte. In the end I did find a way to mock components, which I will explain in detail in the next blog post.

In the end, I do like Svelte and I hope that it will gain some traction. But since a lot of projects are currently written in React or Angular and most developers have experience with either (or both) of these frameworks, I don't think many companies will start writing front-ends using Svelte just yet. It will take some time before we see real production Svelte front-ends. For my own projects however, I currently see Svelte as my first choice, with React as a close second (due to the high demand in the industry).