Is ReactJS really fast?

> It's the fact that you can reason about your app as if you are re-rendering the entire application with every change in state. That way you never have to think about mutating the DOM, and you have less places to screw up.

This is really no different than Angular's value proposition - everything is bound to the DOM via the scope and re-renders automatically with every change in state.

I wouldn't say React isn't fast, but the OP is right, the claim that React is faster than the alternatives is basically just hype (or good marketing).

Going back years to React's inception and public launch, everyone's concern about virtual DOM diffing was that it would be impractically slower than fine-grained dependency tracking. Note that React's own home page expects people may be concerned about performance, and rightly does not respond with sweeping statements promising better-than-Brand-X performance:

> One of the first questions people ask when considering React for a project is whether their application will be as fast and responsive as an equivalent non-React version. The idea of re-rendering an entire subtree of components in response to every state change makes people wonder whether this process negatively impacts performance. React uses several clever techniques to minimize the number of costly DOM operations required to update the UI.

The React team and early proponents got out ahead of this concern, pushing the message that React is fast. It's faster than you'd think, they said, and in some cases faster than the alternatives. Their arguments seem to have gotten distorted and simplified by those repeating them.

The original arguments for why React was fast were:

* The DOM is very slow compared to pure JS. To the extent React's diffing is saving you from re-rendering DOM, you are winning. (Compare it to re-rendering a Backbone template, for example.)

* While it's true that other libraries have schemes that track fine-grained data dependencies, allowing them to go straight to the nodes that need re-rendering without doing any tree diffing, these schemes have their own overhead, which could in theory be just as high as React's.

When I pressed a couple React devs on the second point, it was clear they couldn't argue that tracking data dependencies would be worse than diffing necessarily or in general. Rather, they had concluded the two approaches were comparable in practice.

In summary, the DOM is pretty slow, and virtual DOM diffing is pretty fast. It means you don't have to track data changes at a fine-grained level, and you never over-render the DOM. Performance is comparable to other leading frameworks.

There's an interesting video by Netflix where they discuss using React in their stack. To increase performance on many of Netflix's TV or Console based UI's they have their own rendering engine they're using instead of the manufacturer's browser engine. This means any of React's "speed" improvements are a moot point so instead they use it because of its simplicity for UI layouts.

https://www.youtube.com/watch?v=eNC0mRYGWgc

> DOM diffing isn't there to make React faster than everything else ever imagined.

This is not how React has been sold.

I was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit.

For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Facebook's ad example, the React method of rerendering everything definitely makes things easier. But in most applications, I think such a complex UI is usually rare and ~80% of the UI screens are usually fairly simple. For the majority of UI screens, React or perhaps React+Flux complicates things by adding unnecessary boilerplate even when using third party Flux implementations.