I agree that it sucks when the "worse" technology wins, but your points on why React is an example of one of these "worse" technologies are seriously misinformed regarding its shortcomings and have largely glossed over some of its most significant merits over existing technology.

> React seems to be designed to ignore 40 years of accumulated software best practices.

Best practices in software is not set in stone. Sometimes you need to break from existing best practices of the past in order to arrive at truly powerful new approaches to solving problems that may not seem intuitive at first, but eventually manage to redefine best practices through their technical merits.

The Virtual DOM and re-rendering on every change is one such approach popularized by React, but it's definitely not the only one, nor is it even the most significant one, in my humble opinion.

Before React, mutable models was the only game in town. Angular imposed mutable models, Ember imposed mutable models, Backbone imposed mutable models, your average custom ad-hoc JQuery framework probably also imposed mutable models. Everyone blindly followed this "best practice" simply because this was the status quo ever since the earliest days of UI development.

React is the first JS UI framework that does not impose a mutable model. And as a result, the ClojureScript community was able to build on top of it and show the world that change detection can be implemented as a constant-time reference comparison when immutable models are used [1]. The immutable models approach was highly unintuitive (who'd have thought using immutable data structures in your model could make your app faster than using mutable data structures, which are intrinsically faster), but its results are clearly evident, and enables nothing short of a quantum leap in UI performance.

[1] http://swannodette.github.io/2013/12/17/the-future-of-javasc...

> Separation of concerns? Who needs that any more?

Your definition of separation of concerns seems to be the need to keep templates, styling and logic in separate files, which seems like a rather superficial distinction to me, to be honest. In any case, as mercurial already mentioned, JSX is completely optional, and React easily allows for you to keep your templates in a separate file from your logic and your styles.

Ironically enough considering your rather petty criticism, React and Flux-inspired architectures like Redux have in fact popularized a much more important separation of concern: the separation of application state vs operations on the application state.

This new separation of concern, along with Flux's insistence on a unidirectional data flow, has removed much incidental complexity from app state management, and enabled a whole new generation of developer tooling like component localized hot-reloading and time-traveling debugging [2].

[2] https://www.youtube.com/watch?v=xsSnOQynTHs

And this is the essence of why React has won over the likes of Angular, Ember, and Backbone. Developers have always been able to build great applications, even in the frameworks that come before React. But React and Flux-like architectures allows developers to manage complexity significantly better than in other frameworks that come before it.

This is why "it allows teams of 100 developers work together on an app". And as a front-end developer who has worked never worked in such 100 developer teams, and only on solo projects and in projects with small 2-10 dev teams, I can state with confidence that I can reap much of the same benefits of this reduced complexity. In fact, I probably benefit even more from this reduced complexity because as a solo/small-team developer, my complexity budget is absolutely tiny compared to what bigger teams can afford.

> Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard!

The standardization process on the open web is painstakingly slow compared to the rate at which new technology is generally adopted and refined. This slow, methodical approach allows standardization committees plenty of time and input to think about every standard being proposed, but it's also one of the main reasons why very few libraries, even those with standardization as the end goal, begins as some kind of standard proposal.

It is much easier to gain traction as a standard if you already have an established implementation in a library/framework that is mature and well-adopted, and can demonstrate the merits of your approach. This is the approach taken by projects like TypeScript, and it's probably safe to assume that many aspects of React will be integrated into various standard tracks in the not too distant future.