Hi, I'm Jordan from the React team. I'm happy to answer any questions about React Native, but @vjeux will be giving a more thorough talk tomorrow that you won't want to miss (if you're at ReactJSConf), so I might wait for him to answer some of them.
This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.
There will be more detail tomorrow, but at a high level:
* 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
Will this layer be released as a separate project so that other projects like raynos/mercury [2] or elm [1] can target this interop layer?
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.
Since we've heard Facebook Groups is built with it, and it's said to be iOS/Android - to what extent is the choice to build Groups with this responsible for the fact it's not in the Play store? Basically, if Groups is ever coming to Android is this helping or hindering porting?
I know it's a bit of an orthogonal concern, but will this project provide a way to style native apps using web technologies (e.g. CSS) as well? I'm very excited about building native apps with React, and would be even more so if I could also leave behind the very-poorly-designed Android style primitives.
Apologies - In at the deep end with a very specific (hardcore?) question.
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.
I'm not at the conference and haven't had a chance to read too much into this yet (so if the answer is just wait you'll see that's good :D)
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?
Wow. It looks like we're going to have to make our platform (http://platform.qbix.com) integrate with React out of the box. This sounds pretty awesome.
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?
"React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1]
"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]
"iOS and Android native using all the same ideas as React, all the power of native." [3]
React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue?
"learn once, write everywhere" - I like the sound of that! But I guess in the spirit of React this is still only the "V" in MVC right? I don't suppose they are planning to broaden the scope to anything other than rendering views. So if you want to use this to build native apps, I guess you are going to have to integrate another cross-platform solution for storage/sensor APIs?
* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.
* The code you write runs in a Javascript interpreter on the background thread.
* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.
* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.
Has anyone asked if this can use other JS libs other than just React ones? Also, if it's just using say JavaScriptCore and rendering native, I assume this means speed limitations imposed by the lack of Nitro/etc on the UIWebView are moot?
This is awesome news. I've been working on a desktop application using React, node-webkit and browserify and it's been a great development experience. Being able to leverage web technologies to build native apps has been a huge time saver. However, I'm relying on the NodeJS components in order to do things like access the file system and fork commands. I'm wondering how React Native will handle this functionality. Will it be an extended API or can you only do AJAX calls? Either way it's very exciting.
Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in terms of whatever native capability exposed. You can totally use npm modules, provided any module that it uses is polyfilled.
I this this is a great mentality over the classic write once run everywhere approach.
We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.
I can't wait to see more details about this. I hope this isn't another botched attempt at trying to solve the cross compiled native app challenge. I've seen and signed up for so many hype machines for solving this problem including plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've invested time in learning about all of these platforms, but in the end they all fell short in some way or another. I have high hopes for $FB though because I've really enjoyed most of the projects they've open sourced including React and Pop. Personally, it's been easier for me to just learn and use Swift/Obj-C. The main caveat is that my apps are limited to running on iOS.
Hi, I'm just reading through the ReactJS docs for the first time, and I found something peculiar. Let me explain.
So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified.
I can understand this, but... The DOM is already incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method?
Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating only the display.
I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO.
This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!
Yes, the whole system is just basically component rendering (react) + a message bus oriented architecture (flux). The architecture is not novel, but I think the big change between React Native (or whatever they're going to call it) and any actual native application is the same difference between approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform independence.
The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
It occurs to me that, for years, web platforms sought to keep developers from ever having to touch dirty old JS. I can remember all sorts of overcomplicated ASP.NET widgets that were like that.
Now we want JS and don't want to deal with gross native APIs. Perhaps it's not the same "we", though I personally am very excited about this. I love JS and I think React's ideas are the right ones for building UIs.
Cool. I've always thought that the native view layer is better viewed analagously to how web developers tend to view the DOM: a low(ish)-level API upon which to build abstractions that better fit the domain.
Hopefully, we will come to view manual NSView slugging in the same way that we'd now view building a single page webapp entirely with jQuery.
I have long questioned the validity of middleware (for the lack of better terms, please don't be pedantic) to create native applications.
I get it, HTML can replicate performance of native apps to a certain extent now, but it's also bound by restrictions that native apps aren't.
Speed of innovation being one. HTML5 is a large ship that takes a long time to evolve (in comparison). iOS and Android aren't, by the same means. Particularly iOS since Apple has a habit of introducing backwards compatibility breaking new features.
I don't understand fully how hybrid made apps will ever be able to properly compete with a native platform for this reason alone, not mentioning some of the other problems that plague hybrid and middle ware apps.
What's the difference between this and websites competing with native Windows/Mac OS/Linux apps? Sure the performance isn't quite as good, but not being locked to a platform is a huge benefit.
This is huge. There are so many approaches to cross platform mobile development, yet none of them really make it easy to integrate a full stack web platform. This is one step closer.
So...a JS interface to a server that creates native views. I don't get it, what is all the hype about? You've got an extra layer and level of abstraction (read: complexity) in your pipeline. I don't see how you can abstract away the idioms of a platform - they're native. 'Write once, run everywhere' has failed time and time again. So marketing changed its tune to 'Learn once, run everywhere' and now people are gushing how HUGE this is?
[+] [-] jordwalke|11 years ago|reply
This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.
[+] [-] peterhunt|11 years ago|reply
* 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
[+] [-] malandrew|11 years ago|reply
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
[+] [-] mcintyre1994|11 years ago|reply
[+] [-] mcjiggerlog|11 years ago|reply
Does it allow you to render native components with JSX as opposed to only DOM elements? Can you mix the two, somehow?
[+] [-] jordwalke|11 years ago|reply
I'll try to address some of the other more specific questions inline.
[+] [-] kcorbitt|11 years ago|reply
[+] [-] magnatronus|11 years ago|reply
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 :-)
[+] [-] danabramov|11 years ago|reply
I dreaded my Xamarin build times..
[1]: http://gaearon.github.io/react-hot-loader/
[+] [-] Feeble|11 years ago|reply
[+] [-] dengar007|11 years ago|reply
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?
[+] [-] rajington|11 years ago|reply
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.
[+] [-] zkhalique|11 years ago|reply
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?
[+] [-] mrdrozdov|11 years ago|reply
[+] [-] hitlin37|11 years ago|reply
[+] [-] thramp|11 years ago|reply
[+] [-] jnbiche|11 years ago|reply
[+] [-] curiously|11 years ago|reply
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?
[+] [-] colinramsay|11 years ago|reply
"React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1]
"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]
"iOS and Android native using all the same ideas as React, all the power of native." [3]
React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue?
[1] https://twitter.com/AnnaPawlicka/status/560505089207463936
[2] https://twitter.com/floydophone/status/560504204343521280
[3] https://twitter.com/voodootikigod/status/560503641920921600
[+] [-] threepointone|11 years ago|reply
cannot wait for more details.
[+] [-] bendyBus|11 years ago|reply
[+] [-] spicyj|11 years ago|reply
https://twitter.com/andy_matuschak/status/560511204867575808
[+] [-] sudhirj|11 years ago|reply
* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.
* The code you write runs in a Javascript interpreter on the background thread.
* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.
* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.
[+] [-] devgeeks|11 years ago|reply
[+] [-] binocarlos|11 years ago|reply
[+] [-] mcao|11 years ago|reply
[+] [-] hardwaresofton|11 years ago|reply
That said, their success (over something like node-webkit + react) will definitely depend on how well they match and integrate the native APIs.
[+] [-] amasad|11 years ago|reply
[+] [-] e0m|11 years ago|reply
I this this is a great mentality over the classic write once run everywhere approach.
We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.
[+] [-] scribu|11 years ago|reply
I can't help but think about that other chestnut, "A determined programmer can write Fortran in any language."
Of course it makes sense to apply a pattern that you know worked great in the past. The tough part is deciding when it's worth trying something else.
[+] [-] joeblau|11 years ago|reply
[+] [-] amelius|11 years ago|reply
So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified.
I can understand this, but... The DOM is already incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method?
Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating only the display.
So, as you can see, I'm a bit confused...
[+] [-] aakilfernandes|11 years ago|reply
Edit: looks like this isn't hybrid as I assumed but truly native
[+] [-] diverightin63|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] jamesgpearce|11 years ago|reply
[+] [-] TheAceOfHearts|11 years ago|reply
I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO.
This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!
[+] [-] polskibus|11 years ago|reply
[+] [-] hardwaresofton|11 years ago|reply
The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
[+] [-] jasonwatkinspdx|11 years ago|reply
[+] [-] serve_yay|11 years ago|reply
Now we want JS and don't want to deal with gross native APIs. Perhaps it's not the same "we", though I personally am very excited about this. I love JS and I think React's ideas are the right ones for building UIs.
[+] [-] chrisdevereux|11 years ago|reply
Hopefully, we will come to view manual NSView slugging in the same way that we'd now view building a single page webapp entirely with jQuery.
[+] [-] akfanta|11 years ago|reply
[+] [-] jrm2k6|11 years ago|reply
[+] [-] sekasi|11 years ago|reply
I get it, HTML can replicate performance of native apps to a certain extent now, but it's also bound by restrictions that native apps aren't.
Speed of innovation being one. HTML5 is a large ship that takes a long time to evolve (in comparison). iOS and Android aren't, by the same means. Particularly iOS since Apple has a habit of introducing backwards compatibility breaking new features.
I don't understand fully how hybrid made apps will ever be able to properly compete with a native platform for this reason alone, not mentioning some of the other problems that plague hybrid and middle ware apps.
[+] [-] RussianCow|11 years ago|reply
[+] [-] alwaysdoit|11 years ago|reply
[+] [-] aceperry|11 years ago|reply
[+] [-] tilt|11 years ago|reply
I'd bet Angular going Native first, though, I guessed it was coming with 2.0
[+] [-] aoakenfo|11 years ago|reply