5 ms·

Inferno.js uses VDOM https://github.com/infernojs/inferno https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://k

Inferno.js uses VDOM https://github.com/infernojs/inferno https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html https://krausest.github.io/js-framework-benchmark/2023/table.... Sooo, VDOM can improve performance?

CivBase 4y ago
> Sooo, VDOM can improve performance? 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.
spankalee 4y ago
You _can_ get vdom to be fast if you hoist static subtrees, memoize, and skip the diff entirely for some operations. Inferno is known for all kinds of these tricks, but you need compilers for that and in the end vdom is just getting in the way.
fabiospampinato 4y ago
That's an interesting comparison because: - 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/638871c00e40185e37f3ea2c575c2c57c498079d/frameworks/keyed/inferno/src/controller.jsx#L9 https://github.com/krausest/js-framework-benchmark/blob/6388...
- no_wizard 4y ago
  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 [0]: https://www.infernojs.org/docs/guides/optimizations https://www.infernojs.org/docs/guides/optimizations
  - andai 4y ago
    These benchmarks say SolidJS is faster than Inferno. Maybe that's a recent thing? https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html https://krausest.github.io/js-framework-benchmark/2023/table...
  - fabiospampinato 4y ago
    > 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.
mistersys 4y ago
Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective. 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.
- bsaul 4y ago
  damn, just when i thought the "1 new js framework a day" race had calmed down, i'm reading your comment and realize it hasn't one bit :)))

CivBase 4y ago

> Sooo, VDOM can improve performance? 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.

spankalee 4y ago

You _can_ get vdom to be fast if you hoist static subtrees, memoize, and skip the diff entirely for some operations. Inferno is known for all kinds of these tricks, but you need compilers for that and in the end vdom is just getting in the way.

fabiospampinato 4y ago

That's an interesting comparison because: - 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/638871c00e40185e37f3ea2c575c2c57c498079d/frameworks/keyed/inferno/src/controller.jsx#L9 https://github.com/krausest/js-framework-benchmark/blob/6388...

no_wizard 4y ago
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 [0]: https://www.infernojs.org/docs/guides/optimizations https://www.infernojs.org/docs/guides/optimizations
- andai 4y ago
  These benchmarks say SolidJS is faster than Inferno. Maybe that's a recent thing? https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html https://krausest.github.io/js-framework-benchmark/2023/table...
- fabiospampinato 4y ago
  > 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.

mistersys 4y ago

Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective. 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.

bsaul 4y ago
damn, just when i thought the "1 new js framework a day" race had calmed down, i'm reading your comment and realize it hasn't one bit :)))