[hathawsh]

I understand your dilemma very well. I have experience building server-rendered web apps, web apps enhanced with jQuery, Angular apps, and React apps. I resisted React for a while, but I'm glad I finally tried it out. Compared with jQuery or purely server-rendered apps, React elevates what you can accomplish within a short time frame. A complex web form with async validation, client side calculations, and multiple branches can be a real pain to code as a server-rendered web app or using jQuery, but React uses a different abstraction that makes a lot of code easier to reason about.

React achieves that with the virtual DOM concept. On the initial render, the virtual DOM concept is nearly equivalent to the kind of HTML templating you're familiar with; you simply render a document with some substitutions. It's what comes next that's interesting: when you need to change something on the page (for example, when you need to display validation feedback for a form field), you don't add code that finds the DOM element and changes it. Instead, with a virtual DOM, you re-render your components with new data, and the virtual DOM figures out what changed and applies the changes. Event handling is much simpler.

React has only a few concepts; once you get it, there's only occasionally a need to read the React documentation. Angular is also powerful, but Angular has many concepts and I found myself referring to the documentation for every little thing. That may have changed with Angular 2.

EDIT: I should also point out that React adheres to the idea of putting HTML tags in code, rather than putting code in HTML tags. For simple templates, it doesn't really make a difference, but for some of the whopper HTML templates I've written before, putting HTML in code (aka JSX) would have been a major benefit. There are plugins for editors like Sublime Text that make JSX smooth.

[bostonvaulter2]

The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.

[inimino]

React only needs a render method, not a render method and an update method for every state transition. Without the virtual dom this would destroy performance, so it is a rather key detail in understanding React's appeal.

[ZenoArrow]

The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.

[danabramov]

FWIW we are trying to avoid "virtual DOM" in the new docs. The thing you create in render() and that describes the tree has been called "a React element" for many versions by now. "Virtual DOM" was more of a marketing term and I find it misleading because it doesn't make sense with e.g. React Native, and also makes React seem like a performance trick. React is not a performance trick. That elements get compared by React DOM renderer is its implementation detail. React is abstraction for dividing UI into predictable pieces, not a performance optimization.

[hathawsh]

Thanks for pointing that out. The term "DOM renderer" does seem much clearer than "virtual DOM".

[ZenoArrow]

> "React is abstraction for dividing UI into predictable pieces, not a performance optimization."

Why can't it be both?

[danabramov]

Performance is baseline. If something isn't performant we won't use it. But that's not the point of React.

React wouldn't exist if it wasn't performant. But the reason React exists is not performance.

[hathawsh]

If I wanted to do what React does, but without React, I might start like this:

document.innerHTML = myComponent.render();

That way, I can write components similar to React components and it can render very quickly. However, this strategy would work only on the initial render, because this naive strategy would destroy implicit DOM state like scroll positions, focus state, and cursor selections. The React DOM renderer (formerly known as the virtual DOM) lets me apply this rendering strategy without ruining implicit state.

The DOM renderer does not give me components or performance, since I can already achieve those things with raw Javascript. What it gives me is the ability to use a simple, clean rendering strategy without destroying the DOM state. That's why the React DOM renderer is not just an implementation detail.