This post is essentially my attempt to answer some of the concerns presented in this opinion posted in HN. The author has likened the success of React with the success of Java, exemplifying how time again, what (s)he identifies as worse technology, has been pushed to a higher popularity rather than more competent alternatives available.
I have been learning new technologies pretty much continuously. It's not impossible, especially if you follow sites like Hacker News, to keep a finger on the direction of the industry, and then try to stay on top of the next new hot technology of the year.
But I hear you on the "worse" technology sometimes winning. You mentioned Java; it was worse than just about all other major contenders, and is only finally losing popularity.
On a current technology fad: React seems to be designed to ignore 40 years of accumulated software best practices.  Separation of concerns? Who needs that any more? And the rationale for it is that it allows teams of 100 developers work together on an app.
Well, separation on concerns is a good thing to have. But only when the concerns actually translate to different responsibilities and not when they are multiple facets of the same problem.
The upcoming Web Component technology is fueled by the widespread need for true component oriented building blocks and popularity of frameworks like Google Polymer highlights it very well.
Open standards? Nah, how about lock-in to custom language extensions that will prevent you from migrating your code to the next web standard! Much better.
The reasons for not using an open standard like web components have been explained by the React team:
It has turned out that the spec is incomplete with regard to things like event delegation and there are still major changes being pushed from various sides, such as Mozilla. What was in Polymer/Chrome is not the final incarnation so we've had to revert some of the support that we already added (e.g. support for event handling in shadow trees).
In terms of strategy, we'll go forward with as if it didn't exist and try to improve interop at the React or React-like component layer instead. I've talked with members of other popular UI frameworks and they seem to feel the same. In fact, we probably have a better chance at implementing solid interop in user land.
In fact there already exist some resources for working with React and Web-components in same application.
Attempts towards seamless incorporation of XML in ecmascript is not a new idea. Actionscript has had that since ages. While E4X is an open standard, pragmatic reasons have been put forward by React team for not embracing it entirely:
All the code is not going to be converted to E4X right away. There's going to be a transition phase where E4X and non E4X code will have to co-exist. The fact that the objects E4X generates are not accessible from non E4X code means that none of the libraries ever written can work with E4X structures.
And how many app teams have 100 or more active developers? Probably fewer than a dozen, and I submit that none of them probably should. Certainly not the Facebook app: It has a lot of features, but not that many features, and yet it has a 150Mb footprint.
When I hear things like that, I can't help but fill in "junior" or "mediocre" in front of "developers." React helps to prevent people from breaking each others' code when you have bloated development teams filled with junior developers. React has some cool ideas, but all told I think it's a step backward for software engineering, and certainly isn't as much of a help for small teams, especially if you want to have a CSS/SCSS/LESS expert styling your product without having to dig through JSX files, for instance.
In a small app with a small team, there is little use for any framework at all, but software applications have this uncanny tendency to unexpectedly grow large depending on changing requirements, expanding scope. Given the above, I would certainly feel more comfortable working on a system where I can change the appearance of a component with confidence that will not introduce subtle changes in totally unrelated parts of my application, probably parts that I know nothing about.
While yes, there are fewer teams that have 100 or more active developers, but high churn rates are an unavoidable problem especially in the startup ecosystems. While a competent developer will certainly be able to jump into an unknown codebase and in due time figure out his/her way - but if the codebase is structured around best practices distilled by the community the time required in the same is drastically reduced. Optimizing the process around that seems like a very good idea.
Adding to the problem is that automated regression testing of CSS is time consuming and error prone. While there are solutions I think the crux of the problem is that our current styling system is a broken technology - globally shared stylesheets are evil and technologies like Radium are steps in the right direction.
While it isn't like we have not tried to solve this problem before, I am really glad to see practical alternatives to stylesheets gathering traction.
I agree, much has been written about these benefits, and the availability of alternatives is not exactly a secret either. I don't have much to add.
Back to the original point, though: You can stay on top of the Hot New Technologies, but when there are good technical reasons to use alternate technologies, stay on top of those as well. And then explain clearly to your clients (or employers) why the current fad is a fad, and how to get the key benefits of that stack without its drawbacks. Oh, and choose clients (or employers) who will listen to strong technical arguments. :)
While I disagree with the primary premise, this is a very strong and sound advise. I whole-heartedly agree that solutions should be rationally vetted and benchmarked before being put to use. I hope that arguments I have presented above are perceived as rationally just. Any comments or suggestions are more than welcome.