Why Svelte is not ready for prime time just yet (and why it’ll be awesome once it is)
Tags: svelte, react, vue
Published: 2020-11-14 16:34:47

Spending the past couple of weeks using Svelte for a personal project, I’ve been pretty happy with it, although there’ve been some hurdles along the way. This article aims to explore the issues I’ve run into, as well as what’s so great about Svelte — all based on that couple of weeks experience. If you’re a Svelte newcomer or are trying to get a better overview of the current JavaScript frontend frameworks, this article might help you.

# What is Svelte
Chances are you’ve already heard about [Svelte](https://svelte.dev/) /svelt/ if you’re reading this, so just a quick recap: Svelte is a _language_ and a _compiler_ for creating modern web apps. Think of it as the new React/Vue. It still uses HTML, CSS, and JS to create apps, but there’s a radically different approach to how the tool internally works.

![Svelte](https://dev-to-uploads.s3.amazonaws.com/i/1p1c2jr5eprhu1xpghym.png)

_Haven’t heard about Svelte yet? [Watch this awesome talk](https://www.youtube.com/watch?v=AdNJ3fydeao) by Rich Harris, the author, where he demonstrates how Svelte works and how it’s different from the other frameworks._

# The bad stuff
Let’s get to my experience now, starting with the bad stuff.

## TypeScript source maps

TypeScript support arrived to Svelte in summer, so not a very long time ago, and it shows. I can’t put this delicately, so… the source maps totally suck if you’re using TypeScript (you should be if you’re being serious about writing an app). The line numbers don’t match and most of the lines you can’t put a breakpoint on at all.

There’s already an open [pull request](https://github.com/sveltejs/svelte/pull/5584) for getting the source maps on par with JavaScript, but until that gets merged, you’re stuck with using `console.log` and `debugger` statements to debug your code.

## No eslint when using TypeScript

This is another bummer, you can’t use eslint if you’re using TypeScript, since there’s no support for preprocessors (TS) in the eslint Svelte plugin yet.

Again, there’s already a [pull request](https://github.com/sveltejs/eslint-plugin-svelte3/pull/62) to add the support. So beware of those `target=”_blank”`s until then.

## Community size

Being youngest of the bunch, it’s seeing a much smaller adoption than the older frameworks. It’s growing, especially in 2020, but not as fast in absolute numbers as for example Vue, so it seems like it has yet to gain momentum.

![Weekly downloads of React, Vue, Angular and Svelte in the past 6 monts.](https://dev-to-uploads.s3.amazonaws.com/i/taens38nkdt367yygoaf.png)
_↑ Weekly downloads of React, Vue, Angular and Svelte in the past 6 monts. Source: [NPM trends](https://www.npmtrends.com/react-vs-vue-vs-@angular/core-vs-svelte)_

![Weekly downloads of Svelte in the past 5 years.](https://dev-to-uploads.s3.amazonaws.com/i/zxqqw027c1y1a766vhq1.png)
_↑ Weekly downloads of Svelte in the past 5 years. Source: [NPM trends](https://www.npmtrends.com/svelte)_

This, of course, has some implications:

* There are much fewer components designed specifically for Svelte, compared to the other frameworks
* The PRs take quite some time before they get merged (partially also due to the core team being small)
* You probably won’t get a fast response to your StackOverflow question (mind that there’s a [Svelte channel on Discord](https://discord.com/channels/457912077277855764/506988048375087114) where you can get help from a bunch of really nice people though!)
* And most importantly, one can’t be sure if Svelte is going to survive in the long term.

_Side note: Seems to me that React with its hype has de facto become the new Java for frontend (it grew very fast, as it had no competition, so now we have almost no choice but to stick with it). Vue is growing only very slowly and isn’t going to catch up with React anytime soon. Svelte is just a dwarf right now._

![Weekly downloads in the past year, Svelte (red) vs Vue (blue). Please note the numbers are on a completely different scale and there are many factors that can affect them. Still, we can see that the curve is steeper in case of Svelte (red), which means Svelte is growing faster than Vue (blue) in relative terms.](https://dev-to-uploads.s3.amazonaws.com/i/1tubdmgxm0hdrzeliy32.jpeg)
_↑ Weekly downloads in the past year, Svelte (red) vs Vue (blue). Please note the numbers are on a completely different scale and there are many factors that can affect them. Still, we can see that the curve is steeper in case of Svelte (red), which means Svelte is growing faster than Vue (blue) in relative terms. Source: NPM trends ([1](https://www.npmtrends.com/svelte)), ([2](https://www.npmtrends.com/vue))_

## Stuff confusing to a newcommer

There are currently at least two official ways of bootstrapping a Svelte app. One is to use a [template](https://svelte.dev/blog/the-easiest-way-to-get-started#2_Use_degit), the other is to use [Sapper](https://sapper.svelte.dev/). There isn’t a clear explanation of what to use when. From what I’ve learned:

* If you’re building an SPA, you’re best off by using the template + a router like svelte-spa-router
* If you’re building an SSR app, you’ll want to use Sapper (it’s something like Next.js)

But, there’s more. Sapper is still version 0.x ([the team claims it can be considered production-ready though](https://sapper.svelte.dev/faq#version-numbers)) and version 1.0 is [coming… never](https://www.youtube.com/watch?v=qSfdtmcZ4d0). That’s because Sapper is going to get replaced by Svelte Kit.

Svelte Kit will unify the way Svelte apps are created, use a super-fast build tool, and be mostly compatible with apps already written using Sapper. So, it’s something to be excited about if you’re a Svelte/Sapper developer. For newcomers though, this can be confusing.

# The good stuff

With the bad stuff out of the way, let’s get to the good stuff.

## The tutorial and REPL

Svelte has an [awesome tutorial](https://svelte.dev/tutorial). Following it, you’ll learn everything you need to know about it in a day or two. There’s also a great [REPL](https://svelte.dev/repl), where you can try various things out, and even download the result with everything you need to get it up and running.

If you’ve spent the last few years writing React code like me and you’ve ever seen a Vue single-file component (SFC), you’ll feel right at home coming to Svelte thanks to that tutorial. So dive into it if you want to see what the syntax looks like.

## Single file components (SFCs)

Do I have to say more? :) Single file components are just awesome. If you ever used Vue’s SFCs, you know why. All related code is in a single place, it allows you to prototype quickly, and you don’t have to worry about styles messing with each other.

With Svelte, this is the default. And the experience is IMHO a little bit better than in Vue, as there’s literally no boilerplate at all, you start at 0 indentation, and styles are scoped by default. Let’s see what a typical hello world would look like:

```
Hello world
```

Yup, even that’s a component in Svelte and it’ll render exactly as you’d expect! As you can see, I wasn’t kidding, zero boilerplate.

Let’s see something _a little_ more complicated with some JavaScript and styling:

```
<script>
 let something = "hello";
</script>

<style>
 p {
  color: purple;
  font-family: 'Comic Sans MS', cursive;
  font-size: 2em;
 }
</style>

<p>This is a {something}.</p>
```

Which will render as:

![This is a hello](https://dev-to-uploads.s3.amazonaws.com/i/6iv6tbvu5f9jc0ahvifj.png)

In contrast, just think how many tabs deep you start writing a typical React component, and what you need to do to set up its styles…

## Batteries included

Svelte also comes with _stores_ for application state management, and _motion/transition_ tools to make creating animations easy. It also has a class directive, slots, special elements, etc. Basically, if you’re building an SPA, there’s everything you need except for a router (see above). So, almost no decision fatigue.

## No virtual DOM

It wasn’t until I started using Svelte that I realized just how much I actually hated the virtual DOM. We’re building user interfaces, yet we’re putting this abstraction layer between us and the user interface. Why? For a brief moment, just stop and think if you really, really _need and want to use_ a virtual DOM, or if you _ended up_ using it just because it came with the library.

Virtual DOM has many disadvantages ([performance](https://svelte.dev/blog/virtual-dom-is-pure-overhead), difficulties accessing the DOM directly to name a few), yet probably the only real benefit was supposed to be that you could write declarative user interfaces that have a predictable state. Has it managed to fulfill that promise? Based on my experience, I’d say only somewhat. It’s definitely easier to do certain stuff via the virtual DOM than having to manipulate the DOM directly. At the same time though, and in the case of React, I’ve seen so many badly written pieces of code (some of those mine) purely because it gives the programmer so much power, that I seriously doubt that it has this benefit in general.

Svelte, on the other hand, gives you a set of tools that ease DOM manipulation, like if statements, loops, bindings, events, or slots. All of that being converted to human-readable pieces of JS ([check the JS output tab here for an example](https://svelte.dev/repl/833be1bf5ced46ef986917c2508d5c3c?version=3.29.7)) during compile time. It’s what you _really_ need in the vast majority of cases.

The simplicity of Svelte with the combination of a clear separation of HTML, CSS, and JavaScript is what makes it really shine. In fact, it’s what the web was built for.

Also, since you have direct access to the DOM with Svelte, you’re not restricted to using framework-specific components. And, since you won’t be running into any quirks as in the case of a virtual DOM, you’ll easily manage to write most of them yourself, if you want to.

Finally, because Svelte doesn’t use a virtual DOM, and in fact any runtime at all, it’s [really fast](https://youtu.be/AdNJ3fydeao?t=1140) and the bundle size you’re starting with is extremely small.

## Snowpack + Svelte = productivity heaven

Ever heard of [Snowpack](https://www.snowpack.dev/)? It’s an insanely fast frontend build tool, which creates ES modules instead of a bundle for development. Near-instant dev server start times and hot loading is what you get with it. And you can use it with Svelte. And unlike with React, the hot loading works reliably. Seriously, just try it out. You’ll never want to go back to Webpack again. I would even go as far as calling it revolutionary. But you don’t have to belive me, just watch Rich Harris’ demo at 5:08, my experience has been exactly the same so far:

{% youtube qSfdtmcZ4d0 %}

# Conclusion

So, what’s the takeaway here? Based on my about three weeks’ experience with Svelte, I believe that it’s currently an awesome tool for prototyping, or hacking together small apps (where you don’t need great TypeScript support or can live with the few flaws). Basically, anything where you need to be productive as quickly as possible, and you know you can throw it away or afford to rewrite it into React, Vue, or Angular anytime if you don’t like it.

Personally, I think Svelte is slowly becoming what Vue should have been — a modern alternative to React. Once it matures a little bit more and gains traction, it might just be the default choice over the other frameworks.

…or (drum roll, please), you know, it might just happen that the other frameworks borrow Svelte’s ideas and Svelte becomes erased from history like a bazillion other JS frameworks/libraries 😂 We’ll have to see. For now, I’ll keep exploring Svelte on a personal project I’m working on, while sticking with the safe bet — React, for projects that require more than a single developer.