What is Svelte? feat. Rich Harris

We’re creating documentaries to tell the tech stories that inspire people to keep creating and learning, and ultimately, unlock more potential in both themselves and software. Check out the YouTube Channel!

Here, Rich Harris gives a breakdown of what Svelte is, and the problems it solves:

Transcript

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 we 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 a bout 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.

Svelte has definitely found a home in the data visualisation community. And I think that is partly because, you know, it was designed from the beginning to enable me to do my job, which very largely involves data visualisation. And I think it probably took off with that community because, you know, in a way, I'm kind of like a member of the tribe.

And so there's a level of trust that goes with that. But it is also designed with the challenges of those sorts of projects in mind. For example, you know, very often you're dealing with quite a large amount of data, and some of it is maybe going to be in motion at some point. And so performance is super key.

Also, like a lot of the people who are building this stuff, they're not programmers first, they're practitioners or they're journalists and they're not coming to JavaScript because they really love JavaScript. They come into JavaScript because it enables them to do their job. So something that is designed to be very simple and familiar to people who already understand web technology... I think is a huge advantage.

But Svelte is in no way sort of restricted to the date of its uses. It's as flexible and generic a framework as React or Vue or any of the other things that it stands amongst.

Svelte really makes no assumptions about the kind of project that you're building and it, you know, it wants to integrate very cleanly with whatever other technology you're using. There is unnecessary complexity that often gets added to projects.

But even once you got rid of that, you have this sort of irreducible amount of complexity and you know, some tools which are ostensibly simple they're really just kind of transmuted that complexity into complexity that needs to be borne by the program using it.

What Svelte tries to do is it tries to move that complexity into a place where it can't do any damage. And by that we mean by moving the complexity into the compile step instead of, you know, the API design or the code that
runs in the browser or the way that you actually have to use components, then we can kind of turn that problem on its head.

We're not claiming that we've got rid of complexity, we're claiming that we've contained it in such a way that you don't have to deal with it. What we're trying to do is democratise the creation of interactive stuff on the web.

Transcript

Rich Harris:

Related content

Recent posts