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.
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.