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:
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.
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.
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.
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.
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.
- Svelte Origins: The Documentary by OfferZen
- Why OfferZen is Making Documentaries about Open-source tech
- Rich Harris on why he created Svelte
- Why Svelte is Easy to Learn as a React Developer
- How Svelte differs from React or Vue.js
- Taylor Otwell on how he Decides what PRs to Merge into Laravel
- Jeffrey Way Tells the Story of Laracasts
- The Story of Tailwind CSS feat. Adam Wathan
- Nuno Maduro Tells the Story of Pest PHP
- Larabelles and Inclusivity in the Laravel community
- PHP Isn’t Dead ft. Jeffrey Way, Erika Heidi and others
- Taylor Otwell Explains his Coding Style
- The story of Laravel News featuring Eric L. Barnes
- Taylor Otwell on the Importance of Documentation and Developer Experience in Laravel
- The story of Code Happy, Code Bright & Code Smart feat. Dayle Rees
- Taylor Otwell on How He Got Into Programming
- The pros and cons of open-source feat. the Laravel Origins cast
- Taylor Otwell on how Laracon came to be