ReactJS virtual DOM in memory and applying incremental changes

Question

Came across below statement in one or other form on google

Each time the underlying data changes in a React app, a new Virtual DOM representation of the user interface is created.This is where things get interesting. Updating the browser’s DOM is a three-step process in React.

1. Whenever anything may have changed, the entire UI will be re-rendered in a Virtual DOM representation.

2. The difference between the previous Virtual DOM representation and the new one will be calculated.

3. The real DOM will be updated with what has actually changed. This is very much like applying a patch.

I am new to React and would like to understand above how above three points used to to work in pre-React Era say in jQuery (or native JS).

jQuery

1. HTML was constructed on server side, sent back to browser. Browser will parse, render, layout and paint it.
2. Say any new DOM element is created or hidden either on some user event or on load.
3. Will jQuery recreate the complete DOM? From third point stated above looks like React just update the DOM for only the part that has been changed but other system (primarily jQuery or native JS) will recreate the complete DOM. Is that correct?
4. Is the third point true only for DOM changes or even when state of any UI component changes like filling the text box/dropdown etc?

Answer 1

Will jquery recreate the complete DOM ? From third point stated above looks like React just update the DOM for only the part that has been changed but other system(primarily jquery or native js) will recreate the complete DOM. Is that correct?

jQuery

---

No, jQuery doesn't recreate the DOM. Instead it navigates the DOM tree with selectors provided to make the appropriate changes. This makes jQuery very similar to React, but its performance issues come with the way the code was designed and it's heavy usage of the facade design pattern. This is normal for any larger library that needs to support multiple browsers like Chrome, Firefox, Opera, etc.

Angular 1

---

A framework that used to repaint the entire DOM was Angular 1. The client would make some changes, and rerender whenever $scope.apply or $scope.digest was called. This, combined with a huge number of listeners on large pages for two way data-binding was one of the big reasons why Angular had to undergo significant changes to stay competitive. Angular 8 is probably equivalent to React, but one has seen more adoption then the other.

React

---

React only updates the DOM that was changed. This is part of its "secret sauce". Along with its component centric architecture and early adoption of one way data-binding, it's seen a lot of success. Arguably React is starting to get more bloated since there's such wide adoption. This is normal for any project that gets mainstream usage. It's only a matter of time until people view React as a ton of performance problems and we'll create a new framework.

Alternatives

---

There are even faster frameworks than React, such as Elm lang. Nothing ever beats pure Javascript (e.g. document.querySelector()) since at their core, all frameworks use it. At that point you start hitting other trade offs such as lack of external libraries you can depend on, or difficulty in maintaining large front end codebases.

---

Is the third point true only for dom changes or even when state of any UI component changes like filling the text box/drop down etc ?

For jQuery or pure JS the third point is not true. There's a custom on-click handler of some sort that will run a function that makes a small change.

For something like Angular, that could be true if there are changes to scope that trigger a repaint. The same applies for React. If your submit button is supposed to redirect you to a completely different page, it will basically be repainting the DOM.