The thing is that you can't do: update component -> update Real DOM because there isn't an automatic update method on the DOM. You (or React in this case) have to manually figure out what properties / elements have changed and update them one by one. How can you figure out what changed? By comparing current and desired React Element Tree (VDOM).
However, update component -> update Real DOM is possible with a compilation step. A compiler can detect which parts of the tree are static and which are dynamic, figure out the relations between state change and view change and generate code that precisely updates desired properties so there's mostly no need for diffing at runtime. That's the reason why svelte and the like are much faster than React (solidjs takes things even further and also takes components out of the equation at runtime so there's just state update -> DOM update and the code is nearly as fast as vanilla js).
As you said, we still have a way to update component then update RDOM but React doesn't use it so it has to use VDOM to help to deal with figuring changes and updating RDOM. If it's true, VDOM is not really efficient, it's just a "must have" thing to make React work the right way ?
If it's true, VDOM is not really efficient, it's just a "must have" thing to make React work the right way ?
The short answer is yes. It's just a way to detect changes and synchronize component's state to the DOM.
All web frameworks today define and work with abstractions (objects) that describe real DOM e.g. Fiber in React, LView in Angular. @marzelin
is right that if you have a compilation step, say like in Angular or Svelte, you can identify dynamic parts and only check their values and perform isolated updates if needed. This approach is faster that comparing entire trees, like in React. On the hand, React allows very dynamic tree modifications in runtime, while with the compilation step all dynamic behavior needs to be known at the compilation stage. Also, React doesn't need custom syntax for that, while Angular has a mechanism of directives to mark dynamic behavior in HTML templates.
I've written extensively about this topic in these two articles:
Having this abstract description of a view allows you to reuse code. Technically, you can take a source code for a component and use it to render to both a web app and a native app by just switching the renderer from react-dom to react-native.
Compile-time optimizations were promised with the introduction of hooks. A small step was already made with the new JSX transform.
At the moment React team is busy working on a concurrent mode which is a different approach to improving performance. Instead of optimizing rendering itself you slice the work into small pieces that are executed asynchronously so that user interactions (typing, clicking, scrolling) are never blocked even if there's a lot to rerender so the app seems fast and responsive.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The thing is that you can't do: update component -> update Real DOM because there isn't an automatic update method on the DOM. You (or React in this case) have to manually figure out what properties / elements have changed and update them one by one. How can you figure out what changed? By comparing current and desired React Element Tree (VDOM).
However, update component -> update Real DOM is possible with a compilation step. A compiler can detect which parts of the tree are static and which are dynamic, figure out the relations between state change and view change and generate code that precisely updates desired properties so there's mostly no need for diffing at runtime. That's the reason why svelte and the like are much faster than React (solidjs takes things even further and also takes components out of the equation at runtime so there's just state update -> DOM update and the code is nearly as fast as vanilla js).
As you said, we still have a way to update component then update RDOM but React doesn't use it so it has to use VDOM to help to deal with figuring changes and updating RDOM. If it's true, VDOM is not really efficient, it's just a "must have" thing to make React work the right way ?
The short answer is yes. It's just a way to detect changes and synchronize component's state to the DOM.
All web frameworks today define and work with abstractions (objects) that describe real DOM e.g. Fiber in React, LView in Angular. @marzelin is right that if you have a compilation step, say like in Angular or Svelte, you can identify dynamic parts and only check their values and perform isolated updates if needed. This approach is faster that comparing entire trees, like in React. On the hand, React allows very dynamic tree modifications in runtime, while with the compilation step all dynamic behavior needs to be known at the compilation stage. Also, React doesn't need custom syntax for that, while Angular has a mechanism of directives to mark dynamic behavior in HTML templates.
I've written extensively about this topic in these two articles:
Having this abstract description of a view allows you to reuse code. Technically, you can take a source code for a component and use it to render to both a web app and a native app by just switching the renderer from react-dom to react-native.
Compile-time optimizations were promised with the introduction of hooks. A small step was already made with the new JSX transform.
At the moment React team is busy working on a concurrent mode which is a different approach to improving performance. Instead of optimizing rendering itself you slice the work into small pieces that are executed asynchronously so that user interactions (typing, clicking, scrolling) are never blocked even if there's a lot to rerender so the app seems fast and responsive.