I'm part of the group that thought "what the hell?" when I first saw the React syntax - but seeing this has completely changed my mind and I'm really looking forward to picking up React as soon as possible.<p>If this delivers on its promises (no reason to assume it won't, seeing as it's already being used in large apps) then it's going to change the mobile development landscape.<p>It sounded like they may even be hinting at in-browser testing the way they were knocking on provisioning profiles and perhaps maybe even some sort of live-reload development tool? I'm really interested in seeing what kind of tools Facebook will make available along side the core React Native project. Mind you, this is a huge gift even if they don't have any fancy tools to go along with it.<p>Really excited, thanks FBOS team.
We just demoed something similar at the GWTCreate conference, an Angular-like library called Singular (<a href="http://daniel-kurka.de/talks/gwtcreate15/singular.pdf" rel="nofollow">http://daniel-kurka.de/talks/gwtcreate15/singular.pdf</a>)<p>It differs in that it uses the same techniques as Google Inbox to run native code. We cross compile to Objective-C with j2objc, and cross-compile to JS via GWT, the data binding, controllers, are shared code on all platforms that run full speed native, while the UI templating language on each platform is platform native (e.g. angular directives directly in Android XML files)<p>It produces completely platform-impedance matched apps on each platform (e.g. native on mobile, JS on Web) while allowing the continued use of the regular UI design toolchains people are used to (Android Studio/Xcode Interface Builder)
I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default.<p>I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.
So I have a simple question; how is this better than Swift or Objective C? It seems like Facebook has done everything in its power to avoid writing Objective C. I am also interested to know if this is what powers the current 1.7 star rated Facebook app. I am just having a hard time understanding how Facebook has earned much credibility with their mobile efforts. Also, how is this different or better than Ruby Motion? I just don't get it. We've had a lot of these fake native solutions but how does it work with existing Cocoa libraries, etc. I think the bigger question is why? Is Facebook allergic to actually writing Java ObC or Swift? Before the downvotes, consider the history and track record and quality of Facebook on mobile. I honestly don't know the answers to the above questions (they aren't completely rhetorical.)
Well, my money is on this (concept if not implementation) being the future of client-side development. Absent horrific performance/robustness problems, which seem pretty unlikely from this team, this is sounding like the droids we were looking for, the holy grail ring to unite us all, web and native.<p>And did even Steve Yegge ever see this next big language coming?
Here's the moment in the video where it's announced: <a href="https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341" rel="nofollow">https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341</a>
I think this can be really amazing as is react js now.<p>--<p>I had to build a simple at first but very complex under the hood.
I wrote that app in a weekend with react and was a ton fun and most important worked well since day one.<p>I have been out from the web development since like 1.5 year, but yeah IMO <i>react is the best thing happened to javascript since ... ever.</i><p>Thanks again guys!
Wow. I've been struggling to teach myself objective-c, never getting beyond the simple tutorials. So I'm happy to try this out.<p>I currently have an MVP in ionic framework and would love to port this over to react. Though I should say that Ionic is amazing in its own right.<p>Also, I tend to agree with some of the comments in this thread -- regular Joe user can't really tell the difference. Ionic on an iPhone looks damn-near close to native. Android leaves a little to be desired.<p>Nice work React team
Sorry, dumb question, don't feel like watching the video:<p>What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?
Just a minor quibble; I think the speaker is a bit too negative about faux-native apps, especially with React. For example, see this demo by Pete Hunt:<p><a href="https://medium.com/@floydophone/building-a-real-time-frosted-glass-effect-on-mobile-web-87ce4a41019f" rel="nofollow">https://medium.com/@floydophone/building-a-real-time-frosted...</a>
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.<p>React Native is very different than other approaches because:<p>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.<p>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).<p>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).<p>3. React Native is different because it makes high quality apps written in JS <i>possible</i>. 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.<p>With React Native, you can do something about it. You can build ReactJS apps using native platform views that could <i>never</i> 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.
What is the defacto best way to learn React? I like the architecture and the coding style, but there doesn't seem to be a lot of talk about best practices.
I wonder why it is such a big of a deal of not having DOM API:s on the WebWorker thread? I think the discussion from Browser vendors is that there is no use case or benefit of having them there.<p>And not having the "native feel" or performance. I think browser vendors are on the verge on closing this gap totally. If not browser vendors, hardware will do it.
When I tried similar solutions (running business logic in JS and abstracting native platform specific UI implementations), one of main problems I encountered was that JS was running in a clean VM while most libraries rely in some way on either browser or node.js environment.
I wonder if React Native addresses this.
That sounds amazing. It's been a while since I haven't been that excited about a framework. Native wrappers are so hard to create and maintain that it's promising to have a company like Facebook behind one.<p>I can't wait to have access to this repo to see source code and examples.
Can someone elaborate on how React Native would fit into the app development workflow (iOS)?<p>Having a brief look over the ReactJS webpage, it seems like it would replace view controllers and perhaps Storyboards?<p>Or are we talking about writing the entire application in Javascript, declaratively?
From the video, Facebook mentions that they are using the React native for the Facebook iOS groups application. Theres a live demo to demonstrate. Video starts at 24:05.<p>[1] <a href="http://youtu.be/KVZ-P-ZI6W4?t=24m5s" rel="nofollow">http://youtu.be/KVZ-P-ZI6W4?t=24m5s</a>
[2] <a href="https://itunes.apple.com/us/app/facebook-groups/id931735837?mt=8" rel="nofollow">https://itunes.apple.com/us/app/facebook-groups/id931735837?...</a>
Can anyone please explain what a "declarative API" is, and why that is better than an imperative? He claims this is the best part of the framework, but I'm just left with a big "what?" since I don't understand what the hell that sentence means.<p>I mean he admits he had to build a bunch of products before he understood the concept, but didn't waste a single slide to explain it in the presentation.
<a href="https://www.youtube.com/watch?v=KVZ-P-ZI6W4" rel="nofollow">https://www.youtube.com/watch?v=KVZ-P-ZI6W4</a><p>Look at 10:00 ... that sounds very much like what we were going through and building at the exact same time<p><a href="http://platform.qbix.com" rel="nofollow">http://platform.qbix.com</a> ... self contained components, completely parallelizable etc. Also in PHP and JS :)<p>And it all works!
I understood that the native react serializes the ui "DOM" to some format and sends it to the native process. Will the native rendering engine be open source and/or will the protocol be open/specified ? This could be handy for embedded targets.
I bet someone is planning to write a Markdown editor using React Native. Maybe a text editor is a good test if React Native app can be as good as native app.
A lot of people here feels offended by new ideas. I bet that many here commented even before the end of the video, and probably never used React on real apps. Could We avoid the tribalism and territorialism, please?
Basic question - does this make it easier for someone who knows (or can hack around in) JS to create a native android app? I'm thinking/hoping yes from the video and comments...
-- Attention -- Cross posting from the other thread --<p>Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of people here is comparing this announcement from the react team to the Titanium Mobile SDK. I’d like to give some info to shed some light on the differences, and probably anticipate the challenges they have to (or had to) solve.<p>## Architecture<p>Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains.<p>Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind.<p>Titanium SDK follows an OOP-ish, imperative approach. You create views using factories (`Titanium.UI.createScrollView({ })`) and you add those views to parent views (`parent.add(child)`). This is very similar to a browser DOM, and in fact it’s cumbersome to work with. They built an xml preprocessor called Alloy which does a better job at exposing the view hierarchy right in the source, but it just compiles down to JS, `create()` and `add()`.<p>This is important for the evaluation at least for the following reason: every time you update a property on a view (actually on a proxy object to the real view) you’re crossing the bridge and you have to pay that penality. The bridge is the void between the JS runtime’s thread and the main, UI’s one. This is incredibly painful when trying to do JS animations, sometimes if you’re not careful you can get hurt very badly. You can still do great things, but it’s way better to use the native `.animate()` methods, which cross the bridge only twice (at start, and at the end as a callback invoking).<p>On Native React you should not have this kind of problems because changes will be batched and updated on a update loop basis or at least debounced. Or at least optimized in some smart way. I believe.<p>## Layout<p>One big problem will be the layout. Given that they don’t want the developers to understand every layout system every platform provides, they have to normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy to understand even from a web-only dev experience:<p>a) by default everything is absolute positioned,<p>b) you can get a vertical flow layout by setting the 'layout' property on the parent view or<p>c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal.<p>Native React will probably follow a more intimately web-ish approach, just look at this JS/C/Java implementation of the box-model and flex-box specification by Facebook itself [1]<p>[1]: <a href="https://github.com/facebook/css-layout" rel="nofollow">https://github.com/facebook/css-layout</a><p>## Support and limits<p>Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues:<p>1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land;<p>2) they have to follow every release of the platform’s SDK;<p>3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t.<p>Let’s see how Native React will solve this issue.<p>Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this issues. The project is code-named Hyperloop and is already working behind the curtains for the Windows 8 version of the SDK.<p>## Conclusion<p>Because I shamelessy want to karma-drift this topic, I’ll stop here.<p>It’s interesting, but until they show us some (native) code... it’s just ideas.<p>Follow me on twitter (@_pier) and github (@yuchi [2]) for Titanium related stuff.<p>Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)<p>[2]: <a href="https://github.com/yuchi" rel="nofollow">https://github.com/yuchi</a>
Am I getting this right: they use something like Display Postscript[1] instead of the virtual DOM? Are we back in the 80ties?<p>[1] <a href="http://en.wikipedia.org/wiki/Display_PostScript" rel="nofollow">http://en.wikipedia.org/wiki/Display_PostScript</a>
If I'm one of Reacts competitors I'm ecstatic that they're abandoning the web. It reminds me of when Angular wastes energy on angular.dart because of a Google mandate. Didn't help them much.