What is Svelte? feat. Rich Harris

I really should be better at  answering the 'what is Svelte?' question. I should have had a lot of practice  by now, but it's a lot of things, and it's a little difficult to condense into  a soundbite. For people who have used frontend frameworks like React and Vue, it's a  pretty familiar concept to those. These are things that allow you to build interactive web  user interfaces in a way that is much easier and less bug prone than the traditional way  that we used to write applications years ago.

What's different about Svelte from those  frameworks, or at least was different when Svelte came out — because, you know, there's  been a lot of evolution in the space since then — is that it tries to do as much of  the work the build time instead of in the runtime. What that means is that whereas, for  example, React will do some work to compute the difference between what's currently on  the page and what should be on the page. Svelte will take that logic and it will try  and do as much of it as possible before the application even runs in the browser. And the  way that we do that is we have a compiler.

A compiler takes your declarative component  code and it turns it into an approximation of what you would have written if you're writing  this very hand optimised vanilla JavaScript. And so essentially Svelte is a language, it is a  language for creating user interfaces on the web. When Svelte came out, the term that we used  was a framework without the framework. And it was, I guess, a little bit of a marketing  sleight of hand, but it also reflected the mindset that it was created with which was rather than thinking of a framework as being something

that runs your code, a framework is  really a way of thinking about your code and it follows from that that you could  potentially build a framework in such a way that you got all the benefits of the  code organisation and the readability and the robustness without paying the cost of serving  all of this extra JavaScript to the browser.

Svelte is not unopinionated. Svelte is very  opinionated about the way to build applications. And it's that way because the people  who built it are very opinionated, I'm very opinionated, the rest of the  team are too. We have opinions, we talk about those opinions. We like  pitch our opinions against each other. And the outcome of that process is a  framework that has a very distinct view on, you know, what code should look like. One of the things that we believe very strongly is  that you should write as little code as possible.

Not just because, you know,  you have less code to write, you'll write it faster and then you can  spend the rest of your day outdoors or doing something other than hunching over a  laptop. But also because, you know, research has shown that the more code you  have, the more bugs your application will have. And if you can write your code in a way that  allows you to express concepts as concisely and elegantly and intuitively as possible, then,  you know, we believe you are going to have

a more robust application at the end of it. And  that's good for you and it's good for your users. When you're writing JavaScript in the context  of a newsroom you're typically writing these kind of self-contained apps that go on  a page that you don't control. So you have all of the other code that runs like the  analytics and the ad code. And if you have code that loads comments from readers and all  of that sort of thing — typically runs before your own application code, and so you're  working in this kind of hostile environment. And the last thing that you  want to do is on top of that,

send a huge chunk of more JavaScript to  the browser. And then once the JavaScript does load and people start interacting with  your application, it needs to be fast. And in a newsroom, you're building this stuff  under very tight deadline pressure. And so you don't want to have to build it and  then spend another cycle optimising it. It has to be fast from the get-go.  And so really, Svelte was designed to solve these two problems. Shipping too much  JavaScript and making things fast by default.