LogRocket's podcast PodRocket released a new episode with Rich Harris, the creator of Svelte, this morning. There were so many good insights in it that I wanted to pull out some choice quotes and take some notes to share this in a non-audio medium.
I highly recommend listening to the full episode, especially if you're new to Svelte. Even if you're already familiar with Svelte, there are still some great insights to Svelte's philosophy and its position in the current framework landscape.
All these quotes are from Rich Harris. I pulled them from the transcript of the episode and cleaned them up a bit, though the emphasis is mine.
Svelte's advantages permalink
Svelte's advantage is that it lets you write your components declaratively, and then translates it into the underlying DOM manipulation at compile time. This typically makes for smaller bundle size and faster state updates.
Instead of imperatively manipulating the DOM with
document.createElement and all of the things that are provided by the platform. It puts a declarative layer on top of that so that you can describe the output that you want, and then the framework's job is to translate that into the underlying DOM manipulations.
It generates typically very small code, which means that your application is going to load very quickly, and the updates, when you have a state change within your application, also take place very quickly, because it doesn't need to regenerate your entire application. It's just surgically updating the part of the page that's affected.
I should say at this point, because this is what I've been telling people about Svelte since it first came around in 2016, the landscape has actually shifted a little bit and other frameworks are, in many cases, becoming a little bit more Svelte-like. So when I talk about these unique advantages, they're not so unique anymore. Svelte's selling point these days is really more about the developer experience it provides. Vue, in particular, has adopted a lot of these techniques and also has some of those bundle size and performance characteristics.
There are advantages to staying close to the platform and only using syntax that exists natively, but domain-specific languages (DSLs) have advantages too.
Svelte's primary language is HTML permalink
Svelte's component syntax uses HTML as a base—the fundamental language of the web.
On SvelteKit's flexibility permalink
SvelteKit is a framework built for the serverless front-end landscape.
But if you're doing something that's highly dynamic, then you can have a server component or you can have serverless functions or you can put it inside a Cloudflare Worker, and you can pre-render the parts of your application that are static and dynamically render the parts that are not. And it's really a way of addressing all of the problems, or as many of the problems as possible, that you encounter while building a modern web application.
For more on this topic, see the SvelteKit announcement post, though some things have changed since that was written. Most notably, SvelteKit is now using Vite instead of Snowpack.
What's on the Svelte roadmap? permalink
I liked hearing about what could be next for Svelte, though note that nothing on this list is set in stone. It seems like we can expect more iteration on Svelte core once SvelteKit hits 1.0 and is stable.
I'm almost reluctant to talk about some of these things, because a lot of it is speculative and we're not really sure where some of these ideas are going to land. But we have this long wish list of things that we want to do for Svelte 4.0 and beyond.
Some of it is adopting some of the features that other frameworks have proven out, like streaming SSR and things like that. Some of it is around speeding up our own compiler, so that the feedback loop gets even tighter. Changing how the compiled output is generated such that if you have a very large application, you're paying only a very tiny incremental cost per component. We have some grand ideas about better ways to think about motion inside user interfaces and how that should be tied to the core of a framework as opposed to left to a userland solution.
We have a great many ideas, and I don't want to give them all away. But there's a lot on our plate, and we're pretty excited to get stuck into it when we can.
Does Svelte have more "magic" than something like React? permalink
A common perception is that Svelte has more magic as opposed to a framework like React. However, React has magic too—the difference is that Svelte's magic happens at compile time, while React's magic happens at runtime.
The difference is that they're doing it all at runtime instead of having all of that stuff happen behind the scenes at compile time. And I tend to think that focusing on whether the magic happens at build time or whether it happens at runtime is focusing on the wrong thing. All frameworks involve magic. Svelte is just trying to do the expensive bits of magic before that code gets to the user. That's the only real difference.
On the "framework wars" permalink
Treating web development as a war between one framework or another is not healthy. The people building these frameworks get along and are all trying to improve front-end development and the web as a whole. There is no One True Framework, and different frameworks fill different needs.
I dislike the framework wars framing generally, because what might not be obvious to a lot of people who are users of these frameworks as opposed to actively involved in the development of them, is that... The people who are building these frameworks, we often talk to each other. We by and large know each other. We get along. There's no animosity There's no warring whatsoever.
We hang out in the same spaces and we share ideas with each other, and really we're all, I think, just trying to collectively advance the state of front end development by focusing on the little bits of innovation that we can contribute, and then gradually, all of that stuff filters through the ecosystem and gets shared more widely. And Svelte occupies a part of the landscape that is attractive to a certain kind of developer. React occupies a different part of the landscape. They're both completely fine solutions for the people who are choosing them, and they're not going to be right for everyone and that's fine.
Svelte is no longer an underdog permalink
Svelte is now talked about as one of the "big 4" frameworks. At this point, we can't really consider it an underdog, since so many are aware of it. There are many frameworks with much less name recognition than Svelte.
So are we the underdog? It depends on what you're looking at. There's three big frameworks, right? There's React, Angular and Vue. And if you had to pick a fourth framework, I think most people at this stage would probably say the fourth framework was Svelte. And so if underdog means that you're inside the top four instead of the top three, then absolutely are the underdog.
At the same time, we have a pretty good mindshare at this point. A lot of people in the front end world have heard of Svelte. A lot of people talk about Svelte. There's a whole industry of people doing YouTube videos about Svelte. And I think calling ourselves underdog would be a disservice to the people who are actually laboring on open source projects without getting a whole lot of recognition. I think we have plenty of recognition. And so, I wouldn't claim the underdog label for ourselves by any stretch, but nor are we in any way mainstream.
See the podcast for more, including permalink
- How Svelte compares to the virtual DOM (see also: Virtual DOM is pure overhead)
- The ideal use case for Svelte
- Svelte's two-pronged approach to managing state
- How templating works in Svelte
- Whether a React-specific DSL could help reduce its boilerplate (see also Rich's tweet on the subject)
Want to find out when I post a new article? Follow me on Twitter
or subscribe to my RSS feed