For me, the most significant benefit of using React is the community around it. Rightly or wrongly, React had been crowned as the darling of "modern front end"

For me, the most significant benefit of using React is the community around it. Rightly or wrongly, React had been crowned as the darling of "modern front end" and that has attracted huge amounts of criticism, debates, and exploration into how we build complex UIs. Over the last year the cumulative output of those people plus the related projects such as Babel and Webpack have collectively taught me a smarter way of developing complex dynamic interfaces for the web. The highest praise I can offer is that for the first time in 15 years I feel like I can bring the same level of engineering to the frontend that has been available to us the backend - code that is predictable, reliable, testable, maintainable, and understandable by others. Having said that, such frantic activity is a double-edged sword. React universe is a rapidly shifting beast - a particular tactic can be the recommended way today, then quickly superseded and discouraged by tomorrow. Some examples include: React's initial createClass() guidance, react-router's "final, final2, final3" API surface, react-dnd's complete and incompatible rewrite between 0.9.8 and 1.0, the many phases of the flux store evolution (from 'just arrays of data', to 'maybe ajax reads', to 'not data at all') etc. In every such case I get annoyed at first, then shortly after I become grateful for the change because the new way _is_ significantly better and it _does_ lead to my app code being appreciably better in structure/flexibility/agility etc. This is great for continuously evolving products - our quality increases with each such iteration. But this can be difficult to budget for, or I do not enjoy going back to the rest of the team with the news that what I asked them to do before should now be avoided. We all learn and our core product benefits, but these quality and engineering efforts are a cost that not every team can maintain indefinitely. Lastly, React is relatively unopinionated itself which means everyone has a different way to consume it. The freedom is there, and I see many teams using it to shoot themselves in the foot. Take the concept of Flux for example - for clean and maintainable code, very few components should ever have the word 'flux' or 'action' or 'store' in them. The overwhelming majority (>80%) of components should be ridiculously stupid, have no state, and certainly know nothing of flux. But the temptation is there - "oh I'll just drop flux inside and boom I have this power to do anything I want from my ProductSummary component"). This leads to the project having way too many moving parts, overpowered components acting at will, unauthorised data access points which cause subtle bugs, and the project ends up being the same unpredictable mess as we'd' have with jQuery. Yes, the rendering is done with React, but that's a hollow gain if the app is still unwieldy. Using React demands discipline and focus to have hard boundaries between components, creating clear and predictable data/action flows, removing as much state as possible, and obsessively guarding and layering app's building blocks. Incidentally, if you do it the 'right' way, React itself will be the most inconsequential part of the system that you can swipe away with ease when a better way to write reliable interface will be inevitably discovered.