I've been playing with Facebook's React to make an internal interactive resource scheduling system for our company. So far I think I'm getting it... and am thrilled with how it works.
React eschews the attempt to split the View / ModelView that are the hallmark of most full-service frameworks. Instead of this separation, React applications are built by defining reusable, nested components, each having a render() method that mixes binding and logic to build sub-parts of a web page using their custom DOM. Each component has an internal mutable state and a set of read-only properties it gets from its parent context. In React, "data binding" is just part of rendering.
Since React owns the DOM, it's incompatible with JQuery; or rather, if you use JQuery, you could do it in a leaf node and manage the boundary carefully. React tracks things by using a hierarchical identifier, each key unique within each level of the structure. It then has a predictable/fast algorithem for detecting changes and updating the DOM. Unless you provide your own component keys (used to build the DOM id) all the way down, you need to use CSS classes (rather than IDs).
Finally, I'd say, React really seems like a library -- and one that has a low API to functionality ratio. That is, it really does something substantial with relatively few things you need to learn. If you have your own in-house framework, it might be something you could weave in gradually rather than do a wholesale adoption of a larger (measured via API surface) framework.
There's quite a functional overlap between many uses of jQuery and what React does.
Ignoring animations and ajax, the core functionality of jQuery orients itself to the concept of progressive enhancement (http://en.wikipedia.org/wiki/Progressive_enhancement), you have a basic functionality of a page in HTML and you enhance that with scripts for better user experience. Hence most of jQuery methods follow the operations required for progressive enhancement: finding DOM stuff and changing it, registering events etc.
This is what in the end conflicts with the design of React. React is (again ignoring server-side-js prerendering) an all-or-nothing approach. The whole dynamic part of the DOM is constructed out of the virtual DOM. There is no no need to find DOM elements, because the React way would just relink your component to the real DOM result of its previous rendering or you find DOM elements of child components via React refs. To follow React design, you only change the real DOM directly if you need to step outside of React to e.g. integrate another library. The normal modus operandi is to just render new new virtual DOM based on your props / state.
You can do some meaningful things with combination of React and jQuery, e.g. just use jQuery's focusin/focusout to make up for the lack of bubbling focus support in React. Mostly though you shouldn't need to -- by design.
It's not really a bug for the same reasons that jQuery implements focus/blur independently from focusin/focusout. focus events just don't bubble out natively so you have to make your synthetic event system do that if you want / need it. jQuery implements it as a separate pair of events, React chose not to / only deviates from DOM behavior in very few instances (onchange). Using jQuery was just easier for my use case which seemed too exotic to claim any kind of general relevance.
I haven't used React, but the approach you describe sounds very much like how early C++ UI toolkits worked. Applications would be built of "reusable, nested components", often called "widgets". The widgets would be placed into a hierarchy, with widgets often creating their ancestors. Widgets would have a paint() method that would take the widget's internal state and the state of the widget's container(s) into account when displaying (or updating a previous display) of the widget.
In general, no. You would typically take your widget, create it, and put it into a widget-agnostic container or layout manager. The widget wouldn't know about it's parent or children. The widgets would communicate by sending signals which bubbled up or down the container heirarchy, triggering repaints, resizes, and so on as needed.
You (and others) say that React can be introduced gradually, but then you say that it owns the DOM and is incompatible with JQuery unless you're careful. How are these reconciled? Can React manage only a subtree of the DOM and let JQ (et al) handle the rest?
Yes; you mount your top-level React component into a <div>, and React won't touch the DOM outside of that.
It also provides hooks that get called throughout the lifecycle of each component, including whenever it's been added to or about to be removed from the DOM. These can be used to integrate non-React Javascript behaviors that want direct access to the DOM, but you still have to properly handle cleaning up when React wants to take your DOM node away.
I have to say that I have gained a certain technical respect for Facebook after reading about React. I don't and have never used Facebook the webapp, so I really never developed interest in their technical stack (I vaguely knew it was originally PHP and they had done some work with HipHop etc.). But this seems like the first thing I've seen in a long time, maybe ever, that could actually make writing webapps pleasurable in the way that functional programming is.
You should also take a look at Javelin then. It's still more of a proof of concept, but if you love functional programming then it (seems promising to be) even more fun than React for building web apps.
Would you consider linking Javelin? I have had some trouble finding it. Apparently it is not on Wikipedia's Javelin disambiguation page, and my google-fu is weak.
...that reminds me an awful lot of ASP.net web-forms. Which isn't a terrible thing... MS had some good ideas with that bizarre framework, it was marred by brittleness, leaky abstractions, and the technology of the day.
ASP.NET Web Forms may have been fine if it was only UI and UI logic rather than an odd mashup of UI + business logic + a crazily complicated page life cycle. The initial versions of ASP.NET MVC used Web Forms purely as a view layer which worked quite well.
At my previous workplace we were converting a classic ASP + ASP.NET Web Forms app to MVC. I really love MVC but I did like the component encapsulation in web forms.
This is false. Although it's true that React makes the most sense when each individual component is all React, it's easy to embed small React components into a non-React application, and you can also wrap small jQuery plugins (like select2, for instance) in React without too much work.
At Khan Academy we've decided to move to React for new JS development but we've had a lot of success moving to it incrementally and building new pieces in React without having to touch the old ones.
You can have jQuery above react - to trigger state change in react's component tree (and DOM rerender). In the same way you can call out jQuery functions that would affect DOM that's not controlled by React.
For manipulating the react-controlled DOM it does not make much sense to use jQuery anyway because react's mechanism are better and come with welcome side-effects (like rerendering to browser DOM only when it is necessary).
React eschews the attempt to split the View / ModelView that are the hallmark of most full-service frameworks. Instead of this separation, React applications are built by defining reusable, nested components, each having a render() method that mixes binding and logic to build sub-parts of a web page using their custom DOM. Each component has an internal mutable state and a set of read-only properties it gets from its parent context. In React, "data binding" is just part of rendering.
Since React owns the DOM, it's incompatible with JQuery; or rather, if you use JQuery, you could do it in a leaf node and manage the boundary carefully. React tracks things by using a hierarchical identifier, each key unique within each level of the structure. It then has a predictable/fast algorithem for detecting changes and updating the DOM. Unless you provide your own component keys (used to build the DOM id) all the way down, you need to use CSS classes (rather than IDs).
Finally, I'd say, React really seems like a library -- and one that has a low API to functionality ratio. That is, it really does something substantial with relatively few things you need to learn. If you have your own in-house framework, it might be something you could weave in gradually rather than do a wholesale adoption of a larger (measured via API surface) framework.