Skip to content

Latest commit

 

History

History
91 lines (63 loc) · 4.58 KB

brief-history-of-react.md

File metadata and controls

91 lines (63 loc) · 4.58 KB
Raw

A Brief History of React

Why did Facebook create React? What problems does it solve? What was there before? Let's see a little bit of history.

First browser war (1995 - 2008)

First, Brendan Eich created JavaScript. It was included in Netscape in 1995 and Internet Explorer in 1996. There was no npm, few libraries and resources, slow engines. You would use JavaScript as simple tool for validating forms.

jQuery was a huge change at that time because it brought consistent API across all browsers and abstracted away lots of bugs. However, many apps were a bunch of spaghetti scripts; nobody cared much because reloading the page happened often and fixed all problems.

Some tools of this era:

Second browser war (2008 - 2012)

With the release of V8 the world figured out that JavaScript can be fast too. A new fancy buzzword was invented - Single Page Application - and people started writing applications, not pages. That means user spends much more time in a single context, and state management and application architecture becomes much more important.

The most favourite paradigm of this age was Two way binding: View event triggers Model update, and Model event triggers View update. While that sounds good in theory and works well in examples, it may cause issues. Performance can suffer in some circumstances, debugging is pure pain and tracking which event caused which update is difficult.

In this era, lots of new tools popped up:

React era (2013+)

In 2013, Facebook released React. Its main advantage is simple API. You only need one method:

react.render(<App />, props)

and that's it! No need to care about binding, be it one way or two way. This is the killer feature. There are others too:

  • Declarative interface
  • Just JavaScript, no custom DSL (*)
  • Components are idempotent functions
  • Support for client, server, string, and native rendering

Other frameworks and tools appeared that play very well with React:

Why bother?

Why bother? Why does it need to be so complicated? Just render everything, like server sent pages do, and we are fine.

Well, rendering takes a lot of time. There are several steps that happen when DOM changes:

  1. Parsing and executing JavaScript
  2. CSS calculation
  3. Layout
  4. Painting
  5. Layers composition

There is actually a lot of work to be done and rendering a webpage takes between 200 milliseconds to 1 second on a fast computer. That is acceptable on first page load, but definitely too much for user actions.

It helps if the app touches less elements: some steps can be skipped, some are faster, and rendering is faster.

Other frameworks mentioned here required the developer to solve this; React comes with Virtual DOM.

Virtual DOM and tree diffing

React comes with a tree diff algorithm that does the heavy lifting. Instead of touching browser DOM, it remembers a copy in memory: virtual DOM. Virtual DOM is just a bunch of JavaScript objects and requires less CPU and less time than browser DOM. It then figures out what needs to be changed and only touches that particular Element.

From developer point of view, this is a win: it looks like we render everything every time, so the app looks simple. And React takes care of only changing what must be changed, so performance does not suffer.

More reading