- 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.
Inferno was one of the first frameworks to embrace compiling JSX as an opportunity for advanced performance. the `$HasTextChildren` is a special attribute their JSX compiler (its a babel plugin) uses to optimize the tree at that point in time the that flag is found. It can do advanced optimization knowing that the children of that component are purely text VNodes. There are other flags available too that optimize different aspects[0]
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 think React won partly because one of the most important tools for Facebook's revenue, the "Power Editor", was built on react (before react even existed, I suppose)
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.
> Even SolidJS hasn't quite crept the performance Inferno has managed to achieve.
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.
Yep, Solid is among the fastest but requires more cognitive overhead.
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.
JSX. This was never zero cognitive overhead as compared to plain HTML. Folks have simply had 10 years of practice with their Stockholm Syndrome.
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.
- 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...