Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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?
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/6388...
Yes and no.
Having implemented virtual DOM natively in Sciter (1), here are my findings:
In conventional browsers the fastest DOM population method is element.innerHTML = ...
The reason is that element.innerHTML works transactionally:
Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree.
While any "manual" DOM population using Web DOM API methods like appendChild() must do such transaction for any such call, so steps above shall be repeated for each appendChild() - each such call shall left the DOM in correct state.
And virtual DOM reconciliation implementations in browsers can use only public APIs like appendChild().
So, indeed, vDOM is not that performant as it could be.
But that also applies to Svelte style of updates: it also uses public APIs for updating DOM.
Solution could be in native implementation of Element.patch(vDOM) method (as I did in Sciter) that can work on par with Element.innerHTML - transactionally but without "parse HTML" phase. Yes, there is still an overhead of diff operation but with proper use of key attributes it is O(N) operation in most cases.
[1] https://sciter.com
> You probably haven't done any native UI
Hah. https://github.com/Ardour/ardour/tree/master/gtk2_ardour ... c'est moi
Anyway, that's not really the point I was making. Native UI can be thought of and used as a DOM model, but that's not inherent to the process unless you're literally writing traditional database+presentation+edit applications.
I was more poking light-hearted fun at the explosion in terminology and concepts exposed to someone doing web-based "frontend" development, and how little most of this has to do with HTML, CSS and the general classical model of "a browser".