The difficulties of developing on the Web Platform

If we had to develop directly on the web platform (which some people use anyway), we would face multiple problems that make it quite hard:

• Mutating the DOM for speed can become very difficult for complex UIs.

• The web platform (at the time) didn't offer any mechanisms of abstraction (creating new elements in web pages). (This is no longer true, there is an API for Web Components, but it came after many frameworks were already established, and it is not, arguably, as good as them).

• Developing an app split into two parts, frontend and backend, with a "remote procedure call" interface in the middle, and possibly with multiple programming languages and standards, is quite a burden.

What is React

React was one of the first libraries to tackle the problem of mutating the DOM. It wasn't the first, nor the last, but the model it put forward has been very much adopted by the community, and many frameworks have adopted the same philosophy. It makes client development much easier because it relies on a very simple idea:

The UI is a function of the state (or model).

That is, when rendering some data into HTML, if we are given the data, there is only one possible outcome for the UI. Every piece of data produces a different page which is a function of that data. If the data changes, so does the page.

So React set out to solve the problem by asking only one thing to the developer: to write functions that, given the state/model, produce as output the desired UI, i.e. how the page should look. And React took care of DOM mutation.

As React developers, our only responsibility is almost the same as if we generated HTML from data, from scratch. Even if the page is already loaded and the DOM is present, we do not think about how to change the DOM, only about how to generate it completely.

Virtual DOM

React internally uses something called the Virtual DOM. The Virtual DOM is what React functions return, and it is a mirror version of the real DOM, but much faster. The trick is this: when React changes the DOM, it keeps an exact replica as Virtual DOM. Then, when a developer wants to render a page, it gives React a new Virtual DOM, which represents the page as it should look now. After this React has two Virtual DOM trees: the old Virtual DOM, which is a copy of the real DOM, and the new one, which is the desired Virtual DOM.

Then starts a process of reconciliation, i.e., React compares both trees, old and new, and decides what should be done to the real DOM to make it like the new Virtual DOM. This usually involves much less work than recreating the DOM from scratch, because old and new share a lot of structure, typically only a few nodes have differences. Those differences are the ones that React pushes to the real DOM, to leave it exactly like the new Virtual DOM.

Having done this, now the new Virtual DOM is exactly like the DOM, and we can start the same process again (new will become old).