How to make a great framework better? - Svelte 5 with Rich Harris

Rich, thanks for having us. Thanks for coming by. You saved me a subway trip by coming here. Perfect. So what problem does Svelte solve? Svelte solves the-- so the fundamental problem is that web development is too hard.

And Svelte is an attempt to make it a little bit easier, to make it a little bit more tractable for a wider group of people to build rich, interactive web applications. It falls into this category of things called front-end framework, similar to projects like React and Vue and Angular and all of these other things. Takes a slightly different tack, but that is essentially what it does. It allows you to build your application out of declarative components, and then it turns it into something that the browser understands

and allows you to build interactive UIs without having to do all of the plumbing of manipulating the DOM yourself. You've described it as a web framework, as a framework without the framework, and as a language. Why is that important, and what do you mean by that? Yeah, the definitions and the way that we talk about it have definitely evolved over the years. The framework without a framework description was when Svelte first came out.

The idea was, can we just do away with all of the machinery that is included as part of the framework when it runs in the browser? Can we take your input and just compile it down to the underlying instructions to the browser and dissolve away all of the scaffolding? And so that's what framework without the framework means. In reality, of course, there is a little bit of infrastructure that needs to be there for any of this to work. But essentially, what it's getting at is this idea that the code that you write

and the code that actually runs in the browser, they're not the same thing. There is a transformation that takes place at build time so that the application that you actually ship to users is more efficient. It's smaller than it needs to be. Otherwise, it's better at updating the DOM in a very efficient way. And it does all this without you needing to think deeply about how to optimize your application. It does it for you. So Svelte, in addition to being a framework, is a language. It is a language for describing user interfaces.

When you build a Svelte application, you're doing it in a .Svelte file as opposed to in a .js or .ts file. And that is the fundamental difference. What do you see as the difference between a JavaScript framework and a web framework? Yeah, it's a subtle distinction. I guess the reason that we call it a web framework as opposed to a JavaScript framework, it's kind of twofold. Firstly, Svelte is an HTML-centric language. What we've found over the years is that HTML is actually a really good language for describing user interfaces.

There's something about the nature of those angle brackets that people just really get. You're describing the structure of something in a way that intuitively makes a lot of sense. And what we've seen is that JavaScript-centric frameworks, like React to be a great example, in order to make that style of development appealing, they've had to create things like JSX so that it feels like you're writing HTML.

Svelte doesn't do that. It says HTML is actually a really good starting point. We just need to make HTML an interactive language. And so that is what Svelte is. It adds interactivity to HTML. The other reason that we call it a web framework and not a JavaScript framework is that any time you build a web app, you're going to have to think about styling. That is one of the fundamental problems that you are going to have to solve. And a JavaScript-centric framework typically just doesn't have any opinion on this. But Svelte does. If you write a Svelte file, then you can include your CSS directly inside that component,