In the world of front-end JavaScript tooling, Svelte is one of the most exciting new options. It promises to clear away a lot of the cruft and indirection associated with other popular systems:

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:

Build boilerplate-free components using languages you already know—HTML, CSS, and JavaScript

(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:

[Svelte is] a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM.

(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

Svelte code looks like JavaScript, CSS, and HTML, but its compilation stage takes that and munges it totally out of recognition into a tangle of reactive JS code. What's running on the client does not resemble what you wrote; yet, where you're looking at it in your editor, it looks just like normal code. Your brain will tend to allow assumptions that would hold for normal JS/CSS/HTML.

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 React tooling.

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.

Looking forward

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.