We took a step back and asked ourselves what kind of API would work for us… and realized that the best API is no API at all. We can just use the language.
(from "Rethinking Reactivity")
Svelte's primary value propositions
Let me start by laying out specifically how I see Svelte marketing itself, and I'll follow-up with how I feel about those claims.
Svelte isn't a framework
You “just” use standard web fare:
(from the first call-to-action on the Svelte homepage)
Svelte isn't a runtime
You compile ahead-of-time and deploy components which run with no dependency on Svelte:
(from the Svelte GitHub readme)
I find these claims to be misleading & there are a couple of things that make the whole approach unappealing to me. Neither are absolutely disqualifying, but they make me hesitate to recommend Svelte to people starting new projects or learning front-end development.
Svelte creates a split world by mimicking things familiar to you
So in order to avoid providing an API or framework, Svelte creates a split world where you need to always know which side you're on–is this code that will be interpreted directly, or compiled by Svelte? Your code looks the same on each side but acts totally different.
So whereas Svelte explicitly appeals to people on the principle of familiarity, this greatest strength hides a confusing trap.
Svelte has one runtime per component
Svelte markets itself as having no runtime: unlike React & friends, there is no code that's taking the data structures you create and turning them into a DOM, it's merely a tangle of JS code specific to each component that's doing the rendering directly.
What that means in practice is that you have a different Svelte runtime per component that's generated for you. You start from ground zero each time you find a production glitch of some sort; there's no single standard runtime that provides introspection & helps you mess with your data structure and see how that would render differently, or enables you to edit your code and see live how that changes things.
The way to change the behavior of a running Svelte app is to either A) abandon the logic you were working with when you created the component in the first place, instead working on the logical level of the generated JS code; or B) go back to your editor, make changes, pray, recompile your app, and reload.
While Svelte touts how it adds no extra complexity due to a runtime library, there's still the implicit complexity of understanding each component as it's actually implemented, and you don't get any of the niceties of a runtime to help you deal with that.
What I prefer instead
I like Preact. It's the exact same API as React, so I benefit from being able to
search for "how to do X in react" and get results that work for Preact too. But
the runtime is simpler & smaller and it's easy to get started without a bunch of
boilerplate and code generators like
create-react-app, which are endemic to
I like having an API that's not magical or disappearing, which I can use to do my rendering. I like that Preact can be used directly in the browser without any transpilation steps. I like that it plays well with other front-ends which may set event listeners on objects which React would usually clobber.
I am excited by the possibilities for compiled web apps which run on low-memory devices or achieve ultra-high-performance on powerful consumer machines. While I'm dissatisfied with Svelte's approach which mimics and munges standard web technologies, it seems likely to inspire the community to create innovative APIs which will allow us to build reactive high-performing compiled web apps with WebAssembly and Rust or TinyGo, and even with new languages like Crystal.
I also worry that Svelte may inspire a raft of copycat "no-API" front end systems which implement mutually incompatible semantics, each on top of normal-looking JS/CSS/HTML, further increasing the potential for "split world" headaches.