React is badly designed
pandastrike.com
pandastrike.com
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?
Do you have an update beyond this?
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.
> React is a great tool for many cases, for our particular needs in this particular case I decided it would be easier to just do things for ourselves.
It makes it possible to implement React's componentisation model in a performant manner.
It allows React to not only work in all major browsers today, but to use its SyntheticEvent implementation to patch up and normalise aspects of their behaviour which are important when writing webapps.
While React's ideas about data flow might not be new, the componentisation model it uses to implement them makes it incredibly easy to compose and reuse UI components, with a well-defined method of passing data between them and controlling re-rendering.
It allows React components to be easily pre-rendered on the server and rehydrated to be interactive on the client from the initial markup using the same codebase, making progressive enhancement easier to implement, therefore more likely to be implemented.
That's why the virtual DOM isn't the most interesting thing about React, rather what it enables.
It would be nice if native Web Components just worked everywhere right now, but they don't. Maybe some day React will just another way to implement the innards of a native Web Component, but at the moment it's just better then them.
So yes, you could develop for Web Components today, and it would “work” everywhere and it would be the platonic ideal of future-proof web development. It just wouldn’t be very pragmatic.
[1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[2] http://caniuse.com/#search=shadow%20dom
It passed IE for desktop in mid-2012, and iOS Safari for mobile in late 2012 or early 2013.
I agree with your general point since the all Webcomponents-supporting browsers are barely a majority. But the web looks very different from it did even a couple months ago.