* JS engine on a background thread

* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)

* Plug-in for React that speaks that protocol

* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)

* Designed to take advantage of native platform views, NOT be the next Java Swing

I know one complaint among many was that wrapping native API in a new framework can limit access to functionality and customization; you're limited to the choices of the framework designer. Another is debugging is harder since native tools don't understand the framework and you're dependent on the tool chain provided by the framework makers.

What Apple calls "constraint-based layout" is cool, but does not follow the classical definition of what a constraint-based layout actually is. They don't use variables anywhere in the IB UI. You can only define proportions in code which is incredibly clunky.

Anyways, flex-box is not available in IE < 10. IE10 requires ms- prefix. If React makes it available everywhere (IE8+) that will be really great.

The issue is that it’s only width-constrained.

TBH, I don't use React right now but this is a game changer.

mercury was fully decoupled from virtual-dom [0] (such that you can use virtual canvas or virtual-gl). Would be really nice if this stuff can be used by other libraries easily.

[0] https://github.com/Matt-Esch/virtual-dom

[1] http://elm-lang.org/

[2] https://github.com/Raynos/mercury

It's just you don't really need Backbone with React because plain object/array models are more convenient, and controllers aren't needed because there's no need to “orchestrate changes” between view and model. Check out Flux as an example of architecture (not a framework) that works really well with React.

Does it allow you to render native components with JSX as opposed to only DOM elements? Can you mix the two, somehow?

I'll try to address some of the other more specific questions inline.

In Titanium it is difficult, if not impossible without resorting to a Native plug-in (which kinda defeats the object of using it IMHO as this is not 'Learn once, use anywhere'), to re-create an interface similar to the Facebook app. i.e. the vertical scrolling timeline with embedded horizontal scrolling images in each post. (on Android it really does suck) due to issue with memory, threading etc.

So I guess my question is, is it something to that React Native could cope with, or would it potentially suffer from the same memory, threading issues?

And my guess is that at some point it has to surface, so a good architectural comparison would be fab.

Perhaps the Hyperloop/React Native race is on :-)

I dreaded my Xamarin build times..

[1]: http://gaearon.github.io/react-hot-loader/

Can I use the same kind of jsx I am on the web today or is there going to be something different? Will sharing components between web and native mobile apps be possible?

If it's still small do you plan on the majority of future components to be first-party or third-party (community)?

Extremely exciting either way, wish there was a livestream of tomorrow.

In short, how will it work and do you have any links we should check out, or people I can contact? The React virtual DOM has all kinds of elements that map to DOM elements, so how would it render in a native app? What about native APIs and Javascript that can interface with it e.g. like it does in PhoneGap? What is the equivalent here?

Is it like Titanium in some way?

You say this is not DOM or some hybrid solution?

Either this is too good to be true or ground breaking stuff.

Do you mean that react could completely get rid of having to write stuff in Java or Objective-C?

Yes, with React Native you'll be able to write native mobile apps completely in JavaScript.