Svelte - What It Is And Why You Should Consider Using It

Jan 12th 2020 by Mattes Wieben

Svelte - What It Is And Why You Should Consider Using It

Do you like building small and fast web apps with very few lines of code? If so, Svelte might be worth looking into. Svelte is a component based web framework which compiles your code during a compile step and delivers highly optimised and tightly bundled code to the devices of your users.

But first, let's take a step back and look at some facts and the history of Svelte.

A Brief Summary Of Svelte's History

Svelte was introduced by Rich Harris (@Rich_Harris) and is now developed as an Open Source project. You can contribute or check out the code on Github. As of the time of writing Svelte has 29.2K Stars and 262 Contributors on Github.

To get a feel for where Svelte is coming from, let's go back its beginnings.

Time Travel

It is November 26th in 2016 and the beginning of Svelte's journey. At least the public journey. I'm sure Rich Harris thought about Svelte a couple of days before that date ... Agreeing with some ideas from Alex Russell, Rich Harris found out that we are shipping too much code to the users. The reason for that is that we usually use powerful frameworks like React, Angular or Vue to build or applications. Even if we don't need everything from within the framework, still the whole framework is sent to the client.

That inevitably leads to:

1. A longer loading time for users. This is especially a problem when users have a slow bad network connectivity.

2. Lots of unnecessary calculations done in the browser which in fact leads to a bad UX for users who don't call the latest power houses of devices their own.

So what if we re-thought our whole approach of building frameworks that need to run in the browser and start building frameworks that let the developer think and write his code in the world of components and compile this code to highly efficient vanilla JS afterwards?

That's when Svelte 1.0.0 was born. There were lots of missing features but a stable 1.0.0 was released to prove the concept. And in fact a Svelte project was 3.6kb zipped compared to React's framework size 45kb zipped alone.

Fast Forward to April 18th 2018

We'll keep the part of Svelte's 2.x.x history very short. It was basically an update to Svelte 1 improving some parts, incorporating feedback and adding some features. Nothing too fancy. It is to be mentioned though that some of these changes were breaking. To help developers out the Svelte team also released an upgrader which left little to nothing to do for the developer to fix the breaking changes.

You break it, you fix it (nearly) as it should be.

Fast Forward to April 22nd 2019

Svelte 3 is released. With this new version came some significant - and again breaking - changes. This time the framework's revision went so far, that the upgrader couldn't keep track with it.

At the very heart of those changes was bringing reactivity to the heart of Svelte. I can not recommend Rich Harris' talk about that enough. If you haven't watched it yet, make sure to check out "Rethinking Reactivity".

The most prominent example of Svelte's approach to reactivity is the "API" to tell the computer the state changed and a re-render is necessary. Here it is:

awesomenessFactor += 1;

Great API design, isn't it? Where the API is you might ask. The answer is: Svelte is a compiler. More on that later.

Today, Svelte is still very actively being improved and developed. Also it is used by some major companies like the NY Times, 1Password and GoDaddy.

History lesson done.

Finally

How It Works

Now that we know a little about the origins of Svelte let's dive a little deeper in how it works. First and foremost, Svelte is a Compiler. This is the most crucial thing to understand. While using Svelte, whenever you encounter a behaviour that you don't quite understand, think about this simple sentence and it might become clearer.

Theory

Here's a very brief theoretical explanation before we dive into two concrete Examples:

Svelte is a compiler which takes your code, written under the constraints given to you by Svelte and translates this code into highly efficient vanilla JS.

Svelte Architecture

I really did my best on trying to make this look beautiful ... Please keep in mind that this is a very simplistic approach of explaining Svelte. Actually there's a lot more that happens.

1. You write code during development - obviously.

2. Svelte takes your declarative code and compiles that into different imperative code. This happens in a compilation step.

3. After you deployed the code that has been built by Svelte to a server only this code is sent to clients whenever it is requested. Therefore none of your, or Svelte's code really needs to be present at runtime.

Actually, let's keep it with this for theoretical explanation for now. Everything will become a lot clearer when we have a look at some examples.

The Virtual DOM and Diffing

To make this a little more obvious let's get back to our API example from above:

awesomenessFactor += 1;

This is what you write. What the browser will execute is:

$$invalidate(0, count += 2);

What happened?? Svelte translates - compiles - your code during compile time and wraps its invalidate function around your code.

The invalidate function not only marks the component in which it runs as dirty, but also marks the part that changed. What does that mean? That means during runtime Svelte does not need a Virtual DOM.

You've probably heard a dozen times that the virtual DOM is fast. That is not true. It is faster than using the real DOM when you need diffing to execute declarative code. But do we really need to execute code like that? Actually we don't. The only thing we want is thinking in those declarative component structures.

The virtual DOM is merely a by-product, necessary to execute declaratively written code. It is not a feature to speed up the code-execution. There are two main reasons why it is slow:

1. It is not free. Whenever a re-render is necessary, each element in the Virtual DOM has to be compared with the new state to check whether this specific part of the DOM has to be re-rendered.

2. Usually, there are some wasteful instructions in the render-method that have to be computed whenever a component is re-instantiated. Declaring Functions, basic calculations, stuff like that ...

As you see, it'd be a lot better if:

1. We could write declarative code using components.

2. Our code ran imperatively avoiding the usage of a virtual DOM.

To fill this gap, there is Svelte. It lets you do exactly that. You think in components and write declarative code. Svelte then does the heavy lifting of translating (compiling) your code into highly optimised and efficient vanilla JS code. This is then executed in the browser. Everyone is happy.

Happy

(Note: One example for imperative code is the invalidate function. This is an imperative call to mark a component as dirty. During the re-render the diffing is skipped, because all marked components are updated. Updated, yes, because the necessary change is known as well.)

A Sentence About Svelte's Feature Set

Here's another example of Svelte's behaviour as a compiler:

Many frameworks include only a bare minimum of functionalities because the framework devs are scared of oversizing the framework's bundle. If you need any kind of functionality, that is not supported by the framework of your choice, you have to go dig through npm and get some third party package.

Svelte actually brings a lot of features which you as a web developer usually need that are not included in other frameworks. Most notably the support of styling and animations. Still, the bundled packages fo your application are a lot smaller.

How is it possible that Svelte implements so many awesome features, some of which are missing in other frameworks, whilst still enabling developers to create so small application bundles in size, you might ask.

Svelte is a compiler. I don't know how often this has been written by now (and there will be more mentions of that). Applied to the aforementioned question that means Svelte as a compiler only puts those features in your package that you use. If you don't need them, the user doesn't want to load or process them.

In the end you can imagine that Svelte code isn't even sent to the browser. And neither is your code. That is not 100% accurate but it helps to understand where Svelte does its magic.

Phew, that was tough stuff... I hope you could follow along. If not, feel free to ask me any questions. I'll be gladly helping you out!

Further Projects

Svelte is no lonely stand-alone framework by any means. Since it's first release related Projects have been initiated and brought to production-readiness. All of them help us to tackle more complex tasks using Svelte.

Sapper

Sapper is to Svelte what Next is to React and what Nuxt is to Vue. In other words "Sapper is a framework for building web applications of all sizes, with a beautiful development experience and flexible filesystem-based routing." (Shamelessly stolen from: https://sapper.svelte.dev/).

The application framework Sapper uses the component framework Svelte. It adds many of the features that you'd want as a web developer which aren't in the scope of Svelte but you wouldn't want to implement all by yourself. Here is just a list of some of those features:

1. Server side rendering

2. Preloading

3. Routing

4. Build & Deployment Tools

Stay tuned for a future post in which I'm going to write about sapper in more detail.

Svelte Native

Svelte Native is a community project to build native Apps for iOS and Android. It is based on NativeScript and allows you to use your Svelte knowledge to build mobile apps. It claims to use the compile step as extensively as Svelte does it for Web Applications - other than React Native of Nativescript-Vue, both frameworks in which a lot is done on the user's device.

Since I have never used Svelte Native before I can't give you a full review here. Sorry for that ... If anyone of you has used or even brought an App to production I'd be happy to hear about your experiences in the comments of this post.

All Well And Good But Why Should You Use It?

1. Svelte is fast. Like really fast. As discussed earlier it doesn't need the virtual DOM at all. No diffing. No wasteful calculations in the render method. Nothing alike. It knows what to update and it does so very fast with highly optimised vanilla JS.

2. Svelte is not only fast once it's running in the browser. Also, its initial loading time is very short. Since it runs during compile time it only packages the code that is absolutely necessary to run the application. Everything else is skipped. Since Svelte's job is done during compile time - not run time -, Svelte doesn't even ship itself (for the most part). This is a huge advantage over other frontend frameworks like React or Vue.

3. We all love to code. But none of us really likes the code itself. Code is the source of all errors and bugs and therefore we all appreciate or codebase to be as small and concise as possible. Svelte helps us with that. If you compare similar components written in Svelte and React you'll see that Svelte has about 30%-40% less code. Why? The answer is the same as always. Svelte is a compiler and therefore sets its own restraints to give you some very expressive and concise syntax.

4. Svelte is component based. Just like React or Vue. You can apply the concepts, that you're used to. Therefore, it is easy to learn. Just go ahead and give the tutorial a try. It covers everything and takes you about 1.5 hours.

Ok Ok ... There Gotta Be A Catch

Catch

If you're thinking this is too good to be true, you might be right. It is not all gold that shines. But in my opinion Svelte is pretty close to the golden part. But I'm just here to give you all the facts that are necessary for you to make up your own mind and to create your own opinion.

Here's what I personally dislike:

Developer Experience

1. Even though Svelte is built using TypeScript, there is no first class TypeScript support for developers using Svelte yet. It'll sure be in the future, but if you can't live without it, Svelte is not for you.

2. As of today there are still many IDEs and Code Editors that do not have the amount and quality of extensions as there should be. If you're used to the pleasure of using React or Angular and want to get into Svelte be prepared to make some cuts.

Stability

3. In the blog post announcing the release of Svelte 3, Rich Harris states that "we're nowhere near finished". While the upgrader did a great job upgrading your projects from Svelte 1.x.x to Svelte 2.0.0 leaving very little effort for the developer, during the upgrade from 2.x.x to 3 there were various tasks getting your hands dirty. Rich's statement and the experience of the past make me expect future breaking changes to come which will bring extra-effort for you as a developer. Very not-so-fun effort it is.

4. AFAIK there is no official testing framework released by the Svelte team. There are lots of community tools though - Jest, Cypress, svelte-testing-library to name a few. Since testing is such an important topic I didn't want to leave this unmentioned in this post.

Community

5. Svelte is still young and not backed by any of the "big guys" like Google or Facebook. Therefore, it should be obvious that the community is a lot smaller. That means that you might have to google a lot if you encounter a problem. Or, different suggestion, try to solve the problem on your own ...

Mind blown

6. (Maybe) due to the size of the community, maybe also due to various other reasons, there are a lot less job openings searching for Svelte devs. This might change in the future but if you want / need to get hired now, go with React. Ok, this might be an opinion... but in my opinion it is a fact.

Summary

Today we had a deep look into Svelte and learned that it is more a compiler than a framework. Therefore, it allows you to write declarative component based code. This is then translates by Svelte into imperative code which enables omitting the virtual DOM.

In my opinion Svelte is a great way to build applications. It fixes a lot of the (very few) problems React has. It is faster during initial load and runtime and runs with less code. On the other hand, it still lacks support for Typescript, IDE- / Editor-extensions and the community is way smaller.

That's it for today. If you learned something and had some fun reading this please consider sharing this article and subscribe to my blog. I'll keep informing you whenever I publish a new article :)

Link Collection

To get you started, here are some Links that you can check out:

Svelte-Homepage: https://svelte.dev/

Sapper-Homepage: https://sapper.svelte.dev/

A great talk by Rich Harris about the ideas behind Svelte: https://www.youtube.com/watch?v=AdNJ3fydeao

Sveltes Github: https://github.com/sveltejs/svelte

Share this post