The hype surrounding Svelte right now is inescapable. Every blog post comment section, the article comment section on Dev.to or Twitter thread/hot take seems to solicit a response about Svelte.
If you are not familiar, Svelte is a Javascript library which leverages a compiler to turn your Svelte code into plain old Javascript and HTML. You write your applications inside of .svelte files and they get compiled to something that has no runtime.
This puts Svelte into a similar league alongside Elm, Imba and a few others, not directly in line with React or Vue. However, being compared to React or Vue seems to be unavoidable in 2019 and will continue to be the case into 2020 and beyond.
In many ways, Svelte is an indirect competitor to the likes of React and Vue, both options which like to tout their small bundle and application sizes. On that front, they can’t compete with Svelte.
Where Svelte differs from other options like React and Vue is that it does not have a virtual DOM, no runtime or anything else non-standard after it is built. Syntactically, your applications end up looking like old-school AngularJS and Vue syntax and a little sprinkling of React’s JSX syntax thrown in:
<button on:click={handleClick}>A lot of the examples you will see for Svelte highlighting its simplicity are not indicative of real-world applications. This rings true for many framework and library examples, showing as little code as possible. You don’t want to scare away users.
Where things start to look less HTML and Javascript-y is things like loops or conditional each statements. The following is an example of iterating over an array of users.
<ul>
{#each users as user}
<li>{user.id}: {user.name}</li>
{/each}
</ul>If you have ever worked with Handlebars templating in Javascript before, then this syntax will take you back to the mid-2000s right away. This is one example of a few other uses which also resemble Handlebars in Svelte.
Syntax aside, it is by no means a large criticism of Svelte. Every framework and library deals with looping over collections differently, except maybe for React and JSX which the community mostly uses a map to loop over items in collections.
In React’s JSX you will find the following approach is the most widely used:
<ul>
{users.map((user, index) => {
return <li key={index}>{user.name}</li>
})}
</ul>I actually would have loved to see Svelte adopt Aurelia’s approach to syntax instead of going down the path of Vue-like syntax and throwing in that Handlebars syntax.
In Svelte binding the value of a text input looks like this:
<input bind:value={name} placeholder="enter your name">And in Aurelia, binding a text input value looks like this:
<input value.bind="name" placeholder="enter your name">
I realise my Aurelia bias is starting to show here, but in my opinion, I think the Aurelia approach looks a heck of a lot nicer and more JS syntax-like than the Vue bind:value approach. Not having to type a colon is a huge plus and it just looks neater.
Anyway, moving on. We are nitpicking here.
It is Fast.
There is no denying that Svelte is fast. The lack of runtime is the contributing factor here. The closer you are to the bare metal of the browser, the faster things will be.
The truth is, all frameworks and libraries are fast. When it comes to speed and performance, the contributing factor is rarely the framework or library itself, it is the user code.
Start pulling in various Node packages like Moment, adding in features such as validation and routing, and ultimately your bundle size is going to grow significantly. The end result might be the framework or library itself (even those with a runtime) accounts for 10% of your overall application size.
This is why I always tell people to be wary of benchmarks. Sure, benchmarks might look impressive, but they are not indicative of real-world conditions where things like latency, bundle size, what libraries you are using, and how you write your code are really the determining factors.
I think considerations to how a framework or library lets you author components and write code, what its features are, and what it allows you to easily and not easily do are more important than its speed.
To put things into context, there are still many AngularJS 1.x applications out there in production, which are still working fine. I also know of many Durandal, Knockout and Backbone applications still being used which are also working fine.
The generated code I have seen from Svelte applications is surprisingly readable as well. Usually compiled code is not easy to read (for humans) at all, so I was really surprised.
Svelte Exposes The True Complexity of React
For years, React has hidden behind the claim that it is the V in MVC, that it is a simple and a humble view component library. Anyone who has ever worked with React on an actual application will tell you that you never just need the view part.
I cannot recall a time where I have ever built a web application that didn’t have at least:
- Routing (the ability to define routes to different screens)
- The need to work with data from an API
- Form validation (not always, but more often than not)
If you want to add these features into a React app, you have to glue them all together. Because React utilises a Virtual DOM, the ability to just drop in and use any library that touches the DOM is not possible.
The problem with React itself (without turning this into a post bashing React), is that it is too heavily invested into itself. It is also responsible for perpetuating FUD in the front-end ecosystem on quite a few fronts.
React popularising Virtual DOM (and later on, Vue) would result in a lot of FUD around the DOM. When people tell you that the DOM is slow, they’re responding as a result of being programmed by the React community which drunk the “DOM is slow Koolaid” a few years ago.
Svelte has proven that the DOM is not slow. Although to be fair, Aurelia has eschewed the Virtual DOM (in favour of reactive binding) since it launched in 2015 and managed to keep step with other frameworks and libraries for years (upcoming Aurelia 2, even more so).
Now that React has introduced the concept of hooks into their library, it is yet another thing for developers to learn. Solutions like Svelte which do not require you to learn abstractions and ways of authoring applications definitely feel lighter and saner in the face of React.
Cognitively React requires a few React-specific ways of working which just adds to the learning curve. The React of 2019 is not the React of 2014, that is for sure. Authoring applications using Javascript and HTML is kind of refreshing.
Lack of ability to functionally compose views
This is one of those downsides of Svelte that some developers will struggle to look past. It requires you to use script tags and HTML to build your Svelte components. This means you are forced to use its templating syntax like #if, having to use #each for looping.
For developers who have had a taste of “pure components” where all components are written in Javascript, this is going to be a hard pill to swallow.
No TypeScript Support (Yet)
Right now, there is no official support for TypeScript in Svelte. If you are not a TypeScript user or perhaps you work with Vue 2 which admittedly is not much better at supporting TypeScript, then this will not be a dealbreaker for you at all.
If you are like many other developers who realise the future is TypeScript and have switched over, the lack of TS support is going to be a dealbreaker for you. Some developers have gotten it to work sort of using hacks, but not ideal support by any means.
Conclusion
I think what Svelte has brought to the table is going to kickstart some innovation and competition in the front-end space. While React has been trudging along for quite a few years now and Vue picking up popularity as well, it’s nice to see some new thinking that doesn’t revolve around a Virtual DOM or leaky abstraction.
Rest assured, you best believe that other frameworks and libraries are not going to sit idle while Svelte comes in and pulls the table cloth right off the dinner table.
The AOT compiler coming in Aurelia 2, for example, is going to optimise your Aurelia applications to a high degree stripping away runtime and unneeded code. Angular has been focusing their efforts on improved AOT compilation with the Ivy compiler and renderer and other options are also focusing their efforts on the compilation as well.
Even after playing around with Svelete just briefly, the lack of resulting code and marketing spin was refreshing to see after years of other players in the industry seemingly perpetuating immense amounts of hype.
Having said that, the safety and stability that I get using a featured framework (in my case, Aurelia) still feels too hard to beat.
I think Svelte is definitely going to get more popular and for non-complex UI’s it would be a great choice over React or Vue, but I still have hope that one day that Web Components becomes the norm and we see light abstractions on-top of WC that just compile to Web Components behind the scenes.
I would love to see how Svelte scales in a large-scale web application. Not specifically in performance (because I think it would remain fast), but rather code organisation, maintainability, testability and how easy it is to bring new team members up to scratch with an existing codebase.
Massive kudos to Rich Harris and everyone else who has worked on Svelte. I can definitely see the hype around Svelte is more than warranted and in the end, competition is healthy. We need fresh thinking and solutions to help drive standards and the ecosystem forward as a whole.
