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 /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.
Haven’t heard about Svelte yet? Watch this awesome talk 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 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 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. Source: NPM trends
↑ Weekly downloads of Svelte in the past 5 years. Source: NPM trends
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 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. Source: NPM trends (1), (2)
Stuff confusing to a newcommer
There are currently at least two official ways of bootstrapping a Svelte app. One is to use a template, the other is to use Sapper. 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) and version 1.0 is coming… never. 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. Following it, you’ll learn everything you need to know about it in a day or two. There’s also a great 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:
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, 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) 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 and the bundle size you’re starting with is extremely small.
Snowpack + Svelte = productivity heaven
Ever heard of Snowpack? 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:
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.
Top comments (2)
I was excited about Svelte a year ago. After playing around with Sveltekit, trying out the community and checking out the ecosystem I decided it didn't really look ready for production projects. I'm a bit surprised to say I just checked in and it seems not much better a year later.
I believe the blockquote in the docs said the same thing about early development a year ago when I checked. It's too bad because the project really excited me, but after getting errors practically in every Svelte starter I cloned (the errors being more difficult to decipher than other frameworks imho), I'm gonna have to head back to Nuxt or one of the bigger frameworks for now and check back again later.
Like I said in the article, I think it depends on what you want to use it for. I don't think there's a better tool for prototyping or building small SPAs than Svelte right now. Then again, I wouldn't use Svelte for a huge project, or even for a project with more than a single developer, which I'm guessing is your case :)
As for the lack of solid Next.js-like solution - there is Sapper, which has a lot of features that Next.js has. But, of course, it doesn't have all the features, not even Nuxt.js has them. And it probably won't change unless it sees a massive community growth.