Good clickbait, but almost nonsensical article. The idea of supporting web components is great, but it's also a standards process in committee. React and Web Components can play together (https://www.youtube.com/watch?v=g0TD0efcwVg), so why draw some sort of false dichotomy between the technologies.
The thought that went into the virtual dom diffing strategy is an algorithmic nicety that software in general can and has already benefitted from. React itself is an implementation of that which provides real workflow improvements for web and now native platforms. That's pretty awesome and usable right now. I don't see this as a zero sum game, or as an all in investment strategy unless you are going into some arcane questions of licensing, the code and the ideas are out in the open. Ember, mythril, Om have all taken the ideas into new regions.
Even look at the atom editor, they switched to react for their editor component, then realized the general purpose dom diffing strategy which is very fast could still be optimized for their edit window. That's awesome. That idea is decoupled from react. Learning to read react code takes about 1 day to 1 week. It's pretty awesome.
Also, the canard about reactive programming... uhh... I just don't get what you're advertising here? That you're willing to use products like docker and node.js as advertised on your front page, but not react.js because... it's "bad"? Why so inflexible, why not try all the things and use what works as time permits?
I use atom as an editor for markdown. But I don't know about if they're using React in it or not. I don't follow the dev that closely. I am still rather sure you can develop plugins in react, which is fine.
My point being that require('react'); wasn't the best fit for their editor window (which doesn't need events to be intercepted, etc), but the idea behind virtual dom diffing and how they updated their window left an impact. The concepts behind react got them thinking in a new way, which is ultimately much more important than their dependency on a 0.x.y release library.
If anything, the design of react was a stepping stone to where they've ended up now. It wasn't "bad", so much as unoptimized for their specific task. For me I'm glad it can intercept events (usually), since it simplifies cross browser compatibility. Atom is essentially one browser version, so it doesn't need that overhead.
The thought that went into the virtual dom diffing strategy is an algorithmic nicety that software in general can and has already benefitted from. React itself is an implementation of that which provides real workflow improvements for web and now native platforms. That's pretty awesome and usable right now. I don't see this as a zero sum game, or as an all in investment strategy unless you are going into some arcane questions of licensing, the code and the ideas are out in the open. Ember, mythril, Om have all taken the ideas into new regions.
Even look at the atom editor, they switched to react for their editor component, then realized the general purpose dom diffing strategy which is very fast could still be optimized for their edit window. That's awesome. That idea is decoupled from react. Learning to read react code takes about 1 day to 1 week. It's pretty awesome.
Also, the canard about reactive programming... uhh... I just don't get what you're advertising here? That you're willing to use products like docker and node.js as advertised on your front page, but not react.js because... it's "bad"? Why so inflexible, why not try all the things and use what works as time permits?