I'm Jordan and I'm on the React (and React Native) team. There's been some great questions and insight on this thread. React Native offers a ton of benefits around productivity (and ability to use React of course), but since there are many questions about performance, I thought I'd share some of my own personal perspective on the matter.
React Native is very different than other approaches because:
1. We're not promising to give you One Weird Trick that allows you to change nothing about your development philosophy/practices and yet automatically create excellent mobile experiences. If you're developing for mobile, and you want an excellent user experience, you must care about performance and you must care about programming nuanced interactions. Behind any great mobile experience, is someone who cared. Don't believe anyone that tells you differently. However, I feel that the amount of work that React Native asks of developers in order to achieve it, is much less than any other alternative that I've seen.
2. React Native doesn't use the DOM at all. React naturally tames many of the performance issues that typically arise from unpredictable programming practices in the browser, but that can only get you so far. React Native takes it to the next level, beyond what can be done in the browser. React Native shows that ReactJS has always been more about "zero DOM" than "virtual DOM" (contrary to popular belief).
4. React Native is different because we want to keep some of the best parts about web development. Just because we want the performance and resource control of native views, that doesn't mean we should abandon the great things about the web. With React Native, you can use CSS FlexBox to lay out your native views, and many other familiar style attributes - but without the catastrophic CSS style reflows. The event system also works exactly as it does in your React apps today because it runs the same library code. By building in terms of the subset of web styles/layout that we know we can make fast native implementations for, it allows developers to build great apps today without setting back progress of the web in the future. I feel this is strictly better than encouraging developers to abandon anything remotely resembling web technology and instead learn a completely different toolchain (or two or three).
3. React Native is different because it makes high quality apps written in JS possible. With browsers, you will likely run up against a fundamental limitation and there's nothing you can do about it. Either you don't have access to a platform component (certain scroll view with physics/Maps), or the interaction that you're implementing keeps getting interrupted by image decoding and there's nothing you can do about it.
With React Native, you can do something about it. You can build ReactJS apps using native platform views that could never be implemented in JS (like Maps), and you can also build using higher performing granular building blocks (multi-threaded decoded <Image />) (<View/> blocks that don't use the DOM at all). The result is that this unlocks an unprecedented level of quality that feels great and matches the platform characteristics.
Is the JavaScript 'react host' implemented in native (Objective-C/Swift/Java) language and interpreted during runtime? How are the calls between threads managed - especially wrt marshaling of data structures?
Flux store now originates from native source - do we now have a 'native -> JS interpreter -> native' double transition on every flow?
If the JavaScript is interpreted, would hot-loading mid-flight to change behavior of the native app be possible?
Do you guys have a set of cross platform components like <Image> , <View> , <Map> that will work across Android , iOS and Web ?
The native components might behave slightly different on each platform so I was wondering if you guys have subclassed the native components to behave similarly on all platforms.
We have a <View> and <Image> that works on iOS and Android. We also had web implementations working as a proof of concept but I'm curious if the community would be more interested in helping us implement/maintain the web implementations since we want to focus more on the integrations with each native platform for now.
You're probably aware, but it's always good to keep in mind that we don't have a goal to allow people to "write your app once, run anywhere". You should be able to share as much code as you want to share, but the truth is that great mobile experiences design not only for the platform, but even for the device. We should build apps that take advantage of the extra screen real estate on an iPhone6+, for example. So even within a single platform, you'll want to design specific experiences, and the same goes for implementations across different platforms.
That's interesting. I guess I can't really understand it until I see it finally released. A set of basic widgets like Lists,Sliders and Switches should definitely cover most use cases.
How are react native apps architected ?
Is it something like a model that is written in pure JS that is common for all platforms ?
So after I've created the model in JS , would I have to tailor the render() method for each platform ?
Avoiding CSS reflows in modern browsers should be pretty well documented, and I imagine it only makes sense to discuss reflows in a particular browser.
@vjeux will cover more about the style/layout API in React Native tomorrow, but the main point I wanted to get across is that React Native's style rules are a limited subset that are generally cheaper to compute. More importantly - the result of these computations aren't given to the JS environment in a synchronous manner. You can't read/write/read/write style properties/computations and inadvertently trigger more reflows than necessary. I've seen that pattern make web experiences unusable. In React Native, reads must be done asynchronously, and they are batched together for efficiency. Not only is this one major footgun that React Native takes away, but the asynchronous nature also means that style computation (layout primarily) can be done in a different "pipeline" stage, which opens up future opportunity to parallelize that work with JS execution.
React Native is very different than other approaches because:
1. We're not promising to give you One Weird Trick that allows you to change nothing about your development philosophy/practices and yet automatically create excellent mobile experiences. If you're developing for mobile, and you want an excellent user experience, you must care about performance and you must care about programming nuanced interactions. Behind any great mobile experience, is someone who cared. Don't believe anyone that tells you differently. However, I feel that the amount of work that React Native asks of developers in order to achieve it, is much less than any other alternative that I've seen.
2. React Native doesn't use the DOM at all. React naturally tames many of the performance issues that typically arise from unpredictable programming practices in the browser, but that can only get you so far. React Native takes it to the next level, beyond what can be done in the browser. React Native shows that ReactJS has always been more about "zero DOM" than "virtual DOM" (contrary to popular belief).
4. React Native is different because we want to keep some of the best parts about web development. Just because we want the performance and resource control of native views, that doesn't mean we should abandon the great things about the web. With React Native, you can use CSS FlexBox to lay out your native views, and many other familiar style attributes - but without the catastrophic CSS style reflows. The event system also works exactly as it does in your React apps today because it runs the same library code. By building in terms of the subset of web styles/layout that we know we can make fast native implementations for, it allows developers to build great apps today without setting back progress of the web in the future. I feel this is strictly better than encouraging developers to abandon anything remotely resembling web technology and instead learn a completely different toolchain (or two or three).
3. React Native is different because it makes high quality apps written in JS possible. With browsers, you will likely run up against a fundamental limitation and there's nothing you can do about it. Either you don't have access to a platform component (certain scroll view with physics/Maps), or the interaction that you're implementing keeps getting interrupted by image decoding and there's nothing you can do about it.
With React Native, you can do something about it. You can build ReactJS apps using native platform views that could never be implemented in JS (like Maps), and you can also build using higher performing granular building blocks (multi-threaded decoded <Image />) (<View/> blocks that don't use the DOM at all). The result is that this unlocks an unprecedented level of quality that feels great and matches the platform characteristics.