VDOM has never been faster to execute than tightly hand crafted Javascript, but writing such code is a nightmare, and it's been much faster to build apps, component libraries etc with frameworks that use VDOM that still have great performance.
VDOM lets you have components which are re-runnable factories. When something changes you re-run the factory and it spits out VDOM nodes, these lightweight Javascript objects are then compared with the ones spit out last time and only the differences are applied.
Hand crafted reactive Javascript will always be faster than this, but at the cost of real complexity and much harder to reason with code.
Libraries like SolidJS work by making a much nicer reactive interface that still allows you to write only simple Javascript that knows which DOM elements to update when things change. In SolidJS components are never re-run after the initial mounting, instead reactive logic is used to change DOM attributes or nodes when things change in the state. This makes the code slightly more complex and introduces restrictions you must adhere to (for instance not using JS destructuring of props to components) compared to VDOM implementations.
So you have libraries like SolidJS and Svelte (more of a modified language) which are looking to create highly reactive components and libraries like Inferno, Preact, React etc etc that use VDOM.
In widely touted benchmarks (I borrowed a slightly out of date one of Ryan Carniato's examples below - Ryan is the author of Solid) the two closest to native Javascript are Solid and Inferno. Given how fast these are it's hard to imagine needing to write native JS because it would be so much harder to reason with. From this we can see VDOM can be crazy fast and reactive can be crazy fast and you know what? React isn't in that top ranking but actually it's also still fast enough for most people.
So do we need VDOM? Well I think that principles like reactivity (with Hooks in React and signals in Solid for instance) really help us construct our applications. I won't be going back to hand crafted JS for sure...
In fact, there is a lot of code out there that is a nightmare, but does this mean, we can´t write good code in Javascript? Do we need a virtual DOM because people are not willing to learn to write better code?
We have done some really nice applications recently, that are directly working on the DOM. Just plain event based Javascript. And it came out they work like a charm.
Well yep, I can see that could happen. I think you should certainly write the code you need. If you need the best possible performance or you can easily reason with your problem then that could well be the best way to go. It's all about the mental models you need to apply and at which level you should apply them right? Whatever gets the job done well enough, fast enough sounds good to me.
Sure, but there are reasons, why people developed frameworks like Angular or React years ago. For me it seems, that things have changed over the last 5 years and many of the reasons are gone. But the frameworks still are there.
This is a very interesting idea to me. I’d like to hear more about it. Maybe you could write a new post about what changes over the past 5 years have made frameworks less vital. I would read it and click the heart.
I suppose there are good reasons for every side in this discussion. As there are different tasks to solve, different tools might be useful. Read more about the backgrounds here.
You need to read more about it! VDOM is faster on large trees, so if you give a huge tree svelte and react then react vdom will be faster on small tress svelte is faster
Doesn't matter All I said is that on huge trees react vdom is faster. If you want to know the reason why we even need vdom the answer is xml/html is the worst language to parse(slow) thats the reason people switched from soap api's to rest with json because the format is faster to parse then xml so in order to never need it again the next ui language on the web needs to be a syntax like CSS maybe all features of HTML merged over to CSS? Never mind... all I can say in order to fix this HTML6 should not even come out.
the reason people switched from soap api's to rest
REST is media format agnostic so JSON had nothing to do with it; in fact RESTful web services (2007) by Leonard Richardson, Sam Ruby used HTML - SOAP collapsed under the weight of the WS-Deathstar specifications - while only reinventing RPC in the process.
The thing I love about this model [REST] is that, as Sam says, it is of the Web, not over the Web.
I think of SPA(-frameworks) the same as I think of SOAP - neither of them are of the Web.
so in order to never need it again the next ui language on the web needs to be a syntax like CSS maybe all features of HTML merged over to CSS?
CSS was introduced in 1996 to remove the presentational aspects from HTML (1993) - they are not going to merge them after 25 years of separation.
In what way are operations on 1_000 and 10_000 rows not representative?
A DOM document is a tree of DOM nodes - but perhaps those are not the trees you had in mind.
The tests do prove that React performance is "just OK" - but not really anything special to warrant a claim that a VDOM-based framework is needed for performance reasons.
Adding 10K rows is possibly not what most Websites do. And the initial question was not: who is the fastest number cruncher.
The question was: There are two systems in a pipeline to optimize the screen update:
A VDom
The browser engine
If the browser engine is slow and stupid, a virtual DOM will be helpful in most cases. But if the browser engine is fast and smart, maybe it does a better job than a VDom. The Chrome core was written in C++, which could be faster than Javascript.
AND: the browser knows, what is visible on the screen, while the VDom does not. So, from the point of user experience, there is a good chance that a browser does a better job if he does not need to wait for a slow VDom.
I think, the only way to find out is to perform some tests with and without VDom active.
VDOM has never been faster to execute than tightly hand crafted Javascript, but writing such code is a nightmare, and it's been much faster to build apps, component libraries etc with frameworks that use VDOM that still have great performance.
VDOM lets you have components which are re-runnable factories. When something changes you re-run the factory and it spits out VDOM nodes, these lightweight Javascript objects are then compared with the ones spit out last time and only the differences are applied.
Hand crafted reactive Javascript will always be faster than this, but at the cost of real complexity and much harder to reason with code.
Libraries like SolidJS work by making a much nicer reactive interface that still allows you to write only simple Javascript that knows which DOM elements to update when things change. In SolidJS components are never re-run after the initial mounting, instead reactive logic is used to change DOM attributes or nodes when things change in the state. This makes the code slightly more complex and introduces restrictions you must adhere to (for instance not using JS destructuring of
propsto components) compared to VDOM implementations.So you have libraries like SolidJS and Svelte (more of a modified language) which are looking to create highly reactive components and libraries like Inferno, Preact, React etc etc that use VDOM.
In widely touted benchmarks (I borrowed a slightly out of date one of Ryan Carniato's examples below - Ryan is the author of Solid) the two closest to native Javascript are Solid and Inferno. Given how fast these are it's hard to imagine needing to write native JS because it would be so much harder to reason with. From this we can see VDOM can be crazy fast and reactive can be crazy fast and you know what? React isn't in that top ranking but actually it's also still fast enough for most people.
So do we need VDOM? Well I think that principles like reactivity (with Hooks in React and signals in Solid for instance) really help us construct our applications. I won't be going back to hand crafted JS for sure...
In fact, there is a lot of code out there that is a nightmare, but does this mean, we can´t write good code in Javascript? Do we need a virtual DOM because people are not willing to learn to write better code?
We have done some really nice applications recently, that are directly working on the DOM. Just plain event based Javascript. And it came out they work like a charm.
Well yep, I can see that could happen. I think you should certainly write the code you need. If you need the best possible performance or you can easily reason with your problem then that could well be the best way to go. It's all about the mental models you need to apply and at which level you should apply them right? Whatever gets the job done well enough, fast enough sounds good to me.
Sure, but there are reasons, why people developed frameworks like Angular or React years ago. For me it seems, that things have changed over the last 5 years and many of the reasons are gone. But the frameworks still are there.
This is a very interesting idea to me. I’d like to hear more about it. Maybe you could write a new post about what changes over the past 5 years have made frameworks less vital. I would read it and click the heart.
I suppose there are good reasons for every side in this discussion. As there are different tasks to solve, different tools might be useful. Read more about the backgrounds here.
Best regards
You need to read more about it! VDOM is faster on large trees, so if you give a huge tree svelte and react then react vdom will be faster on small tress svelte is faster
If the use of VDOM was about performance everybody would be using Inferno by now - especially if they don't need to support native web views.
So React's popularity has little to do with performant VDOM - because React's VDOM implementation isn't that fast.
Doesn't matter All I said is that on huge trees react vdom is faster. If you want to know the reason why we even need vdom the answer is xml/html is the worst language to parse(slow) thats the reason people switched from soap api's to rest with json because the format is faster to parse then xml so in order to never need it again the next ui language on the web needs to be a syntax like CSS maybe all features of HTML merged over to CSS? Never mind... all I can say in order to fix this HTML6 should not even come out.
That's misinformation; browsers are extremely efficient at parsing HTML and the DOM isn't slow - Live DB Monster Demo.
REST is media format agnostic so JSON had nothing to do with it; in fact RESTful web services (2007) by Leonard Richardson, Sam Ruby used HTML - SOAP collapsed under the weight of the WS-Deathstar specifications - while only reinventing RPC in the process.
I think of SPA(-frameworks) the same as I think of SOAP - neither of them are of the Web.
CSS was introduced in 1996 to remove the presentational aspects from HTML (1993) - they are not going to merge them after 25 years of separation.
If you really think HTML is faster to parse then CSS then I can't help you.
Who is comparing parsing speeds of HTML vs CSS?
Your original comment was about React (VDOM) being faster than Svelte on huge trees. SolidJS is faster than either of them and doesn't use VDOM.
Are there any tests or videos which can prove that Solid is faster on huge trees? I don't think it is.
JavaScript Frameworks, Performance Comparison 2020: Group 1 — The Performance Elite
Thats not what I asked you, I said show me prove that solid is faster on huge trees.
In what way are operations on 1_000 and 10_000 rows not representative?
A DOM document is a tree of DOM nodes - but perhaps those are not the trees you had in mind.
The tests do prove that React performance is "just OK" - but not really anything special to warrant a claim that a VDOM-based framework is needed for performance reasons.
I had exactly those in mind but this tests seem fishi to me.
Clone the repository and see for yourself…
I will lets look how the tests will be over 10k rows
Adding 10K rows is possibly not what most Websites do. And the initial question was not: who is the fastest number cruncher.
The question was: There are two systems in a pipeline to optimize the screen update:
If the browser engine is slow and stupid, a virtual DOM will be helpful in most cases. But if the browser engine is fast and smart, maybe it does a better job than a VDom. The Chrome core was written in C++, which could be faster than Javascript.
AND: the browser knows, what is visible on the screen, while the VDom does not. So, from the point of user experience, there is a good chance that a browser does a better job if he does not need to wait for a slow VDom.
I think, the only way to find out is to perform some tests with and without VDom active.
Ok I need to say I tried Solid JS today and my mind is kind of blown away.
Could you give us more information about your background and expectation? What precisely blew your mind?
My background? Eckhard is not the type of guy who can ask questions like that.
What´s your problem? Just tried to understand your previous answer.
Chart updated with last versions, vue 3.2 and compared with vanillajs.