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