12 ms·

Introducing React Native [video]

542 points by arasmussen 12y ago

uniclaude 12y ago
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. I can't wait to have access to this repo to see source code and examples.
jessep 12y ago
Here's the moment in the video where it's announced: https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341 https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341
- rattray 12y ago
  And just as a heads-up to those who haven't watched, implementation details and code samples are coming tomorrow. But basically the tl;dw seems to be that you can write JavaScript React code that runs efficiently on mobile and renders native primitive components instead of dom primitives (<View> instead of <div>). It also introduces the idea of "Learn once, write everywhere" instead of "Write once, run everywhere", which I think is a great idea.
  - rpwverheij 12y ago
    Is 'tomorrows' video online yet? Can't seem to find it, or has it not been tomorrow yet? :)
- rdudekul 12y ago
  Here is the philosophy behind React Native: https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1725 https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1725 "Learn once, write anywhere."
solarexplorer 12y ago
Am I getting this right: they use something like Display Postscript[1] instead of the virtual DOM? Are we back in the 80ties? [1] http://en.wikipedia.org/wiki/Display_PostScript http://en.wikipedia.org/wiki/Display_PostScript
- jdub 12y ago
  No, React Native translates a declarative API into imperative calls. Just like React does in the browser (after going through the Virtual DOM as, essentially, an optimisation).
  - solarexplorer 12y ago
    Yes, just like the DPS interpreter translates (high-level) DPS into (low-level) pixels. Looks pretty similar to me. (but then I am not overly familiar with DPS or ReactJS) EDIT: To clarify, I am sure that the current UIKit also tries to do optimize rendering. They probably do some kind of internal batching, etc. But they have no (public) data format like DPS or a virtual DOM that is generated, optimized and rendered. I don't think that DPS is all that different.
    - vidarh 12y ago
      It's not similar. Postscript (display or "regular") is imperative. It's an instruction stream. React belongs one level "up", abstracting away the translation from a declarative representation of the view to a stream of calls on some lower level mechanism to reproduce that representation in the most efficient way possible. The basic idea of React is that instead of having your application spitting out an instruction here and an instruction there, which may result in lots of reflows and redrawing, if individual state changes are expensive it can be more efficient to re-create a full representation of the desired state and have an engine compare that desired state to the actual state and figuring out the best possible set of steps to get from the actual to desired state. E.g. the engine may be able to figure out that a subtree changes so much it's going to be best to just replace it wholesale instead of manipulating node by node. The "output" from a React style engine can be a series of DOM manipulations, or it could be DPS instructions, or any number of other things - the idea is very general.
Touche 12y ago
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.
- nkozyra 12y ago
  Where was the web abandoned?
  - Touche 12y ago
    React is no longer a web library, so today.
    - zwily 12y ago
      It's not? I must have missed that announcement.
    - sgrove 12y ago
      React has been carefully designed to encompass better UI patterns regardless of the underlying platform. There are some very thoughtful and capable people working on it. Worth reading Jordan's thoughts here https://news.ycombinator.com/item?id=8962171 https://news.ycombinator.com/item?id=8962171
    - nkozyra 12y ago
      Expansion != abandonment. In fact, were I a "competitor," I would be concerned about the philosophical buy-in that said expansion could induce.
    - cleverjake 12y ago
      I think you misunderstood. they are adding a non web library, not leaving the web.
- jessep 12y ago
  "Abandoning the web" seems a bit strong here. One difference between angular+dart and react+native is this: angular_devs ∩ dart_devs ~= 0 (relative to angular_devs) react_devs ∩ mobile_devs ~= react_devs Almost everyone who uses react also has to do mobile development, and would like a simpler way to do it. This solves a real and widespread need.
stanzheng 12y ago
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. [1] http://youtu.be/KVZ-P-ZI6W4?t=24m5s http://youtu.be/KVZ-P-ZI6W4?t=24m5s [2] https://itunes.apple.com/us/app/facebook-groups/id931735837?mt=8 https://itunes.apple.com/us/app/facebook-groups/id931735837?...
slashnull 12y ago
Sorry, dumb question, don't feel like watching the video: What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?
- kenrose 12y ago
  iOS and Android.
  - deleted 12y ago
    [deleted]
- evv 12y ago
  This is Eric, from the React Native team. We're starting with iOS and Android, which will keep us busy for the foreseeable future. That said, we will open source soon, and we'd be happy to accept help targeting other platforms!
  - omard 12y ago
    Nice! What about windows phones?
  - slashnull 12y ago
    This is awesome. I can't wait for the API docs and sources to be released. Tweets and videos are lousy at conveying information : )
  - jbigelow76 12y ago
    Very interesting. Microsoft allows you to build fully native (not webview wrappers) apps using WinJS, and they have shown that React (along with Angular) can be used to build those apps [1]. I wonder if Microsoft will put resources into bridging the gap between React Native and Windows 10. As a long time web oriented .NET developer wanting to pick up mobile who has been wondering whether to go Cordova or dive in fully native (ObjC/Java/Xaml) this is going to make the choice very difficult. [1] https://github.com/winjs/winjs/wiki/Using-WinJS-with-React https://github.com/winjs/winjs/wiki/Using-WinJS-with-React
owenwil 12y ago
This is amazing - wonder when we can get our hands on it.
rattray 12y ago
I had just started to think about switching to Mithril from React. This completely changed my mind. Incredibly exciting.
DAddYE 12y ago
I think this can be really amazing as is react js now. -- 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. I have been out from the web development since like 1.5 year, but yeah IMO react is the best thing happened to javascript since ... ever. Thanks again guys!
- k__ 12y ago
  > react is the best thing happened to javascript Why?
  - DAddYE 12y ago
    Because when you deal with complex code react make it easier to read and as said in the talk more confident when making changes. On a large codebase we all know that you have to be a good JS dev to keep it well organized well readable etc...
digvan 12y ago
It fails like many other framework tried to create native apps with JavaScript
- onewaystreet 12y ago
  How can you possibly say this without seeing a single line of code?
- sydcanem 12y ago
  Those mobile Javascript frameworks uses the DOM. React native won't.
  - je42 12y ago
    Actually, some don't use DOM. http://openaphid.github.io/blog/2013/01/17/part-i-how-to-choose-a-javascript-engine-for-ios-and-android-apps/ http://openaphid.github.io/blog/2013/01/17/part-i-how-to-cho...
  - digvan 12y ago
    It's not about DOM. UIKit is pretty sofisticated to build layer to translate JS to native code. It needs years of work and constant update.
    - aaronbrethorst 12y ago
      ::cough:: https://twitter.com/andy_matuschak/status/560511204867575808 https://twitter.com/andy_matuschak/status/560511204867575808
      - digvan 12y ago
        He is just talking about layer model. Being iOS engineer for 4 years and Web developer for 5 years, These frameworks only works for certain use cases and at the end you wish that you did the right thing from beginning.
bobajeff 12y ago
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. I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.
- leeoniya 12y ago
  with gpu-accelerated css transitions, requestAnimationFrame, virtual dom and web workers, the experience can be damn close. he makes it seem like "no comparison", this is provably false at least for the apps he demoed. for games, native is still necessary. what react offers beyond performance though, is definitely awesome. imo, the talk comes off a bit like a sales pitch at a pep rally.
  - nemothekid 12y ago
    I don't know - but given Facebook's past with WebView on their flagship app I feel they would be best qualified to say whether or not those solutions once fully implemented are satisfactory. It could be the case that the features you mentioned are suitable today for web applications targeting the latest iPhone on browsers on the latest standards, but not when React was first developed.
  - tomocchino 12y ago
    You're absolutely right that it is possible to get close. I think my main point here, (though I probably didn't cover this well enough and I was being somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the default on web, and it's actually really, really hard to get there. Sorry for coming across as a sales person. Someone tweeted about a previous presentation of mine in the past asking "who the hell is this marketing guy they had do this talk". I assure you I'm not in either marketing, or sales, I just get really excited sometimes.
    - dhaivatpandya 12y ago
rattray 12y ago
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: https://medium.com/@floydophone/building-a-real-time-frosted-glass-effect-on-mobile-web-87ce4a41019f https://medium.com/@floydophone/building-a-real-time-frosted...
- tomocchino 12y ago
  You're not the only person to give me that feedback. :) Check out my other reply as well. I agree it's possible to make things that feel good, it's just very, very hard, and it's certainly not the default.
- peterhunt 12y ago
  If you look at the demo you'll see that while it's likely close to the best you can do with web tech, the physics don't feel correct because we can't reuse the native constants. Also the UI is very flat and simple. More complex UIs would be a struggle without react native.
- aaronbrethorst 12y ago
  The demo doesn't render on Safari on iOS 8. :-\
_pmf_ 12y ago
That's it. I'm finally going to port GridBagLayout to Javascript.
- nogridbag 12y ago
  The memories of GridBagLayout still haunt me to this day (see username). This is a classic gridbag cartoon: http://madbean.com/anim/totallygridbag http://madbean.com/anim/totallygridbag
  - peterarmstrong 12y ago
    Heh, I remember coding a vertical FlowLayout in 1999 (before that was included) out of fear and loathing of GridBagLayout...
  - _pmf_ 12y ago
    The horrible thing is that once I use it for a while, it starts making sense. That's usually the time I stop doing Java for a while.
themgt 12y ago
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. And did even Steve Yegge ever see this next big language coming?
- donw 12y ago
  Having spent the past six or so months working with React and Flux, I sure hope so. For the first time in my technical career, I've actually enjoyed working in Javascript. The real power of React isn't just the virtual DOM -- it's being able to leverage Flux and an immutable, single-source-of-truth app state. Pretty much every time I turn around to build something, this combination has made what used to be an exercise in hair-pulling into an absolute joy.
  - TheCoelacanth 12y ago
    To some extent the virtual DOM is what enables that, because it allows that style of programming while still having good performance.
  - guscost 12y ago
    > I sure hope so. It's looking more and more likely. And I agree, if React + Flux/etc becomes the de facto portable standard for the next generation of web and mobile development, we will be in pretty darn good shape. I've only done some tutorial apps and experimental stuff so far, but they're definitely on to something.
calebm 12y ago
Looks like React is reaching critical mass.
- briandear 12y ago
  Based on what metric? A Facebook team talking about a Facebook framework and a HN thread filled with React enthusiasts? I am not bashing any of it, but to suggest critical mass is a bit immature.
  - hueving 12y ago
    Yeah, I have yet to meet a react developer in person. Maybe the definition of 'critical mass' is just enough fans to have commentors posting about it 24 hours a day. I would say rust has reached critical mass if react has.
  - calebm 12y ago
    The community enthusiasm and features add up to the critical mass necessary to push me into giving it a good look... also, I wanted to say "critical mass" in connection with "React" ;)
potomushto 12y ago
Looks amazing. Is React Native supposed to be just a View lib for XCode project or it will be the platform like Titanium?
- yuchi 12y ago
  Their promise of being cross-platform probably will move them into a cross-env toolchain, a-la Titanium.
aceperry 12y ago
Sounds excellent. I need it today.
bronz 12y ago
What is this and why is it a big deal?
roccod 12y ago
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.
- arasmussen 12y ago
  Yep, you've got the gist of it. We render the app in JS, React creates this view hierarchy (still in JS), this is serialized and sent over the bridge (asynchronously) to the native engine who then creates the equivalent native view hierarchy and renders it. The source code for the iOS native engine (and the JS infra, and some examples) will be given to attendees of React.js Conf tomorrow (Jan 29). The iOS and Android versions of React Native will be open sourced soon! :)
  - roccod 12y ago
    Is this native engine still html based (eg blink engine or webkit) or is it using the platforms drawing engines? We are currently building user interfaces for STB platforms using a a js platform mapped to a native canvas running on v8. If we could use the react protocol it would be great.
    - davedx 12y ago
      Hey, our team is using React to build STB interfaces. Would love to chat about your experiences, drop me an email? davedx@gmail.com :)
    - arasmussen 12y ago
      Nope, there's no DOM or HTML. It's creating native iOS/Android views.
xngzng 12y ago
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.
Toine 12y ago
What about native APIs like in-app purchases, push notifications, ads SDKs, GameCenter ? Will we be able to access those ?
- CCs 12y ago
  Jing said there's full binding and easy access to any native service
iLoch 12y ago
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. 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. 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. Really excited, thanks FBOS team.
- masklinn 12y ago
  > when I first saw the React syntax Do you mean JSX? Because "the React syntax" is just plain JS unless you're using JSX, is it not? IIRC even vdom nodes can be created by hand with literal objects.
  - iLoch 12y ago
    Yeah, JSX. Whoops!
    - masklinn 12y ago
      Yeah it's completely optional, facebook built it because they had built something similar previously and they like it, and I guess it may be simpler for "pure" designers used to HTML and stuff, but it's AOT-compiled to the corresponding JS calls and the mapping is fairly simple: <Component1 attr1="value1" attr2={foo}> <Component2/> <Component3/> </Component1> becomes (more or less) Component1( {attr1: "value", attr2: foo}, Component2(), Component3() );
- rattray 12y ago
  You really don't need to use JSX; I can't stand the look of it but love using React (I use it with CoffeeScript, but don't mind it with raw JS either).
rajington 12y ago
Will the talk dealing with Relay and GraphQL also be uploaded?
jordwalke 12y ago
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.
tinganho 12y ago
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. 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.
- joesb 12y ago
  It's the same with all other native UI, though. .Net Winform, WPF, Swing, etc., they don't allow you to make modification to UI outside main thread.
briandear 12y ago
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.)
izietto 12y ago
Please, could anyone write a tl;dw (too long; didn't watch)?
- CmonDev 12y ago
  Yeah, is it really native or is it just marketing speech about same ol' crappy JS?
- ryannevius 12y ago
  Scroll down? CTRL + F the comments, and you'll see that someone did a "tl;dw" hours ago
  - izietto 12y ago
    I scrolled but I didn't notice it, thank you
- clay_to_n 12y ago
  You can skip the first 20 minutes if you just want to learn about React Native.
cromwellian 12y ago
We just demoed something similar at the GWTCreate conference, an Angular-like library called Singular (http://daniel-kurka.de/talks/gwtcreate15/singular.pdf http://daniel-kurka.de/talks/gwtcreate15/singular.pdf) 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) 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)
- eyko 12y ago
  After reading through your presentation, I have to say Singular does not look at all similar. And it's Java, so different audiences I guess. Angular in Java is not a bad idea though.
  - cromwellian 12y ago
    Similar in this sense: 1) it uses templating (in our case, HTML, Android XML, and XIB) 2) it is cross platform, runs everywhere, even server 3) it produces native apps It's different in this sense: 1) it doesn't do DOM diffing, it does two-way data-binding 2) it's statically compiled to native code, it doesn't try to run JS in native platforms, and doesn't require any async seems between between the native platform (it's all static linkage) There may be other differences. The audience is Java and people who want no-compromise native integration. We target 70% code sharing between platforms, but expect the UI to be rebuilt for each platform. The core engineers behind J2ObjC were those who built Swing at Sun. We're pretty sour on the idea that write-once run-anywhere UIs are possible. Best experience dictates custom design for each frontend IMHO, and shared UI widgets may get you into an 'uncanny valley' state where you're composing the native widgets in ways that are alien to platform specific style guidelines.
    - rahimnathwani 12y ago
yuchi 12y ago
-- Attention -- Cross posting from the other thread -- 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. ## Architecture Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains. Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind. 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()`. 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). 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. ## Layout 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: a) by default everything is absolute positioned, b) you can get a vertical flow layout by setting the 'layout' property on the parent view or c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal. 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] [1]: https://github.com/facebook/css-layout https://github.com/facebook/css-layout ## Support and limits Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues: 1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land; 2) they have to follow every release of the platform’s SDK; 3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t. Let’s see how Native React will solve this issue. 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. ## Conclusion Because I shamelessy want to karma-drift this topic, I’ll stop here. It’s interesting, but until they show us some (native) code... it’s just ideas. Follow me on twitter (@_pier) and github (@yuchi [2]) for Titanium related stuff. Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab) [2]: https://github.com/yuchi https://github.com/yuchi
daemonk 12y ago
I wonder how they are handling persistent storage and multi-threading if at all.
gadders 12y ago
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...
edygar 12y ago
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?
sheraz 12y ago
Wow. I've been struggling to teach myself objective-c, never getting beyond the simple tutorials. So I'm happy to try this out. 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. 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. Nice work React team
- mattdeboard 12y ago
  Dude you should try Swift. Much easier.
  - sheraz 12y ago
    I would, but I have not upgraded my macbook to mavericks yet. :-/
- squeaky-clean 12y ago
  Same situation here, using Ionic, but this seems extremely cool. I'll definitely build something with ReactNative as soon as I can. We're only making a news app, but Ionic feels completely native once we optimized it correctly and use the latest beta features. As for Android being slow does that include 4.4 devices, or just older version of Android? If it's older devices, you should try the new Ionic beta with Crosswalk integration (you'll need to install/enable Crosswalk, but it's very easy to do). Sadly, it'll add about 25mb to your .apk, but on phones earlier than 4.4 the performance boost is at least 10x if not more.
  - sheraz 12y ago
    On your suggestion I tried it on my phone (4.1.2). The rendering improved, but speed is still an issue. Scrolling with big images is jerky. However, I have not yet optimized images or CSS. I'll probably spend next week looking into optimizations for ionic.
    - 12y ago
ceeK 12y ago
Can someone elaborate on how React Native would fit into the app development workflow (iOS)? Having a brief look over the ReactJS webpage, it seems like it would replace view controllers and perhaps Storyboards? Or are we talking about writing the entire application in Javascript, declaratively?
- rickyc091 12y ago
  React follows an approach similar to ReactiveCocoa (https://github.com/ReactiveCocoa/ReactiveCocoa https://github.com/ReactiveCocoa/ReactiveCocoa). It helps modularize the code into components instead of having a spaghetti string mess that often happens in view controllers. Currently there is no details on React Native, however, I don't believe it would replace the Storyboard as views are still necessary for the React code to interact with the components. What you would be doing is coding in JS and behind the scenes your app would interact with the views and do the necessarily updates. I'm guessing it'll be a hybrid approach. While you'll most likely still need to know Obj-C or Swift, you can probably get away with a lot of boiler plate code with React.
- peterhunt 12y ago
  You basically instantiate a view controller with a string of js and it works. Can drop into existing app for one view.
kas0 12y ago
Already done with Smartface App Studio.
mwcampbell 12y ago
Sounds exciting. When is the source going to be released? Also, how much of the app logic can be implemented in cross-platform JS versus native code?
somethingreen 12y ago
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.
- pluma 12y ago
  React is pretty much environment agnostic. It supports server-side rendering because it works without a DOM. Based on how they are specifically talking about not sharing code but sharing knowledge (i.e. same API, different components), I'd assume the environment-specific stuff is implemented by the actual primitive components (View, etc, the equivalent of div, etc, in the browser). They make it very clear that you won't be taking your web app and just magically have it work natively. You'd just write your native app using React, too.
debacle 12y ago
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.
- lllllll 12y ago
  I second this
jesalg 12y ago
Recruters: Looking for ReactJS Native developer with 5+ years of experience!
- mendelk 12y ago
  According to the video, they were using ReactJS internally for four years internally before open-sourcing it, so it might be possible :)
themgt 12y ago
React Native, in retrospect ... the day the Berlin Wall fell?
Nilzor 12y ago
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. 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.
- robertfw 12y ago
  The briefest explanation is that imperative is a list of instructions describing how you want something done. A declarative approach describes what you want done. The typical example for this is SQL - you don't tell an SQL database how to run a query, you tell it what you want, and it figures it out. In Reacts case, you describe your application in terms of components that know how to render themselves given different sets of data, or states. When the application state changes, the entire application is re-rendered. The "magic" of React is that the use of a virtual dom to create an efficient diff from the current dom state to the new dom state allows this to be very performant, ensuring a minimum of actual dom changes are made. The resulting components are much, much easier to reason about. You can see, looking at the code, exactly how the component will behave given different data. In essence, what you see is what you get. This is a far better dev experience than working with components that can be mutated by events; you need to build a mental model of all the various states that the component could find itself in. I was driven to this approach using Backbone to tame a particularly complex interface, similar in complexity to the ads example shown in the video. But as mentioned, doing this naively (in this case, re-rendering a backbone template instead of mutating it), leads to all kinds of user interface glitches. React smooths over those glitches.
  - Nilzor 12y ago
    Thanks, much clearer now. :)
kenshin03 12y ago
On iOS I'd imagine this uses the underlying Webkit JavascriptCore engine. How about Android? Do I need to embed a V8 in my app if I want to use React Native?
zkhalique 12y ago
https://www.youtube.com/watch?v=KVZ-P-ZI6W4 https://www.youtube.com/watch?v=KVZ-P-ZI6W4 Look at 10:00 ... that sounds very much like what we were going through and building at the exact same time http://platform.qbix.com http://platform.qbix.com ... self contained components, completely parallelizable etc. Also in PHP and JS :) And it all works!

542 points by arasmussen 12y ago

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. I can't wait to have access to this repo to see source code and examples.

jessep 12y ago

Here's the moment in the video where it's announced: https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341 https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1341

rattray 12y ago
And just as a heads-up to those who haven't watched, implementation details and code samples are coming tomorrow. But basically the tl;dw seems to be that you can write JavaScript React code that runs efficiently on mobile and renders native primitive components instead of dom primitives (<View> instead of <div>). It also introduces the idea of "Learn once, write everywhere" instead of "Write once, run everywhere", which I think is a great idea.
- rpwverheij 12y ago
  Is 'tomorrows' video online yet? Can't seem to find it, or has it not been tomorrow yet? :)
rdudekul 12y ago
Here is the philosophy behind React Native: https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1725 https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1725 "Learn once, write anywhere."

solarexplorer 12y ago

Am I getting this right: they use something like Display Postscript[1] instead of the virtual DOM? Are we back in the 80ties? [1] http://en.wikipedia.org/wiki/Display_PostScript http://en.wikipedia.org/wiki/Display_PostScript

jdub 12y ago
No, React Native translates a declarative API into imperative calls. Just like React does in the browser (after going through the Virtual DOM as, essentially, an optimisation).
- solarexplorer 12y ago
  Yes, just like the DPS interpreter translates (high-level) DPS into (low-level) pixels. Looks pretty similar to me. (but then I am not overly familiar with DPS or ReactJS) EDIT: To clarify, I am sure that the current UIKit also tries to do optimize rendering. They probably do some kind of internal batching, etc. But they have no (public) data format like DPS or a virtual DOM that is generated, optimized and rendered. I don't think that DPS is all that different.
  - vidarh 12y ago
    It's not similar. Postscript (display or "regular") is imperative. It's an instruction stream. React belongs one level "up", abstracting away the translation from a declarative representation of the view to a stream of calls on some lower level mechanism to reproduce that representation in the most efficient way possible. The basic idea of React is that instead of having your application spitting out an instruction here and an instruction there, which may result in lots of reflows and redrawing, if individual state changes are expensive it can be more efficient to re-create a full representation of the desired state and have an engine compare that desired state to the actual state and figuring out the best possible set of steps to get from the actual to desired state. E.g. the engine may be able to figure out that a subtree changes so much it's going to be best to just replace it wholesale instead of manipulating node by node. The "output" from a React style engine can be a series of DOM manipulations, or it could be DPS instructions, or any number of other things - the idea is very general.

Touche 12y ago

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.

nkozyra 12y ago
Where was the web abandoned?
- Touche 12y ago
  React is no longer a web library, so today.
  - zwily 12y ago
    It's not? I must have missed that announcement.
  - sgrove 12y ago
    React has been carefully designed to encompass better UI patterns regardless of the underlying platform. There are some very thoughtful and capable people working on it. Worth reading Jordan's thoughts here https://news.ycombinator.com/item?id=8962171 https://news.ycombinator.com/item?id=8962171
  - nkozyra 12y ago
    Expansion != abandonment. In fact, were I a "competitor," I would be concerned about the philosophical buy-in that said expansion could induce.
  - cleverjake 12y ago
    I think you misunderstood. they are adding a non web library, not leaving the web.
jessep 12y ago
"Abandoning the web" seems a bit strong here. One difference between angular+dart and react+native is this: angular_devs ∩ dart_devs ~= 0 (relative to angular_devs) react_devs ∩ mobile_devs ~= react_devs Almost everyone who uses react also has to do mobile development, and would like a simpler way to do it. This solves a real and widespread need.

stanzheng 12y ago

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. [1] http://youtu.be/KVZ-P-ZI6W4?t=24m5s http://youtu.be/KVZ-P-ZI6W4?t=24m5s [2] https://itunes.apple.com/us/app/facebook-groups/id931735837?mt=8 https://itunes.apple.com/us/app/facebook-groups/id931735837?...

slashnull 12y ago

Sorry, dumb question, don't feel like watching the video: What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?

kenrose 12y ago
iOS and Android.
- deleted 12y ago
  [deleted]
evv 12y ago
This is Eric, from the React Native team. We're starting with iOS and Android, which will keep us busy for the foreseeable future. That said, we will open source soon, and we'd be happy to accept help targeting other platforms!
- omard 12y ago
  Nice! What about windows phones?
- slashnull 12y ago
  This is awesome. I can't wait for the API docs and sources to be released. Tweets and videos are lousy at conveying information : )
- jbigelow76 12y ago
  Very interesting. Microsoft allows you to build fully native (not webview wrappers) apps using WinJS, and they have shown that React (along with Angular) can be used to build those apps [1]. I wonder if Microsoft will put resources into bridging the gap between React Native and Windows 10. As a long time web oriented .NET developer wanting to pick up mobile who has been wondering whether to go Cordova or dive in fully native (ObjC/Java/Xaml) this is going to make the choice very difficult. [1] https://github.com/winjs/winjs/wiki/Using-WinJS-with-React https://github.com/winjs/winjs/wiki/Using-WinJS-with-React

owenwil 12y ago

This is amazing - wonder when we can get our hands on it.

rattray 12y ago

I had just started to think about switching to Mithril from React. This completely changed my mind. Incredibly exciting.

DAddYE 12y ago

I think this can be really amazing as is react js now. -- 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. I have been out from the web development since like 1.5 year, but yeah IMO react is the best thing happened to javascript since ... ever. Thanks again guys!

k__ 12y ago
> react is the best thing happened to javascript Why?
- DAddYE 12y ago
  Because when you deal with complex code react make it easier to read and as said in the talk more confident when making changes. On a large codebase we all know that you have to be a good JS dev to keep it well organized well readable etc...

digvan 12y ago

It fails like many other framework tried to create native apps with JavaScript

onewaystreet 12y ago
How can you possibly say this without seeing a single line of code?
sydcanem 12y ago
Those mobile Javascript frameworks uses the DOM. React native won't.
- je42 12y ago
  Actually, some don't use DOM. http://openaphid.github.io/blog/2013/01/17/part-i-how-to-choose-a-javascript-engine-for-ios-and-android-apps/ http://openaphid.github.io/blog/2013/01/17/part-i-how-to-cho...
- digvan 12y ago
  It's not about DOM. UIKit is pretty sofisticated to build layer to translate JS to native code. It needs years of work and constant update.
  - aaronbrethorst 12y ago
    ::cough:: https://twitter.com/andy_matuschak/status/560511204867575808 https://twitter.com/andy_matuschak/status/560511204867575808
    - digvan 12y ago
      He is just talking about layer model. Being iOS engineer for 4 years and Web developer for 5 years, These frameworks only works for certain use cases and at the end you wish that you did the right thing from beginning.

bobajeff 12y ago

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. I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.

leeoniya 12y ago
with gpu-accelerated css transitions, requestAnimationFrame, virtual dom and web workers, the experience can be damn close. he makes it seem like "no comparison", this is provably false at least for the apps he demoed. for games, native is still necessary. what react offers beyond performance though, is definitely awesome. imo, the talk comes off a bit like a sales pitch at a pep rally.
- nemothekid 12y ago
  I don't know - but given Facebook's past with WebView on their flagship app I feel they would be best qualified to say whether or not those solutions once fully implemented are satisfactory. It could be the case that the features you mentioned are suitable today for web applications targeting the latest iPhone on browsers on the latest standards, but not when React was first developed.
- tomocchino 12y ago
  You're absolutely right that it is possible to get close. I think my main point here, (though I probably didn't cover this well enough and I was being somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the default on web, and it's actually really, really hard to get there. Sorry for coming across as a sales person. Someone tweeted about a previous presentation of mine in the past asking "who the hell is this marketing guy they had do this talk". I assure you I'm not in either marketing, or sales, I just get really excited sometimes.
  - dhaivatpandya 12y ago

rattray 12y ago

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: https://medium.com/@floydophone/building-a-real-time-frosted-glass-effect-on-mobile-web-87ce4a41019f https://medium.com/@floydophone/building-a-real-time-frosted...

tomocchino 12y ago
You're not the only person to give me that feedback. :) Check out my other reply as well. I agree it's possible to make things that feel good, it's just very, very hard, and it's certainly not the default.
peterhunt 12y ago
If you look at the demo you'll see that while it's likely close to the best you can do with web tech, the physics don't feel correct because we can't reuse the native constants. Also the UI is very flat and simple. More complex UIs would be a struggle without react native.
aaronbrethorst 12y ago
The demo doesn't render on Safari on iOS 8. :-\

_pmf_ 12y ago

That's it. I'm finally going to port GridBagLayout to Javascript.

nogridbag 12y ago
The memories of GridBagLayout still haunt me to this day (see username). This is a classic gridbag cartoon: http://madbean.com/anim/totallygridbag http://madbean.com/anim/totallygridbag
- peterarmstrong 12y ago
  Heh, I remember coding a vertical FlowLayout in 1999 (before that was included) out of fear and loathing of GridBagLayout...
- _pmf_ 12y ago
  The horrible thing is that once I use it for a while, it starts making sense. That's usually the time I stop doing Java for a while.

themgt 12y ago

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. And did even Steve Yegge ever see this next big language coming?

donw 12y ago
Having spent the past six or so months working with React and Flux, I sure hope so. For the first time in my technical career, I've actually enjoyed working in Javascript. The real power of React isn't just the virtual DOM -- it's being able to leverage Flux and an immutable, single-source-of-truth app state. Pretty much every time I turn around to build something, this combination has made what used to be an exercise in hair-pulling into an absolute joy.
- TheCoelacanth 12y ago
  To some extent the virtual DOM is what enables that, because it allows that style of programming while still having good performance.
- guscost 12y ago
  > I sure hope so. It's looking more and more likely. And I agree, if React + Flux/etc becomes the de facto portable standard for the next generation of web and mobile development, we will be in pretty darn good shape. I've only done some tutorial apps and experimental stuff so far, but they're definitely on to something.

calebm 12y ago

Looks like React is reaching critical mass.

briandear 12y ago
Based on what metric? A Facebook team talking about a Facebook framework and a HN thread filled with React enthusiasts? I am not bashing any of it, but to suggest critical mass is a bit immature.
- hueving 12y ago
  Yeah, I have yet to meet a react developer in person. Maybe the definition of 'critical mass' is just enough fans to have commentors posting about it 24 hours a day. I would say rust has reached critical mass if react has.
- calebm 12y ago
  The community enthusiasm and features add up to the critical mass necessary to push me into giving it a good look... also, I wanted to say "critical mass" in connection with "React" ;)

potomushto 12y ago

Looks amazing. Is React Native supposed to be just a View lib for XCode project or it will be the platform like Titanium?

yuchi 12y ago
Their promise of being cross-platform probably will move them into a cross-env toolchain, a-la Titanium.

aceperry 12y ago

Sounds excellent. I need it today.

bronz 12y ago

What is this and why is it a big deal?

roccod 12y ago

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.

arasmussen 12y ago
Yep, you've got the gist of it. We render the app in JS, React creates this view hierarchy (still in JS), this is serialized and sent over the bridge (asynchronously) to the native engine who then creates the equivalent native view hierarchy and renders it. The source code for the iOS native engine (and the JS infra, and some examples) will be given to attendees of React.js Conf tomorrow (Jan 29). The iOS and Android versions of React Native will be open sourced soon! :)
- roccod 12y ago
  Is this native engine still html based (eg blink engine or webkit) or is it using the platforms drawing engines? We are currently building user interfaces for STB platforms using a a js platform mapped to a native canvas running on v8. If we could use the react protocol it would be great.
  - davedx 12y ago
    Hey, our team is using React to build STB interfaces. Would love to chat about your experiences, drop me an email? davedx@gmail.com :)
  - arasmussen 12y ago
    Nope, there's no DOM or HTML. It's creating native iOS/Android views.

xngzng 12y ago

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.

Toine 12y ago

What about native APIs like in-app purchases, push notifications, ads SDKs, GameCenter ? Will we be able to access those ?

CCs 12y ago
Jing said there's full binding and easy access to any native service

iLoch 12y ago

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. 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. 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. Really excited, thanks FBOS team.

masklinn 12y ago
> when I first saw the React syntax Do you mean JSX? Because "the React syntax" is just plain JS unless you're using JSX, is it not? IIRC even vdom nodes can be created by hand with literal objects.
- iLoch 12y ago
  Yeah, JSX. Whoops!
  - masklinn 12y ago
    Yeah it's completely optional, facebook built it because they had built something similar previously and they like it, and I guess it may be simpler for "pure" designers used to HTML and stuff, but it's AOT-compiled to the corresponding JS calls and the mapping is fairly simple: <Component1 attr1="value1" attr2={foo}> <Component2/> <Component3/> </Component1> becomes (more or less) Component1( {attr1: "value", attr2: foo}, Component2(), Component3() );
rattray 12y ago
You really don't need to use JSX; I can't stand the look of it but love using React (I use it with CoffeeScript, but don't mind it with raw JS either).

rajington 12y ago

Will the talk dealing with Relay and GraphQL also be uploaded?

jordwalke 12y ago

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.

tinganho 12y ago

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. 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.

joesb 12y ago
It's the same with all other native UI, though. .Net Winform, WPF, Swing, etc., they don't allow you to make modification to UI outside main thread.

briandear 12y ago

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.)

izietto 12y ago

Please, could anyone write a tl;dw (too long; didn't watch)?

CmonDev 12y ago
Yeah, is it really native or is it just marketing speech about same ol' crappy JS?
ryannevius 12y ago
Scroll down? CTRL + F the comments, and you'll see that someone did a "tl;dw" hours ago
- izietto 12y ago
  I scrolled but I didn't notice it, thank you
clay_to_n 12y ago
You can skip the first 20 minutes if you just want to learn about React Native.

cromwellian 12y ago

We just demoed something similar at the GWTCreate conference, an Angular-like library called Singular (http://daniel-kurka.de/talks/gwtcreate15/singular.pdf http://daniel-kurka.de/talks/gwtcreate15/singular.pdf) 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) 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)

eyko 12y ago
After reading through your presentation, I have to say Singular does not look at all similar. And it's Java, so different audiences I guess. Angular in Java is not a bad idea though.
- cromwellian 12y ago
  Similar in this sense: 1) it uses templating (in our case, HTML, Android XML, and XIB) 2) it is cross platform, runs everywhere, even server 3) it produces native apps It's different in this sense: 1) it doesn't do DOM diffing, it does two-way data-binding 2) it's statically compiled to native code, it doesn't try to run JS in native platforms, and doesn't require any async seems between between the native platform (it's all static linkage) There may be other differences. The audience is Java and people who want no-compromise native integration. We target 70% code sharing between platforms, but expect the UI to be rebuilt for each platform. The core engineers behind J2ObjC were those who built Swing at Sun. We're pretty sour on the idea that write-once run-anywhere UIs are possible. Best experience dictates custom design for each frontend IMHO, and shared UI widgets may get you into an 'uncanny valley' state where you're composing the native widgets in ways that are alien to platform specific style guidelines.
  - rahimnathwani 12y ago

yuchi 12y ago

-- Attention -- Cross posting from the other thread -- 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. ## Architecture Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains. Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind. 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()`. 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). 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. ## Layout 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: a) by default everything is absolute positioned, b) you can get a vertical flow layout by setting the 'layout' property on the parent view or c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal. 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] [1]: https://github.com/facebook/css-layout https://github.com/facebook/css-layout ## Support and limits Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues: 1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land; 2) they have to follow every release of the platform’s SDK; 3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t. Let’s see how Native React will solve this issue. 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. ## Conclusion Because I shamelessy want to karma-drift this topic, I’ll stop here. It’s interesting, but until they show us some (native) code... it’s just ideas. Follow me on twitter (@_pier) and github (@yuchi [2]) for Titanium related stuff. Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab) [2]: https://github.com/yuchi https://github.com/yuchi

daemonk 12y ago

I wonder how they are handling persistent storage and multi-threading if at all.

gadders 12y ago

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...

edygar 12y ago

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?

sheraz 12y ago

Wow. I've been struggling to teach myself objective-c, never getting beyond the simple tutorials. So I'm happy to try this out. 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. 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. Nice work React team

mattdeboard 12y ago
Dude you should try Swift. Much easier.
- sheraz 12y ago
  I would, but I have not upgraded my macbook to mavericks yet. :-/
squeaky-clean 12y ago
Same situation here, using Ionic, but this seems extremely cool. I'll definitely build something with ReactNative as soon as I can. We're only making a news app, but Ionic feels completely native once we optimized it correctly and use the latest beta features. As for Android being slow does that include 4.4 devices, or just older version of Android? If it's older devices, you should try the new Ionic beta with Crosswalk integration (you'll need to install/enable Crosswalk, but it's very easy to do). Sadly, it'll add about 25mb to your .apk, but on phones earlier than 4.4 the performance boost is at least 10x if not more.
- sheraz 12y ago
  On your suggestion I tried it on my phone (4.1.2). The rendering improved, but speed is still an issue. Scrolling with big images is jerky. However, I have not yet optimized images or CSS. I'll probably spend next week looking into optimizations for ionic.
  - 12y ago

ceeK 12y ago

Can someone elaborate on how React Native would fit into the app development workflow (iOS)? Having a brief look over the ReactJS webpage, it seems like it would replace view controllers and perhaps Storyboards? Or are we talking about writing the entire application in Javascript, declaratively?

rickyc091 12y ago
React follows an approach similar to ReactiveCocoa (https://github.com/ReactiveCocoa/ReactiveCocoa https://github.com/ReactiveCocoa/ReactiveCocoa). It helps modularize the code into components instead of having a spaghetti string mess that often happens in view controllers. Currently there is no details on React Native, however, I don't believe it would replace the Storyboard as views are still necessary for the React code to interact with the components. What you would be doing is coding in JS and behind the scenes your app would interact with the views and do the necessarily updates. I'm guessing it'll be a hybrid approach. While you'll most likely still need to know Obj-C or Swift, you can probably get away with a lot of boiler plate code with React.
peterhunt 12y ago
You basically instantiate a view controller with a string of js and it works. Can drop into existing app for one view.

kas0 12y ago

Already done with Smartface App Studio.

mwcampbell 12y ago

Sounds exciting. When is the source going to be released? Also, how much of the app logic can be implemented in cross-platform JS versus native code?

somethingreen 12y ago

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.

pluma 12y ago
React is pretty much environment agnostic. It supports server-side rendering because it works without a DOM. Based on how they are specifically talking about not sharing code but sharing knowledge (i.e. same API, different components), I'd assume the environment-specific stuff is implemented by the actual primitive components (View, etc, the equivalent of div, etc, in the browser). They make it very clear that you won't be taking your web app and just magically have it work natively. You'd just write your native app using React, too.

debacle 12y ago

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.

lllllll 12y ago
I second this

jesalg 12y ago

Recruters: Looking for ReactJS Native developer with 5+ years of experience!

mendelk 12y ago
According to the video, they were using ReactJS internally for four years internally before open-sourcing it, so it might be possible :)

themgt 12y ago

React Native, in retrospect ... the day the Berlin Wall fell?

Nilzor 12y ago

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. 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.

robertfw 12y ago
The briefest explanation is that imperative is a list of instructions describing how you want something done. A declarative approach describes what you want done. The typical example for this is SQL - you don't tell an SQL database how to run a query, you tell it what you want, and it figures it out. In Reacts case, you describe your application in terms of components that know how to render themselves given different sets of data, or states. When the application state changes, the entire application is re-rendered. The "magic" of React is that the use of a virtual dom to create an efficient diff from the current dom state to the new dom state allows this to be very performant, ensuring a minimum of actual dom changes are made. The resulting components are much, much easier to reason about. You can see, looking at the code, exactly how the component will behave given different data. In essence, what you see is what you get. This is a far better dev experience than working with components that can be mutated by events; you need to build a mental model of all the various states that the component could find itself in. I was driven to this approach using Backbone to tame a particularly complex interface, similar in complexity to the ads example shown in the video. But as mentioned, doing this naively (in this case, re-rendering a backbone template instead of mutating it), leads to all kinds of user interface glitches. React smooths over those glitches.
- Nilzor 12y ago
  Thanks, much clearer now. :)

kenshin03 12y ago

On iOS I'd imagine this uses the underlying Webkit JavascriptCore engine. How about Android? Do I need to embed a V8 in my app if I want to use React Native?

zkhalique 12y ago

https://www.youtube.com/watch?v=KVZ-P-ZI6W4 https://www.youtube.com/watch?v=KVZ-P-ZI6W4 Look at 10:00 ... that sounds very much like what we were going through and building at the exact same time http://platform.qbix.com http://platform.qbix.com ... self contained components, completely parallelizable etc. Also in PHP and JS :) And it all works!