Inferno.js uses VDOM https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://krausest.github.io/js-framework-benchmark/2023/table.... Sooo, VDOM can improve performance?
- Svelte is actually strangely slow, I mean there's *one* interesting optimization that having a custom compiler/transform allows you do to for free, which is deep cloning nodes in one go rather than creating them one by one each time, and they ain't doing it. Also, I don't have proof of this anymore, but I had tried running my relatively naive framework without the deep cloning trick, and without any custom transform or compiler at all, on that benchmark, and it was _still_ significantly faster than Svelte. Like Svelte is not that fast when you look at it closely, despite what the perception of the average developer might be, or what the marketing might say.
- Inferno is fast for real in that benchmark, and it isn't using signals, which is very interesting. I don't know how Inferno works in depth, but looking at the Inferno implementation for that benchmark [0] I see some shenanigans. Like what's that "$HasTextChildren" attribute? Why is my event handler created like that? Like I'm doubtful that the result in the benchmark will actually translate exactly to the real world.
- It's interesting also: if the VDOM is pure overhead why is Svelte creating an object for each instance of a component, kinda like React is doing? You don't strictly need to do that, as proof of that Solid doesn't do that (in production builds), because that's pure overhead for real there.
[0]: https://github.com/krausest/js-framework-benchmark/blob/6388...
This does translate into the real world, if developers use the flags. I know their babel plugin uses some heuristics to auto apply some of these things, but its extremely conservative.
The flags themselves are available in the real world though and can be used to achieve high performance.
Its really a shame Inferno never caught on the same way as other frameworks. Its extremely fast and intuitive, and had a nice take on functional components (just add the lifecycle methods as props, instead of introducing what is now React Hooks, though I think Inferno is held back not having a hooks API for some level of mindshare and compat there).
Even SolidJS hasn't quite crept the performance Inferno has managed to achieve.
EDIT: If memory services, the creator of Inferno works (worked?) at Meta (Facebook) as well. For whatever reason, it never garnered mindshare at FB either, despite arguably being a better solution than React in many real world scenarios and coming around at roughly the same time. I have always wondered what the story was there
I see Solid to the left of Inferno in that benchmark, though they are very close indeed. Solid's code looks weird in its own ways I guess, but it looks less hacky/hand-optimized to me.
Inferno seems to use less memory though, which seems interesting. Solid isn't fully memory optimized though, it could beat Inferno with more memory optimizations potentially.
Svelte requires very little over and above HTML and JS while still being closer to Solid in performance than React, Vue, or Angular.
And the latest interactions of React and its ecosystem have both high cognitive overhead AND lackluster speed. At least Angular is opinionated. React is just a YOLO ball of yarn for large codebases.
With Svelte, you see a script tag with 99% plain JS, some HTML with some basic control and binding syntax, and a style tag with 100% plain CSS/SCSS.
No createSignal(…) with [foo, setFoo]. No props objects. No onCleanup(…) handlers. No createEffect(…) to track reactivity. No render(…) function just to show some HTML. No string template literals to use the framework. No worrying about when to use createMemo(…) or not. Nothing more than a $ prefix to use a store.
Solid (and React et al) is to Svelte as vanilla DOM is to JQuery.
https://krausest.github.io/js-framework-benchmark/2023/table...
As one of the first Facebook PMDs (later FMPs) part of my job back then (around 2010-2012) was to keep up to date with changes in the ads API, but our main contacts were two guys in Ireland and themselves not always kept up to date with every development out of Palo Alto – I realised that the Power Editor was a client-side app, so I would reverse engineer it to find new features that were being run as internal experiments and stay up to date.
I realised that they had broken up the app into classes that kept their own state, using a framework that they called Bolt/Javelin – which would later become React – so I ended up writing what was probably one of the first browser extensions to debug "React" :)
Their ads team grew and grew and suddenly the two blokes in Ireland became hundreds and thousands. I can't imagine a better POC for a technology than the power editor was, because of how much of an impact it had for Facebook's ads business exponential growth.
In reality, most of these benchmarks are not meaningful when talking about real app performance. What's meaningful is how you do global state updates in your app. If you use a react app with react-hook based context providers that unnecessarily update hundreds of components on simple changes, you perf is going to suck. If you use a react app and don't use React.memo anywhere, perf is going to suck. If you use react very carefully and are fully aware of when the vDOM is going to run and use small components that only update when their data actually changes, and ideally avoid running vDOM 60 - 120fps a second for animations, performance is going to be good.
I like Solid.js because it does all this for you by nature of just using the framework. Svelte does some of this for you so for real world apps performance is likely to better than react, but it doesn't do it as well as Solid by nature of it's state management strategy, not by nature of it's DOM update strategy.
The less you update, the faster your app will be. Then the DOM diffing strategy doesn't matter.
This article doesn't really argue against that. They say the VDOM is a "means to an end" and is "generally good enough".
The thrust of the article seems to be that a virtual DOM isn't a guarantee of performance. Rather it's just one solution that can be pretty fast. Svelte happens to take a different approach which is also pretty fast.