10 ms·

Use ReactJS to Build Native Apps

466 points by andyl 12y ago

api 12y ago
http://www.reactiongifs.com/r/give_it_to_me.gif http://www.reactiongifs.com/r/give_it_to_me.gif
- RussianCow 12y ago
  Really? This isn't Reddit.
  - api 12y ago
    These are special circumstances.
  - swader 12y ago
    This is worse than reddit
  - RivieraKid 12y ago
    Sadly.
saosebastiao 12y ago
Is there more information somewhere? Or just a tweet?
- sehr 12y ago
  https://twitter.com/fbOpenSource/status/560506714382802945 https://twitter.com/fbOpenSource/status/560506714382802945 Looks like it's not being open sourced for a while, but apparently the attendees are going to have some hands on tomorrow. 2015 seems like it's shaping up to be the year of React!
  - pjmlp 12y ago
    > 2015 seems like it's shaping up to be the year of React! Something needs to replace AngularJS I guess, until the next big thing.
- deleted 12y ago
  [deleted]
thasmin 12y ago
I would love to see React added to mobile app frameworks like Apache Cordova.
- andyl 12y ago
  You can use ReactJS now with Cordova/PhoneGap - no problemo. This announcement is about replacing html elements (div, h1, img, etc.) with native elements. Should be faster going native than via web elements.
  - arenaninja 12y ago
    Oh snap. This is HUGE
  - pbreit 12y ago
    So does it use PhoneGap or something like it?
    - lucasmullens 12y ago
      No, because PhoneGap uses the DOM.
    - zpao 12y ago
      No, it skips the DOM entirely and works with native elements (iOS views) directly.
      - diverightin63 12y ago
        This is where I get confused. How is it compiling to these elements?
        eyko 12y ago
        That's the million dollar question and tomorrow we might get an answer.
        12y ago
colinramsay 12y ago
This is massive. Some more details: "React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1] "Fb groups app in iOS App Store is powered by it #reactjsconf" [2] "iOS and Android native using all the same ideas as React, all the power of native." [3] React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue? [1] https://twitter.com/AnnaPawlicka/status/560505089207463936 https://twitter.com/AnnaPawlicka/status/560505089207463936 [2] https://twitter.com/floydophone/status/560504204343521280 https://twitter.com/floydophone/status/560504204343521280 [3] https://twitter.com/voodootikigod/status/560503641920921600 https://twitter.com/voodootikigod/status/560503641920921600
- threepointone 12y ago
  ahem. my bet - https://github.com/facebook/css-layout https://github.com/facebook/css-layout cannot wait for more details.
  - colinramsay 12y ago
    "This project implements a subset of CSS including flexbox and the box model using pure JavaScript" So all the good bits of CSS without any of the bad - including browser compatibility problems? Doesn't explain stuff like fonts & colours though...
  - kirillklimuk 12y ago
    Seems like you won the pot. @vjeux will be giving a bigger talk about it tomorrow and he's the biggest contributor to the css project (https://github.com/facebook/css-layout/graphs/contributors https://github.com/facebook/css-layout/graphs/contributors).
    - bjr- 12y ago
      relevant talk by @vjeux: https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js
aakilfernandes 12y ago
What does this mean? Can't you use any javascript tech to build native apps with nwjs or cordova? Edit: looks like this isn't hybrid as I assumed but truly native
- diverightin63 12y ago
  I am pretty confused as to what this actually does. How can it be native?
  - aakilfernandes 12y ago
    My guess is we're missing an important piece of the puzzle. Unless they have a js to everything interpreter. In which case thats much bigger news than react.
    - taurath 12y ago
      Its more of a shiv to convert react elements/calls into native UI elements, using a native server to receive streams/messages (unsure which) and convert them.
  - amasad 12y ago
    Instead of having React render to the DOM it renders to Native views. Be it iOS, or Android.
    - candl 12y ago
      I doubt it would happen at runtime in iOS/Android, though? They would need to ship a JS interpreter that gets run on application startup, parse the React files, instantiate the native controls and create a bridge between them back to the JS interpreter? Well on second thought I guess Appcelerator Titanium does something similar. So it's native UI only, but with the added overhead (JS interpreter + bridge, larger binary size, slower startup, etc.).
      - 12y ago
michaelmcmillan 12y ago
Coupling your app to any framework has proved to be a really bad idea in the long run, to me this is a step in the wrong direction. If I've understood this announcement correctly.
polskibus 12y ago
I'm a big ReactJS fan, however isn't moving React to native a bit like old school windows message loop ?
- hardwaresofton 12y ago
  Yes, the whole system is just basically component rendering (react) + a message bus oriented architecture (flux). The architecture is not novel, but I think the big change between React Native (or whatever they're going to call it) and any actual native application is the same difference between approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform independence. The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
- jasonwatkinspdx 12y ago
  Yeah, my react code has WM_PAINT all over the place.
mcao 12y ago
This is awesome news. I've been working on a desktop application using React, node-webkit and browserify and it's been a great development experience. Being able to leverage web technologies to build native apps has been a huge time saver. However, I'm relying on the NodeJS components in order to do things like access the file system and fork commands. I'm wondering how React Native will handle this functionality. Will it be an extended API or can you only do AJAX calls? Either way it's very exciting.
- hardwaresofton 12y ago
  Currently working on something similar (minus browserify) -- I don't think React should try to get into the doing-everything game. That said, their success (over something like node-webkit + react) will definitely depend on how well they match and integrate the native APIs.
  - lsdafjklsd 12y ago
    Doing everything is a side effect of the architecture. "The virtual dom is an implementation detail of React.js. React Native demonstrates that many rendering contexts are possible." This was kind of the exciting point all along :). DOM just happens to be the output of a function that people are most interested in at the moment. but people have been talking about using it with canvas and other stuff, too. It's a generally-useful way to map functional data to render-trees.
    - hardwaresofton 12y ago
      Yep, I overlooked that fact, yeah that's awesome. I can imagine a world where people just come up with lots of mappings for the result, modularly. That's awesome
- amasad 12y ago
  Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in terms of whatever native capability exposed. You can totally use npm modules, provided any module that it uses is polyfilled.
xasos 12y ago
Nilas[1] is using React with Atom Shell to build a native desktop mail client for all three major platforms on top of their API. Awesome stuff! [1] https://www.nilas.com/ https://www.nilas.com/
TheAceOfHearts 12y ago
Extremely excited about this! I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2 https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO. This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!
- tlinton 12y ago
  What was the issues you had with Tint (just curious).
jordwalke 12y ago
Hi, I'm Jordan from the React team. I'm happy to answer any questions about React Native, but @vjeux will be giving a more thorough talk tomorrow that you won't want to miss (if you're at ReactJSConf), so I might wait for him to answer some of them. This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.
- Feeble 12y ago
  Hi Jordan, when you say native apps what platform(s) will it be possible to target? E.g. windows, osx, ios, android etc?
  - arasmussen 12y ago
    We're currently working on just iOS and Android.
- mcjiggerlog 12y ago
  Can you let us know a bit more about what this is? Native to what? Android / iOS? Desktops? Does it allow you to render native components with JSX as opposed to only DOM elements? Can you mix the two, somehow?
  - zpao 12y ago
    iOS and android right now. And yes, native components can be rendered directly with JSX. And you won't need to mix with DOM. <h2> For example doesn't mean anything on iOS.
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
  - jordwalke 12y ago
    React has, from day one, sought to liberate itself from the underlying low level building blocks of a particular environment. There were always good reasons to so (normalizing browser inconsistencies etc). There is another benefit of the specific way in which we've built this library level layer of abstraction - we've formed a serializable boundary that allows vanilla React to sit on one side, and any set of lower level building blocks on the other. Before today, we simply had the DOM renderers sitting on the other side of that boundary. React Native replaces the DOM renderers with native renderers which allows people to render platform <View>/<ScrollView>/<NativeWhatever> instead of <div>/<span>. Other than that, you get to use the exact same React API that you already know (even down to the event bubbling). You can bridge to things that are only available on the platform, and can in general make higher performance granular building blocks that cannot be accomplished with web technology (such as <Image> components that decode images more efficiently or with different concurrency models). As with everything, JSX is not required to take advantage of this - and you can use any of the compile-to-js languages that you use with React today.
tilt 12y ago
Very promising! As a (past) Titanium developer, FB Groups being in the wild for a while comes as a relieve to my hears. I'd bet Angular going Native first, though, I guessed it was coming with 2.0
spicyj 12y ago
"I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal." https://twitter.com/andy_matuschak/status/560511204867575808 https://twitter.com/andy_matuschak/status/560511204867575808
deleted 12y ago
[deleted]
joeblau 12y ago
I can't wait to see more details about this. I hope this isn't another botched attempt at trying to solve the cross compiled native app challenge. I've seen and signed up for so many hype machines for solving this problem including plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've invested time in learning about all of these platforms, but in the end they all fell short in some way or another. I have high hopes for $FB though because I've really enjoyed most of the projects they've open sourced including React and Pop. Personally, it's been easier for me to just learn and use Swift/Obj-C. The main caveat is that my apps are limited to running on iOS.
ryanSrich 12y ago
As someone who is just getting into iOS dev is there any benefit (that's at least known at this point) to using React over Swift for UI?
- loumf 12y ago
  Possible portability to Android -- might take some work, but much less than it would be to port Swift. From an architecture point-of-view, there is ReactCocoa.
- rickyc091 12y ago
  It really depends on what you are using iOS for. If you already know ReactJS, then it'll probably be a lot easier for you to learn React Native than Swift or Objective-C. If you are working on a team with primarily JS developers, React Native is probably a better choice to go with. Will this cause Swift to be irrelevant? Probably not. -- If you are learning iOS and doing production / client work, you should be aware that using a third party framework could actually break your app. I'm interested in React Naive, but also very weary about it. Facebook released a framework called Three20 back in iOS 2.0/3.0 days and abandoned the project shortly afterwards. Of course being open source there is bound to be people who take over the project, but it's something to think about.
arms 12y ago
This is very exciting. I've been using React for a bit now and have found it a pleasure to work with. I can't wait for more details on React Native.
debacle 12y ago
Facebook, destroying the edifices of the Internet, one technology at a time. Very excited for this. I have been looking at React for a while, now it's certainly time to take a plunge.
e0m 12y ago
"Learn Once Write Everywhere" I this this is a great mentality over the classic write once run everywhere approach. We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.
- scribu 12y ago
  > "Learn Once Write Everywhere" I can't help but think about that other chestnut, "A determined programmer can write Fortran in any language." Of course it makes sense to apply a pattern that you know worked great in the past. The tough part is deciding when it's worth trying something else.
danr4 12y ago
oh boy now i can call myself an app developer too
akfanta 12y ago
Sorry for an ignorant question, but what would be the relationship between ReactJS and React Native?
- jrm2k6 12y ago
  React-native uses React code to build native applications.
sudhirj 12y ago
Summary of what I can make out so far: * Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements. * The code you write runs in a Javascript interpreter on the background thread. * The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent. * The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.
- binocarlos 12y ago
  Nice summary thanks :-)
- devgeeks 12y ago
  Has anyone asked if this can use other JS libs other than just React ones? Also, if it's just using say JavaScriptCore and rendering native, I assume this means speed limitations imposed by the lack of Nitro/etc on the UIWebView are moot?
  - danabramov 12y ago
    JSC doesn't have JIT. They claim perf is fine though (e.g. because render is always async, app code is always in background). We shall see!
elwell 12y ago
Cue Om Native...
- arms 12y ago
  God, I would love to see this (or Reagent Native).
- bjr- 12y ago
  and Sablono Native
amelius 12y ago
Hi, I'm just reading through the ReactJS docs for the first time, and I found something peculiar. Let me explain. So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified. I can understand this, but... The DOM is already incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method? Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating only the display. So, as you can see, I'm a bit confused...
- drcode 12y ago
  DOM is stateful, whereas the render() method is stateless. For instance, if you add a <button> to the DOM, it will stay there forever. On the other hand if the next call to render() no longer includes the <button> then React will do the work of removing it from the DOM.
  - amelius 12y ago
    But then render() has to re-generate all the stuff over and over again, which could be slow.
    - drcode 12y ago
      Right, this is where you need to look at benchmarks http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc...
    - TheCoelacanth 12y ago
      There are two things that stop it from being slow in practice: 1. The virtual DOM that render deals with is several orders of magnitude faster than the real DOM, so you need to have thousands of elements before it starts taking longer than making the one change to the real DOM for the one element that changed 2. You can skip calling render on subcomponents that haven't changed, so while updating a list of 10000 elements where one has changed would require iterating through 10000 elements, updating a list of 100 elements that each contains 100 elements where one of the bottom level elements has changed would only require iterating through 200 elements.
crudbug 12y ago
I see React effectively as the controller of UI state changes. This can be applied on any datapath, i.e. model to view rendering - web / native / games.
yuchi 12y ago
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) for Titanium related stuff. Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)
sz4kerto 12y ago
Will it work with Reagent?
csulmone 12y ago
Does this include desktop apps?
_pb 12y ago
This is really exciting! Can't wait to use it.
serve_yay 12y ago
It occurs to me that, for years, web platforms sought to keep developers from ever having to touch dirty old JS. I can remember all sorts of overcomplicated ASP.NET widgets that were like that. Now we want JS and don't want to deal with gross native APIs. Perhaps it's not the same "we", though I personally am very excited about this. I love JS and I think React's ideas are the right ones for building UIs.
vertAlign 12y ago
Everyone felt that in terms of Javascript rendering on mobile you guys had the best shot. Did you feel that JS had hit it's limits with rendering and wasn't strong enough for mobile sites/apps? Looking forward to hearing more about React Native!
aceperry 12y ago
This is huge. There are so many approaches to cross platform mobile development, yet none of them really make it easy to integrate a full stack web platform. This is one step closer.
kin 12y ago
This sounds promising. I've been building something with Ionic recently and it's great 'cause it's just Angular but the documentation is a bit inconsistent and outdated. If React Native were to execute and deliver, I'd definitely love to switch over.
sekasi 12y ago
I have long questioned the validity of middleware (for the lack of better terms, please don't be pedantic) to create native applications. I get it, HTML can replicate performance of native apps to a certain extent now, but it's also bound by restrictions that native apps aren't. Speed of innovation being one. HTML5 is a large ship that takes a long time to evolve (in comparison). iOS and Android aren't, by the same means. Particularly iOS since Apple has a habit of introducing backwards compatibility breaking new features. I don't understand fully how hybrid made apps will ever be able to properly compete with a native platform for this reason alone, not mentioning some of the other problems that plague hybrid and middle ware apps.
- RussianCow 12y ago
  React Native is not built on the DOM and thus is not "hybrid"--it seems it's fully native under the hood.
- alwaysdoit 12y ago
  What's the difference between this and websites competing with native Windows/Mac OS/Linux apps? Sure the performance isn't quite as good, but not being locked to a platform is a huge benefit.
jamesgpearce 12y ago
Video of this keynote is now up: https://youtube.com/watch?v=KVZ-P-ZI6W4 https://youtube.com/watch?v=KVZ-P-ZI6W4
throwaway11223 12y ago
Why is this post almost off the front page inspite of a healthy number of upvotes in a short period of time?
deleted 12y ago
[deleted]
ZZB 12y ago
Doesn't it violate the apple policy about updating the app without reviewing?
chrisdevereux 12y ago
Cool. I've always thought that the native view layer is better viewed analagously to how web developers tend to view the DOM: a low(ish)-level API upon which to build abstractions that better fit the domain. Hopefully, we will come to view manual NSView slugging in the same way that we'd now view building a single page webapp entirely with jQuery.
deleted 12y ago
[deleted]
psulatycke 12y ago
How does React Native handle OpenGl ES calls? Does it convert Webgl calls to native OpenGL or provide an interface to directly make native OpenGl calls from javascript?
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?
aoakenfo 12y ago
So...a JS interface to a server that creates native views. I don't get it, what is all the hype about? You've got an extra layer and level of abstraction (read: complexity) in your pipeline. I don't see how you can abstract away the idioms of a platform - they're native. 'Write once, run everywhere' has failed time and time again. So marketing changed its tune to 'Learn once, run everywhere' and now people are gushing how HUGE this is?
shripadk 12y ago
React is the Future. Period!
b5i 12y ago
I didn't attend the conf. Is there a way to get access to the repo?

466 points by andyl 12y ago

api 12y ago

http://www.reactiongifs.com/r/give_it_to_me.gif http://www.reactiongifs.com/r/give_it_to_me.gif

RussianCow 12y ago
Really? This isn't Reddit.
- api 12y ago
  These are special circumstances.
- swader 12y ago
  This is worse than reddit
- RivieraKid 12y ago
  Sadly.

saosebastiao 12y ago

Is there more information somewhere? Or just a tweet?

sehr 12y ago
https://twitter.com/fbOpenSource/status/560506714382802945 https://twitter.com/fbOpenSource/status/560506714382802945 Looks like it's not being open sourced for a while, but apparently the attendees are going to have some hands on tomorrow. 2015 seems like it's shaping up to be the year of React!
- pjmlp 12y ago
  > 2015 seems like it's shaping up to be the year of React! Something needs to replace AngularJS I guess, until the next big thing.
deleted 12y ago
[deleted]

thasmin 12y ago

I would love to see React added to mobile app frameworks like Apache Cordova.

andyl 12y ago
You can use ReactJS now with Cordova/PhoneGap - no problemo. This announcement is about replacing html elements (div, h1, img, etc.) with native elements. Should be faster going native than via web elements.
- arenaninja 12y ago
  Oh snap. This is HUGE
- pbreit 12y ago
  So does it use PhoneGap or something like it?
  - lucasmullens 12y ago
    No, because PhoneGap uses the DOM.
  - zpao 12y ago
    No, it skips the DOM entirely and works with native elements (iOS views) directly.
    - diverightin63 12y ago
      This is where I get confused. How is it compiling to these elements?
      - eyko 12y ago
        That's the million dollar question and tomorrow we might get an answer.
      - 12y ago

colinramsay 12y ago

This is massive. Some more details: "React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1] "Fb groups app in iOS App Store is powered by it #reactjsconf" [2] "iOS and Android native using all the same ideas as React, all the power of native." [3] React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue? [1] https://twitter.com/AnnaPawlicka/status/560505089207463936 https://twitter.com/AnnaPawlicka/status/560505089207463936 [2] https://twitter.com/floydophone/status/560504204343521280 https://twitter.com/floydophone/status/560504204343521280 [3] https://twitter.com/voodootikigod/status/560503641920921600 https://twitter.com/voodootikigod/status/560503641920921600

threepointone 12y ago
ahem. my bet - https://github.com/facebook/css-layout https://github.com/facebook/css-layout cannot wait for more details.
- colinramsay 12y ago
  "This project implements a subset of CSS including flexbox and the box model using pure JavaScript" So all the good bits of CSS without any of the bad - including browser compatibility problems? Doesn't explain stuff like fonts & colours though...
- kirillklimuk 12y ago
  Seems like you won the pot. @vjeux will be giving a bigger talk about it tomorrow and he's the biggest contributor to the css project (https://github.com/facebook/css-layout/graphs/contributors https://github.com/facebook/css-layout/graphs/contributors).
  - bjr- 12y ago
    relevant talk by @vjeux: https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js

aakilfernandes 12y ago

What does this mean? Can't you use any javascript tech to build native apps with nwjs or cordova? Edit: looks like this isn't hybrid as I assumed but truly native

diverightin63 12y ago
I am pretty confused as to what this actually does. How can it be native?
- aakilfernandes 12y ago
  My guess is we're missing an important piece of the puzzle. Unless they have a js to everything interpreter. In which case thats much bigger news than react.
  - taurath 12y ago
    Its more of a shiv to convert react elements/calls into native UI elements, using a native server to receive streams/messages (unsure which) and convert them.
- amasad 12y ago
  Instead of having React render to the DOM it renders to Native views. Be it iOS, or Android.
  - candl 12y ago
    I doubt it would happen at runtime in iOS/Android, though? They would need to ship a JS interpreter that gets run on application startup, parse the React files, instantiate the native controls and create a bridge between them back to the JS interpreter? Well on second thought I guess Appcelerator Titanium does something similar. So it's native UI only, but with the added overhead (JS interpreter + bridge, larger binary size, slower startup, etc.).
    - 12y ago

michaelmcmillan 12y ago

Coupling your app to any framework has proved to be a really bad idea in the long run, to me this is a step in the wrong direction. If I've understood this announcement correctly.

polskibus 12y ago

I'm a big ReactJS fan, however isn't moving React to native a bit like old school windows message loop ?

hardwaresofton 12y ago
Yes, the whole system is just basically component rendering (react) + a message bus oriented architecture (flux). The architecture is not novel, but I think the big change between React Native (or whatever they're going to call it) and any actual native application is the same difference between approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform independence. The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
jasonwatkinspdx 12y ago
Yeah, my react code has WM_PAINT all over the place.

mcao 12y ago

This is awesome news. I've been working on a desktop application using React, node-webkit and browserify and it's been a great development experience. Being able to leverage web technologies to build native apps has been a huge time saver. However, I'm relying on the NodeJS components in order to do things like access the file system and fork commands. I'm wondering how React Native will handle this functionality. Will it be an extended API or can you only do AJAX calls? Either way it's very exciting.

hardwaresofton 12y ago
Currently working on something similar (minus browserify) -- I don't think React should try to get into the doing-everything game. That said, their success (over something like node-webkit + react) will definitely depend on how well they match and integrate the native APIs.
- lsdafjklsd 12y ago
  Doing everything is a side effect of the architecture. "The virtual dom is an implementation detail of React.js. React Native demonstrates that many rendering contexts are possible." This was kind of the exciting point all along :). DOM just happens to be the output of a function that people are most interested in at the moment. but people have been talking about using it with canvas and other stuff, too. It's a generally-useful way to map functional data to render-trees.
  - hardwaresofton 12y ago
    Yep, I overlooked that fact, yeah that's awesome. I can imagine a world where people just come up with lots of mappings for the result, modularly. That's awesome
amasad 12y ago
Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in terms of whatever native capability exposed. You can totally use npm modules, provided any module that it uses is polyfilled.

xasos 12y ago

Nilas[1] is using React with Atom Shell to build a native desktop mail client for all three major platforms on top of their API. Awesome stuff! [1] https://www.nilas.com/ https://www.nilas.com/

TheAceOfHearts 12y ago

Extremely excited about this! I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2 https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO. This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!

tlinton 12y ago
What was the issues you had with Tint (just curious).

jordwalke 12y ago

Hi, I'm Jordan from the React team. I'm happy to answer any questions about React Native, but @vjeux will be giving a more thorough talk tomorrow that you won't want to miss (if you're at ReactJSConf), so I might wait for him to answer some of them. This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.

Feeble 12y ago
Hi Jordan, when you say native apps what platform(s) will it be possible to target? E.g. windows, osx, ios, android etc?
- arasmussen 12y ago
  We're currently working on just iOS and Android.
mcjiggerlog 12y ago
Can you let us know a bit more about what this is? Native to what? Android / iOS? Desktops? Does it allow you to render native components with JSX as opposed to only DOM elements? Can you mix the two, somehow?
- zpao 12y ago
  iOS and android right now. And yes, native components can be rendered directly with JSX. And you won't need to mix with DOM. <h2> For example doesn't mean anything on iOS.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
- jordwalke 12y ago
  React has, from day one, sought to liberate itself from the underlying low level building blocks of a particular environment. There were always good reasons to so (normalizing browser inconsistencies etc). There is another benefit of the specific way in which we've built this library level layer of abstraction - we've formed a serializable boundary that allows vanilla React to sit on one side, and any set of lower level building blocks on the other. Before today, we simply had the DOM renderers sitting on the other side of that boundary. React Native replaces the DOM renderers with native renderers which allows people to render platform <View>/<ScrollView>/<NativeWhatever> instead of <div>/<span>. Other than that, you get to use the exact same React API that you already know (even down to the event bubbling). You can bridge to things that are only available on the platform, and can in general make higher performance granular building blocks that cannot be accomplished with web technology (such as <Image> components that decode images more efficiently or with different concurrency models). As with everything, JSX is not required to take advantage of this - and you can use any of the compile-to-js languages that you use with React today.

tilt 12y ago

Very promising! As a (past) Titanium developer, FB Groups being in the wild for a while comes as a relieve to my hears. I'd bet Angular going Native first, though, I guessed it was coming with 2.0

spicyj 12y ago

"I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal." https://twitter.com/andy_matuschak/status/560511204867575808 https://twitter.com/andy_matuschak/status/560511204867575808

deleted 12y ago

[deleted]

joeblau 12y ago

I can't wait to see more details about this. I hope this isn't another botched attempt at trying to solve the cross compiled native app challenge. I've seen and signed up for so many hype machines for solving this problem including plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've invested time in learning about all of these platforms, but in the end they all fell short in some way or another. I have high hopes for $FB though because I've really enjoyed most of the projects they've open sourced including React and Pop. Personally, it's been easier for me to just learn and use Swift/Obj-C. The main caveat is that my apps are limited to running on iOS.

ryanSrich 12y ago

As someone who is just getting into iOS dev is there any benefit (that's at least known at this point) to using React over Swift for UI?

loumf 12y ago
Possible portability to Android -- might take some work, but much less than it would be to port Swift. From an architecture point-of-view, there is ReactCocoa.
rickyc091 12y ago
It really depends on what you are using iOS for. If you already know ReactJS, then it'll probably be a lot easier for you to learn React Native than Swift or Objective-C. If you are working on a team with primarily JS developers, React Native is probably a better choice to go with. Will this cause Swift to be irrelevant? Probably not. -- If you are learning iOS and doing production / client work, you should be aware that using a third party framework could actually break your app. I'm interested in React Naive, but also very weary about it. Facebook released a framework called Three20 back in iOS 2.0/3.0 days and abandoned the project shortly afterwards. Of course being open source there is bound to be people who take over the project, but it's something to think about.

arms 12y ago

This is very exciting. I've been using React for a bit now and have found it a pleasure to work with. I can't wait for more details on React Native.

debacle 12y ago

Facebook, destroying the edifices of the Internet, one technology at a time. Very excited for this. I have been looking at React for a while, now it's certainly time to take a plunge.

e0m 12y ago

"Learn Once Write Everywhere" I this this is a great mentality over the classic write once run everywhere approach. We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.

scribu 12y ago
> "Learn Once Write Everywhere" I can't help but think about that other chestnut, "A determined programmer can write Fortran in any language." Of course it makes sense to apply a pattern that you know worked great in the past. The tough part is deciding when it's worth trying something else.

danr4 12y ago

oh boy now i can call myself an app developer too

akfanta 12y ago

Sorry for an ignorant question, but what would be the relationship between ReactJS and React Native?

jrm2k6 12y ago
React-native uses React code to build native applications.

sudhirj 12y ago

Summary of what I can make out so far: * Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements. * The code you write runs in a Javascript interpreter on the background thread. * The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent. * The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.

binocarlos 12y ago
Nice summary thanks :-)
devgeeks 12y ago
Has anyone asked if this can use other JS libs other than just React ones? Also, if it's just using say JavaScriptCore and rendering native, I assume this means speed limitations imposed by the lack of Nitro/etc on the UIWebView are moot?
- danabramov 12y ago
  JSC doesn't have JIT. They claim perf is fine though (e.g. because render is always async, app code is always in background). We shall see!

elwell 12y ago

Cue Om Native...

arms 12y ago
God, I would love to see this (or Reagent Native).
bjr- 12y ago
and Sablono Native

amelius 12y ago

Hi, I'm just reading through the ReactJS docs for the first time, and I found something peculiar. Let me explain. So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified. I can understand this, but... The DOM is already incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method? Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating only the display. So, as you can see, I'm a bit confused...

drcode 12y ago
DOM is stateful, whereas the render() method is stateless. For instance, if you add a <button> to the DOM, it will stay there forever. On the other hand if the next call to render() no longer includes the <button> then React will do the work of removing it from the DOM.
- amelius 12y ago
  But then render() has to re-generate all the stuff over and over again, which could be slow.
  - drcode 12y ago
    Right, this is where you need to look at benchmarks http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc...
  - TheCoelacanth 12y ago
    There are two things that stop it from being slow in practice: 1. The virtual DOM that render deals with is several orders of magnitude faster than the real DOM, so you need to have thousands of elements before it starts taking longer than making the one change to the real DOM for the one element that changed 2. You can skip calling render on subcomponents that haven't changed, so while updating a list of 10000 elements where one has changed would require iterating through 10000 elements, updating a list of 100 elements that each contains 100 elements where one of the bottom level elements has changed would only require iterating through 200 elements.

crudbug 12y ago

I see React effectively as the controller of UI state changes. This can be applied on any datapath, i.e. model to view rendering - web / native / games.

yuchi 12y ago

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) for Titanium related stuff. Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)

sz4kerto 12y ago

Will it work with Reagent?

csulmone 12y ago

Does this include desktop apps?

_pb 12y ago

This is really exciting! Can't wait to use it.

serve_yay 12y ago

It occurs to me that, for years, web platforms sought to keep developers from ever having to touch dirty old JS. I can remember all sorts of overcomplicated ASP.NET widgets that were like that. Now we want JS and don't want to deal with gross native APIs. Perhaps it's not the same "we", though I personally am very excited about this. I love JS and I think React's ideas are the right ones for building UIs.

vertAlign 12y ago

Everyone felt that in terms of Javascript rendering on mobile you guys had the best shot. Did you feel that JS had hit it's limits with rendering and wasn't strong enough for mobile sites/apps? Looking forward to hearing more about React Native!

aceperry 12y ago

This is huge. There are so many approaches to cross platform mobile development, yet none of them really make it easy to integrate a full stack web platform. This is one step closer.

kin 12y ago

This sounds promising. I've been building something with Ionic recently and it's great 'cause it's just Angular but the documentation is a bit inconsistent and outdated. If React Native were to execute and deliver, I'd definitely love to switch over.

sekasi 12y ago

I have long questioned the validity of middleware (for the lack of better terms, please don't be pedantic) to create native applications. I get it, HTML can replicate performance of native apps to a certain extent now, but it's also bound by restrictions that native apps aren't. Speed of innovation being one. HTML5 is a large ship that takes a long time to evolve (in comparison). iOS and Android aren't, by the same means. Particularly iOS since Apple has a habit of introducing backwards compatibility breaking new features. I don't understand fully how hybrid made apps will ever be able to properly compete with a native platform for this reason alone, not mentioning some of the other problems that plague hybrid and middle ware apps.

RussianCow 12y ago
React Native is not built on the DOM and thus is not "hybrid"--it seems it's fully native under the hood.
alwaysdoit 12y ago
What's the difference between this and websites competing with native Windows/Mac OS/Linux apps? Sure the performance isn't quite as good, but not being locked to a platform is a huge benefit.

jamesgpearce 12y ago

Video of this keynote is now up: https://youtube.com/watch?v=KVZ-P-ZI6W4 https://youtube.com/watch?v=KVZ-P-ZI6W4

throwaway11223 12y ago

Why is this post almost off the front page inspite of a healthy number of upvotes in a short period of time?

deleted 12y ago

[deleted]

ZZB 12y ago

Doesn't it violate the apple policy about updating the app without reviewing?

chrisdevereux 12y ago

Cool. I've always thought that the native view layer is better viewed analagously to how web developers tend to view the DOM: a low(ish)-level API upon which to build abstractions that better fit the domain. Hopefully, we will come to view manual NSView slugging in the same way that we'd now view building a single page webapp entirely with jQuery.

deleted 12y ago

[deleted]

psulatycke 12y ago

How does React Native handle OpenGl ES calls? Does it convert Webgl calls to native OpenGL or provide an interface to directly make native OpenGl calls from javascript?

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?

aoakenfo 12y ago

So...a JS interface to a server that creates native views. I don't get it, what is all the hype about? You've got an extra layer and level of abstraction (read: complexity) in your pipeline. I don't see how you can abstract away the idioms of a platform - they're native. 'Write once, run everywhere' has failed time and time again. So marketing changed its tune to 'Learn once, run everywhere' and now people are gushing how HUGE this is?

shripadk 12y ago

React is the Future. Period!

b5i 12y ago

I didn't attend the conf. Is there a way to get access to the repo?