Sodeeq Elusoji Software developer | entrepreneur | table tennis player

Should you use Svelte in production?

3 min read 1062

The Svelte logo against a background of the sky and a building.

Introduction

“Svelte is a framework without the framework” – Svelte as defined by Svelte.

Hold on — what does that even mean?

The rise of Single Page Applications (SPAs) have seen us move a lot of logic and functionalities into the frontend of our web apps. Most of the operations that were usually done server-side are now being done conveniently on the client-side.

It was always only a matter of time before we wouldn’t be able to handle all of that complexity with vanilla JavaScript. This need to handle and hide away complexity led to the rise of the JavaScript frameworks we see today.

Of course, this came with its own costs, too.

These frameworks, seeking to fill the lapses in the JavaScript language itself, gave us a lot of shiny new “things”. Things such as data binding, easier DOM manipulation through DOM diffing, state management, and conventional architectures, to mention but a few.

But again, at what cost?

Before you attack me for painting frameworks as evil, I should point out that I am a heavy framework user myself — Vue.js especially. But sometimes, it feels like the frameworks do much more than we need, and to be honest, this can also be considered a problem.

Luckily for me, I came across Svelte not long ago and tried it out on a production project. It was exciting. So, here I am, preaching the Svelte gospel.

So, what is Svelte?

Frameworks like Angular, React, and Vue run in the browser, in the sense that whenever you run an app created using any of these frameworks, the framework is first booted before your own application code is executed.

We made a custom demo for .
No really. Click here to check it out.

This is disadvantageous in two ways. First off, the size of exported to production will usually be heavier that it should. Because both the framework code and your application code are being exported. Secondly, there is an initial delay in execution (during the phase when the framework is being booted). Although, on subsequent execution, things get faster.

Svelte helps us solve the two problems stated above.

But, how does it do that?

Svelte is a framework (and compiler, actually). It compiles HTML, CSS, and JS code at build time (during build process) into “small” and standalone JavaScript code.

By doing this, no extra framework is shipped to users of your application — just your own business logic.

Comparison to other frameworks (performance & bundle size)

Asking you to start using Svelte in production is a lot, I know. But I will outline the reasons why you won’t regret making this decision. To understand some of the gains of using Svelte, I will show you a benchmark test of how Svelte compares to other established frameworks. We will be benchmarking Svelte against Vue.js, React, and Angular:

Startup metrics of Svelte versus other frameworks.
Fig 1: Startup metrics of Svelte against other frameworks

From Figure 1 above, we can see that when it comes to time to interactivity and total bundle size, Svelte is a clear winner.

Memory allocation of Svelte versus other frameworks.
Fig 2: Memory usage of Svelte against other frameworks.

From Figure 2, in terms of memory usage, you can clearly see that Svelte comes out on top.

This benchmark test was conducted using Krausest’s framework benchmark tool.

Popular sites using Svelte

If you’re deciding to start using Svelte in production, you can be sure you are not alone. There are many established companies already using it too.

Below are some popular companies using it:

Namecoach, Rakuten, 1Password, The New York Times, Creative Tims, mail.ru

You can find more sites already making use of Svelte in production on svelte.dev.

Should you use Svelte in production?

Svelte promises a good developer experience. These are some of the benefits you get to enjoy when you make the switch:

  • Minimal learning curve: Svelte prides itself on being incredibly easy to learn. Because you write Svelte components with the usual HTML, CSS and Javascript, you can get started writing Svelte apps in about 5 minutes.
  • Speed of execution: As mentioned earlier, Svelte is a compiler, and as such, during the build process, your Svelte components are converted to vanilla JavaScript code. This helps avoid the overhead of booting or bootstrapping a framework before code is run in the browser.
  • Component-based app development: If you have used the other frameworks at some point, you’ve probably seen how helpful creating reusable components in an app can be. Svelte is also built with this approach at its core.
  • Can be used to build the entire app, or used incrementally: Just like Vue.js, you can either build your app entirely using Svelte, or just add it to some parts of your application.
  • Scoped styling out-of-the-box: With scoped styling, you can style a component without worrying about the CSS leaking to other components.
  • Comes batteries-included: State management, templating, server-side rendering, plugin system, and animations are some of the many tools that come with Svelte right out of the box.
  • A growing community: Even though Svelte is still a relatively new framework, its community is already growing rapidly. You can join in on discussions about Svelte on Discord, and there are also over 1,000 questions asked on StackOverflow.

Why not?

If you’re still asking, “Why should I use Svelte in production?” at this point, I’ll ask you a better question. Why not?

No major backing (yet)

Vue.js and Angular are strongly backed by Google, while React is backed by Facebook. Svelte doesn’t have a major company behind it at the moment, hence it is still low in popularity among companies and developers.

Small community

Because Svelte is quite new, it doesn’t yet have the kind of big community and developer fans that other frameworks enjoy.

Tooling and packages support

When it comes to developer tools and packages, there are currently limited options available for Svelte developers to choose from. But as the community grows and more developers start to find Svelte amazing, this problem will fade out.

Conclusion

Throughout the course of this post, we have looked at both the pros and cons of the Svelte framework. Without a doubt, the pros outweigh the cons.

In as much as Svelte might not be the perfect solution to every single problems you may have as a developer (nothing is, anyway), it has a lot to offer. And this is only the beginning.

: Full visibility into your web apps

LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

.
Sodeeq Elusoji Software developer | entrepreneur | table tennis player

2 Replies to “Should you use Svelte in production?”

  1. Great article. It definitely makes me interested in checking out Swelte – at least to learn a new technology.

    One question though: Why are you using Angular 8 as a benchmark? We are now ok Angular 11. As of Angular 9 there is a new rendering engine for building and serving the app that significantly reduces all of the metric in the charts. I am curious to see how much better Angular now stands in comparison. Especially when coupled with Module Federation in Webpack 5 this will only make the size and speed much smaller.

  2. If i ignore performance and I want it for a side project and the most important aspect is simplicity of development and large ready made component base, and I have no experience with frontend which one would be the best to pick?

Leave a Reply