Svelte :: Framework without the framework
What problem do frameworks really solve?
The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.
Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.
The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, React plus ReactDOM without any app code weighs about 45kb zipped. It takes about 10x as long for the browser just to evaluate React as it does for Svelte to be up and running with an interactive TodoMVC.
And once your app is up and running, according to js-framework-benchmark Svelte is fast as heck. It’s faster than React. It’s faster than Vue. It’s faster than Angular, or Ember, or Ractive, or Preact, or Riot, or Mithril. It’s competitive with Inferno, which is probably the fastest UI framework in the world, for now, because Dominic Gannaway is a wizard. (Svelte is slower at removing elements. We’re working on it.)
It’s basically as fast as vanilla JS, which makes sense because it is vanilla JS — just vanilla JS that you didn’t have to write.
But that’s not the important thing
Well, it is important — performance matters a great deal. What’s really exciting about this approach, though, is that we can finally solve some of the thorniest problems in web development.
Consider interoperability. Want to
npm install cool-calendar-widget and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if
cool-calendar-widget was built in React and you're using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.)
Or code splitting. It’s a great idea (only load the code the user needs for the initial view, then get the rest later), but there’s a problem — even if you only initially serve one React component instead of 100, you still have to serve React itself. With Svelte, code splitting can be much more effective, because the framework is embedded in the component, and the component is tiny.
Finally, something I’ve wrestled with a great deal as an open source maintainer: your users always want their features prioritised, and underestimate the cost of those features to people who don’t need them. A framework author must always balance the long-term health of the project with the desire to meet their users’ needs. That’s incredibly difficult, because it’s hard to anticipate — much less articulate — the consequences of incremental bloat, and it takes serious soft skills to tell people (who may have been enthusiastically evangelising your tool up to that point) that their feature isn’t important enough. But with an approach like Svelte’s, many features can be added with absolutely no cost to people who don’t use them, because the code that implements those features just doesn’t get generated by the compiler if it’s unnecessary.
We’re just getting started
Svelte is very new. There’s a lot of work still left to do — creating build tool integrations, adding a server-side renderer, hot reloading, transitions, more documentation and examples, starter kits, and so on.
But you can already build rich components with it, which is why we’ve gone straight to a stable 1.0.0 release. Read the guide, try it out in the REPL, and head over to GitHub to help kickstart the next era of front end development.
Originally published at svelte.technology.