For a long time, there were only three major contenders for the title of “the best JavaScript UI framework” - React, Vue, and Angular. Each one of them comes with its own unique set of features, use-cases, target audiences and general mindsets on how things should be done.

These frameworks have dedicated 3rd-party tools, libraries, and often entire communities of their own. For example, ButterCMS offers dedicated SDKs and APIs for Vue making the headless CMS integration process much easier.

But what about emerging players, like Svelte - a framework that offers high performance and improved development experience? How does it compare to an established player like Vue?

Let’s start with a quick overview of both frameworks.

You most likely already know Vue. It’s one of the most popular, open-source JavaScript UI frameworks out there. It’s been actively developed ever since its introduction in 2014. With its vast ecosystem, open community and v3 on the horizon, even now, Vue doesn’t seem to slow down.

Svelte is a much younger framework (introduced in late 2016) that only recently has started to gain traction. It’s one of the first, but certainly, the most successful tool that introduces the idea of compilation to modern UI frameworks. It aims at achieving high performance and smaller size of production code while providing equally comfortable development experience.

Toolchain and workflow

When choosing a framework, you certainly look at metrics such as performance, ecosystem, community support and etc. But there are other, arguably less decisive factors, that will go on to heavily influence your development experience. Those include the framework’s workflow, templating syntax and API - all the features needed to properly utilize the framework's potential later on.

Svelte and its compiler

The very thing that’s so unique about Svelte is that it’s basically a compiler. With its own templating syntax and an API to go along with it, Svelte makes for a very smooth and efficient development process.

Take a look at the source code of a basic counter written with Svelte, taken right from its website:

<script> let count = 0; function handleClick() { count += 1; } </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? 'time' : 'times'} </button>

This simple example illustrates well the most important concepts that you’ll be dealing with most of the time while using the framework.

What you see above is a Svelte component - a superset of HTML contained within a single .svelte file. Such a component consists of 3 sections:

<script> block containing JavaScript code that utilizes Svelte’s runtime API and manages the component’s state and properties through local variables and functions.

<style> block for declaring the CSS styles for the component, all are all scoped by default.

the actual template itself, utilizing HTML with a dose of Svelte’s own tags , directives , and expressions . The template isn’t required to have a single top element like in many other frameworks.

All 3 sections of Svelte’s component are optional and can be placed in any given order.

With this little context, you should be able to easily understand what’s going on in the snippet above. That’s important, as a good framework shouldn’t get in your way or have a steep learning curve. Of course, that also doesn’t mean that Svelte has nothing new to offer. Reactive stores, transitions, animations, easings, etc. are all the goodness that comes in a form of Svelte APIs.

Vue’s toolchain

In comparison to Svelte, there’s no compiler to talk about when it comes to Vue. Everything is done client-side and processing that happens on the development machine is limited to optional single-file .vue components.

An advantage of such an approach is just how quickly you can start coding. Just open your code editor or even the simplest online playground, load Vue from CDN and you’re ready to go! However, there are a few misconceptions here. Most importantly, you’re unlikely to use or even want to use Vue without any additional tooling. For example, Vue’s single-file components ( .vue files) greatly improve development experience but require a proper setup - just like Svelte's compiler.

As for the disadvantages, it’s easy to say that you're simply losing on a compiler. No performance optimizations, no local variables based state, no nothing!

But let’s put that aside, as a good framework isn’t only determined by having/not having a compiler, but also a vast set of other features. Here, Vue really shines, with many battle-tested features, rich templating syntax and other functionalities demanded from today’s state-of-the-art framework.

Now, take a look at Vue’s single-file component syntax of the same counter component as before with Svelte:

<template> <button @click="handleClick"> Clicked {{count}} {{count === 1 ? 'time' : 'times'}} </button> </template> <script> export default { data() { return { count: 0 }; }, methods: { handleClick() { this.count++; } } }; </script>

What’s interesting is that Vue’s templating syntax is quite similar to Svelte’s or rather the other way around. What that means is that you’ll have less of a learning curve when transitioning between the two.

But apart from the template itself, the Vue component also contains <style> and <script> and while the first is mostly the same, the second one differs vastly from Svelte’s. There’s no local variables-based state and functions, but the data and methods properties, within an exported object. It's simply a bit more verbose. Which one you prefer depends only on your personal preference.

With this bit of context about the workflow and features of both frameworks, it's a good time to discuss their performance. As you might know, most of the current frameworks come with promises of being “blazing-fast” while not compromising on quality. Do Svelte and Vue deliver on these promises?

Performance

It’s hard to reliably measure the framework’s performance. Modern devices are so fast that they make most of these tiny performance differences really hard to notice. Besides, most frameworks are quite fast anyway.

But this doesn’t mean that performance is an irrelevant or immeasurable factor. Demanding applications like games and usual websites targeting low-end devices have to take performance seriously and as for the measurement - benchmarks do just fine.

For our purposes, we’ll use an open-source benchmark that involves rendering a large table. The benchmark covers a lot of different, actively-developed frameworks, and its source code is available on GitHub. There’s also a website containing the benchmark’s latest results, which we’ll make use of, as running the whole thing takes a while.

In the table, we’re looking at the keyed implementations of the respective frameworks. These connect DOM nodes to certain keys making them re-render only when the given value change.

So, in the table, we see neither of our frameworks at the top, but after a scroll or two, we can finally notice a big gap between Svelte (v3.18.1) and Vue (v2.6.2). With quick math, we can determine that Svelte is generally about 30% faster than its competitor. That’s quite impressive!

But numbers don’t matter much in real-world use… or do they? Well, if we’re considering running the benchmark on our own as real-world use, then they do... somewhat.

I downloaded the benchmark and followed the guide from the repo to set up the tests for the two frameworks of interest. I haven’t done it for the numbers, rather than just to get a feeling of how the benchmark performs from the perspective of the end-user.

I played with the available tasks a little bit to compare the “real-world” performance side-by-side. The results were about as I expected - hardly any difference was noticeable. This 30% started to appear when rendering/updating a 10K row table in “low-end” throttling mode (27s/11s vs 25s/9s) but only barely. So, unless you’re making a really big app with thousands of elements or something like a game where every bit of available performance matters, this “sheer performance” metric shouldn't matter to you much.

Memory consumption

So does it mean that this whole compiler is just a gimmick? Absolutely no! This little experiment demonstrates how easy it is to fall into the trap of “raw performance” kind-of metric. There’s a lot more to take into account - an example of which is memory consumption.

Even though modern devices are quite powerful, they still have limited memory. And so, when your web app starts to hog it because of e.g. a memory leak, even though there’s no limit on how much can be taken, 1GB would be more than enough to crush the web browser (or even the whole devices) of most of the users.

But 1GB is rather on the extreme side as with frameworks themselves, we’re usually speaking about “mere” MBs. More specifically, with Vue for example, we’re talking about 1MB/22MB with only the benchmark UI and 10K rows being rendered respectively. That’s a reasonable amount for what it is, but still much higher than Svelte’s score of 0.9MB/9.4MB!

So, now we see the Svelte’s compiler truly shine. Because it tries to bring your code closer to vanilla JS, it also reduces the memory use along the way! Naturally, both frameworks pale in comparison to vanilla JS (0.85MB/2MB), but Svelte is halfway closer!

By the way, all the memory measurements here are coming from my machine, using the Memory Profiler included within Chromium DevTools.

You can do the experiment yourself by downloading the benchmark and using your own web browser or simply check the “Memory allocation” section on the benchmarks results website for less demanding tests.

Bundle size

So the memory consumption starts to show us the advantages of having a compiler on board. Svelte wins by over 2 times when compared to Vue. It’s really promising and it isn’t even a metric that’s heavily advertised by the framework itself. This leaves us wondering - what are the numbers when talking about bundle size?

Here, Svelte simply crushes Vue with a 10x smaller output! From our little benchmark app, we’ve got Vue output of about 72KB vs Svelte’s 7KB! It’s an unquestionable victory!

Now, keep in mind that bundle size is one of the key advantages of having a compiler. It’s almost an unfair comparison as Svelte can cherry-pick only the required pieces of code to include, while Vue has to be loaded in its full glory. However what’s fair and what’s not doesn’t matter when we’re left with a smaller bundle and thus faster loading times!

Ecosystem and user base

At this point, it might seem like Svelte is simply a superior option, right? Equally nice syntax, better performance, lower memory consumption, and bundle size - where’s the catch? Well, you probably already know the answer - it’s the ecosystem!

Vue’s edge

A single reason why no new framework, no matter how much better it is, can’t compete with the currently established options is because of the related ecosystem. The whole community won’t shift to a new option overnight, no new tutorials will be made, no new articles will be written, no new jobs will be created and no new component libraries will be available (although web components aim to change that). You get the point.

Although the timing difference between the introduction of Vue and Svelte isn’t that big (about 2 years), Vue has a great lead over its competitor here, and I can confidently say that it’ll keep it for the foreseeable future.

Bottom line

Svelte doesn’t have the ecosystem required to rival Vue however it has been rapidly growing in popularity. With its friendly syntax and API, impressive performance and rapidly growing community, Svelte is very likely to challenge the top 3 in the near future. However, in the meantime, it’s mostly a choice for independent web developers that can choose any framework they want and aren’t afraid to deal with writing most of the code on their own.

Vue is the safer bet. It comes with a lot of third-party libraries, components, and dedicated support from many services. It might not have as impressive performance as Svelte, but it's still decent and the sole popularity of the framework is what matters to most web developers. Also, with v3 on the horizon, the situation for Vue seems to only get better!

Lastly, keep in mind that there are many great open-source frameworks available and exploring them allows you to learn new concepts and gaining experience. So, keep exploring!