React is the way of building web apps today. But what’s next? What if React isn’t the final solution for web technology?
Thank you jQuery for giving us webapps, web2.0, things like Gmail and Google Maps.
With Ajax + Event driven architecture.
Frameworks made it easier to scale. To more developers and to more views/subviews. Frameworks helped us reason better about problems.
But they were still slow. And had a lot of boilerplate, and “magic” to make it all work under the hood.
React was launched 2013 and changed everything
It introduced State driven Architecture and forward referencing (reactive code).
Another wave of JS frameworks hit the internet. VueJS, Angular, they all became component based declarative reactive frameworks.
All reactive frameworks relied on a Shadow DOM to handle the quick partial renders of the DOM.
But it’s not fast enough. Even the React team doesn’t think so, which is why they spend so much time adding features, like ShouldComponentUpdate and memoization, to help up speed up rendering.
Reactive frameworks create some side effects.
You could no longer just open a text editor and write.
Now you needed build processes, using things like webpack, to transpire your code so that it would run in the browser.
While rendering is quicker. Shadow DOM is a pure overhead layer.
If you haven’t read this classic article, I still heartily recommend it. It’s a caricature of how difficult it is just to get started writing JS in 2016. It has improved a little bit, but not much. There’s one for every year since.
Stuff like this lead Rich Harris to an insight:
Frameworks are for helping us think, not for structuring code.
And a transpile step, is a compiler.
Now we’re seeing the first Post Reactive Frameworks (as I call them).
They’re not really frameworks, they are the compilers. There’s no special code in the browser, just JS.
Much like major languages have been creating machine code for decades.
Since we’re compiling the code, it can be compiled into anything.
The default state of the svelte compiler creates a reactive JS class for every component. It was also spit out web components. Or Server Side Render for orders of magnitude faster rendering than Shadow DOM frameworks.
Svelte has “Better than best in class” performance.
Not only that but the Bundle size is very small. And since Svelte is a compiler it can have all sorts of features that don’t get included unless you use them. Sort of the opposite of the common “NPM modules black hole” front end developers are struggling with today.
Compare this react demo: https://rethinking-reactivity.surge.sh/time-slicing/
With this svelte demo: https://rethinking-reactivity.surge.sh/svelte-svg/
Typically Svelte is 40% less code than React.
Why do we care?
Less code means less work for us.
Less debug time.
Less network loading time.
Less performance needed in your browser.
Less battery used.
So here’s another comparison, this is TodoMVC.
I’m sure you’ve seen it. It has been used to compare JS frameworks since the days of jQuery and Backbone.
Svelte handles per component CSS, scoped and ready. You can use BEM or some framework, but you don’t need too.
Animations are also handled via svelte by adding and removing css animations runtime. Which means animations are performant, battery friendly, and since svelte is a compiler, animations aren’t affected by your update loop!
Despite being only a little over a year old, Svelte has surprising traction.
Yes, nothing is perfect.
Still lacks complete typescript support.
It uses Rollup as the build tool. You can use webpack, but most users use Rollup.
There aren’t that many examples and not much help on stack overflow.
Should you use it in production? Yes, it’s time. You can mix it into micro front ends, or use webcomponents, or write new stuff in svelte.
Used by Apple, New York Times, ICA, example in browser: https://www.playpilot.com/se/
Is it hard to start with svelte? You be the judge:
Visit svelte.dev for some great examples! And follow me on Twitter for random thoughts!