September 2022 our Svelte adventure has begun. A fresh new team on a brand new project using the most cutting-edge framework on the market. This blog post is the beginning of a series dedicated to our experiences with the Svelte framework.
The first thing everybody notices about Svelte is that it looks different than most of the popular frameworks today, like React, Vue, or Angular. Every member of our team has mainly React experience, and we all picked up Svelte fairly easily. Its tutorial is short but detailed, its documentation is clear and concise, and its main features are simple yet powerful.
The reason Svelte looks different is the usage of JavaScript in HTML as opposed to HTML in Javascript that we all know as JSX. Svelte’s creator, Rich Harris, reasons that it’s beneficial for the SSR build times since Svelte’s server components just get concatenated and shipped to the client. But the main difference between Svelte and the other popular frameworks is the lack of client runtime since Svelte is a compiler.
Now you might be asking yourself: how do we get reactivity if we don’t have a client runtime? Well, the language itself handles it, meaning the state of Svelte components updates on assignments, which in turn triggers rerenders if necessary.
count += 1;If any element would depend on the count variable, any change to it would result in the rendering of that element. Since Svelte compiles the code we write, it may seem to the uninitiated that there is some black magic at work, but in essence, all Svelte does is add a bit of code after each assignment that lets the browser know that the DOM should be updated.
count += 1; $$invalidate('count', count);
Additionally, to accommodate the simple nature of the reactive assignments, Svelte has another mechanism that allows for more complex reactive behaviour. Any top level statement can be made reactive by prefixing it with the $: : JavaScript label syntax.
$: double = count;
$: {
console.log(`multiple statements can be combined`);
console.log(`${double} double is double the value of ${count}`);
}
$: if(count > 9) {
console.log(`${count} is too high`);
count = 9;
} Each of this statements would rerun if any of its dependencies would change, e.g., if count would change double would have to also be recalculated. The way Svelte handles it behind the scenes is by using the dependency graph, which stores and orders every piece of code that has an impact on the state of the component, and updates them if any of the invalidate calls appear.
It’s a radical change in the way a developer should think about state as opposed to the diffing algorithms of Virtual DOM frameworks like React.
Each member of our team was versed in React, which didn’t make the change easy, but where there’s a will, there’s a way, but half a year later we love Svelte for what it is.
That being said, it’s all Svelte needs to handle state inside the component hierarchy, but since Svelte is a compiler with opinions on how the state should be managed, the Svelte team didn’t want to leave the rest to the community and delivered the built-in way to handle state outside of the component hierarchy in the form of stores, but more on that in the next chapter, so stay tuned!
Josip Ante Cindrić
Software Engineer who joined our team because it seemed like a great opportunity to develop great things while growing as a person in a healthy environment. He loves dogs and board games.