Ever since I first used Svelte, there was something about it that felt very “natural”. Something about the way code in Svelte is structured just felt like it was the right way to do things when compared to other JavaScript component frameworks and libraries.
It has been difficult to put my finger on what it is about Svelte that makes it feel that way, but I’ve come to the conclusion that it feels like a natural extension of what HTML and CSS let you do - using it feels like speaking the native language of the web, instead of translating from a different language into the language of the web.
In this post, I’ll attempt to explain what this means, and why something like that can be important. I will use React as a point of comparison, but this is not a critique of React - I’m only using it to illustrate the differences.
What does “native language of the web” mean?
If you’ve studied foreign languages you might have noticed that certain phrases or idioms are hard to translate. For example, Japanese has many phrases which don’t really carry similar connotations when translated into English, even if the general meaning is understood. If you try to translate the phrase in a way that also carries the connotations, you end up with a more complicated and comparatively more clumsy sentence.
In a similar way, certain programming languages are good for expressing certain things, although opinions on this can vary. Haskell for example has great tooling for writing parsers, and it makes expressing those feel intuitive and easily understood. You can write parsers in a clear and concise manner, where in other languages it can require more code, and it’s often more clumsy.
I think Svelte is like this, except for writing frontend code for web apps: It allows me to build components in code which feels more idiomatic and more “native”, and tools like React feel comparatively more complicated and clumsy.
What does it mean for something to feel “native” for writing web apps? If you look at HTML, CSS and JavaScript itself, they are of course the natively supported languages. So when I speak of “feeling native”, I mean it feels like you’re writing code in a way that seamlessly fits the existing native languages.
Why doesn’t React feel native in the same way? I’ll try to illustrate this with some code examples first. Here’s a very basic HTML page:
<html>
<style>
p {
background: RebeccaPurple;
}
</style>
<body>
<h1>Hello</h1>
<p>text</p>
</body>
</html>To me, this is the “natural” and “expected” way the code for a web page would look like.
What does a React component look like?
export default function Example() {
return (
<>
<h1>Hello</h1>
<p>text</p>
<style jsx>{`
p {
background: RebeccaPurple;
}
`}</style>
</>
);
}It’s not too bad, and styled-jsx makes embedding CSS into React components reasonably nice.
What does a Svelte component look like?
<style>
p {
background: RebeccaPurple;
}
</style>
<h1>Hello</h1>
<p>text</p>The Svelte component looks like a regular HTML page. The React component looks clumsier in comparison: It looks like you’re trying to translate from JavaScript into a web page, where the Svelte code just… is a web page.
Even in more complicated cases where you add scripts and template logic into the Svelte component it feels more native. For example, if we have a basic script in a HTML page:
<script>
function thing() {
alert('hello');
}
</script>
<button onclick="thing()">click</button>And the same in Svelte:
<script>
function thing() {
alert('hello');
}
</script>
<button onclick={thing}>click</button>It’s almost the same.
Some others like Vue get fairly close. Syntax-wise, Vue is pretty similar, but it doesn’t feel quite as if you were writing a regular web page due to how their code is structured.
It does make me wonder if it’s maybe just me? I’ve been building web apps for such a long time, that writing plain HTML and CSS is the “normal” way for me, because I did it for a long time before any of the modern fancy frameworks existed. Because of this, something that more closely resembles HTML and CSS feels like the “web way” to me.
Why does this matter?
It’s somewhat challenging to attempt to explain this. The difference to React is not huge, and one could argue that it’s somewhat subjective - one uses a HTML-style syntax, the other uses a JS-style one, and if you prefer one style over the other that explains it. But I think there might be a bit more to it than just that.
I think the reason why Svelte feels like a native part of the web language stack is that the mental model of Svelte code closely matches the mental model of “plain” HTML/CSS/JS web pages. This reduces the cognitive load, because there’s less “translation” to do, and it also helps us architect our code better.
When you write components like in Svelte or React, ultimately they end up being a part of a web page. If the mental model of the component code matches the mental model of a web page, then there’s a smaller disconnect between the two, which means there’s less cognitive load.
In a web page, everything is defined within the boundaries of the HTML markup. The markup defines the page, and it defines the scope for scripts and styles. Any scripts and styles on the page directly affect the markup and they work in context of the markup. This model matches Svelte’s model. In contrast, in React everything is defined within the boundaries of a JavaScript module, which defines the scope for scripts. This module contains a function which eventually returns JSX, which defines the scope for the markup and possibly styles. The module could also contain other things besides this.
We could compare this to writing SQL queries and using ORM tools. Many ORM’s provide an object-oriented way to build queries, which often feels more clumsy than writing SQL directly. This seems to be the result of the difference in the mental models. Some ORM’s provide a SQL-like language, such as HQL or DQL, which feels much more fluent - because it maps much more closely to the mental model of SQL.
As far as I can tell, the main contributor to this difference is the level of abstraction. Svelte is on the same level as HTML - Svelte’s abstraction is for most intents and purposes transparent, and you can think of Svelte code as if you were thinking of a regular web page. React on the other hand is on a lower level of abstraction. This contributes to the cognitive load difference.
The most noticeable effect of the abstraction level is that Svelte has no boilerplate. When you write a Svelte component, you just write the HTML you want. You don’t have to write any surrounding JavaScript code, like you would in React. This leads to simpler code which communicates intent more directly, because you can just directly express what you meant.
As a side note - If we’re thinking only of JSX, we can mostly treat it the same as HTML, similar to Svelte. But the abstraction difference is all the machinery around JSX, and to some degree JSX itself as well, because it allows you to do things like embed more complex JavaScript expressions into itself.
I think this difference in the mental model and abstraction affects what kind of code we write, although you might not really notice it when you’re programming. HTML is inherently somewhat limiting in what it lets you do, so you need to use different kinds of solutions than you might use when working in JavaScript.
For example, if our component starts becoming complicated, React offers us multiple options. We can move some JSX into a separate function, we can move some JSX into a variable created within the function, or we can extract it into a new component altogether. In Svelte, our choices are slightly more limited. We can create a snippet (which still lives within the markup), or we can create a new component.
This means the code ends up evolving in a different way. Because of its design choices, Svelte guides us towards creating new components. This seems like a good thing, because it makes you think more about how you architect your component structure, which leads to code that’s easier to maintain.
So in other words, if the tools we use match the mental model more closely, it both reduces cognitive load, and guides us to make better choices when we write code.
When code feels natural it’s more enjoyable
When I work directly in HTML, my imagination starts creating structures, semantics and pictures of the CSS styling in my mind, which helps me understand the code I’m working on better. I think this is the result of having a tool which better matches your own mental model, and the mental model of the program. When there’s less cognitive load from the tooling, it just feels more like a breeze, and you don’t have to come up with workarounds just because the tool doesn’t fit the task.
I think the design and features of Svelte achieve exactly this result. Svelte removes boilerplate, and lets us work directly on the same level as writing web pages with plain HTML, CSS and JS would, and at the same time, it lets us have the advantages of a modern component-based framework.
This is not to say Svelte does everything perfectly. There are some aspects which feel a little off, such as using $props() to read the component’s properties.
<script>
let { a, b, c } = $props();
</script>It’s not bad, but it feels a bit strange to just pull a bunch of values out of $props() like this.
The way this functions in React feels much more intuitive in context of its abstraction:
function MyComp({ a, b, c }) {
}React has a very sensible implementation, where you simply get the props as parameters to the component. It’s difficult to say how this could be fixed from Svelte’s perspective, since HTML itself doesn’t have any mechanisms suitable for this. Svelte’s rune system in general feels a little bit more complex than what it used to be before they introduced them, but the trade-off gained in clarity seems worth it.
I think trying to understand these kinds of differences is useful in allowing us to build better tools and libraries. Something that is more intuitive is more enjoyable to use, and if its abstractions match what we’re working with, it should lead to better overall software as well.
Frankly, I’m not sure if I’ve really managed to give this topic as a thorough analysis as I would have liked. One of the challenges in writing about software for me is that subjects I find interesting, like this, I also find rather challenging to truly elaborate on in detail. If you agree, disagree or have any other thoughts on the topic of this post, I’d be curious to hear.
Comments or questions?
If you have any comments or questions about this post, feel free to email me to jani@codeutopia.net, or use any of the other methods on the contact page.