Use ReactJS to Build Native Apps

https://twitter.com/floydophone/status/560503411389390848

by andyl • 11 years ago

466 162 11 years ago

twitter.com

saosebastiao• 11 years ago

Is there more information somewhere? Or just a tweet?

sehr• 11 years ago

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• 11 years 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.

thasmin• 11 years ago

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

andyl• 11 years 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• 11 years ago

Oh snap. This is HUGE

pbreit• 11 years ago

So does it use PhoneGap or something like it?

jbhatab• 11 years ago

check out http://touchstonejs.io/

colinramsay2• 11 years 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

[2] https://twitter.com/floydophone/status/560504204343521280

[3] https://twitter.com/voodootikigod/status/560503641920921600

threepointone• 11 years ago

ahem. my bet - https://github.com/facebook/css-layout

cannot wait for more details.

colinramsay2• 11 years 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• 11 years 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).

bendyBus2• 11 years ago

"learn once, write everywhere" - I like the sound of that! But I guess in the spirit of React this is still only the "V" in MVC right? I don't suppose they are planning to broaden the scope to anything other than rendering views. So if you want to use this to build native apps, I guess you are going to have to integrate another cross-platform solution for storage/sensor APIs?

waltfy• 11 years ago

React is much more than just the V in MVC. It sells itself in that way for presenting the ability of being just exactly that. Thus, it can quite easily coexist with other frameworks. I actually think the established and well known selling points of React, like the Virtual DOM and "V in MVC" are just very nice side effects. The most important thing is the concepts and principles adopted from FRP, which in my opinion makes React a very powerful tool for JavaScript in general, a local optima of what can be done with JS right now.

aakilfernandes2• 11 years 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

diverightin632• 11 years ago

I am pretty confused as to what this actually does. How can it be native?

aakilfernandes2• 11 years 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.

amasad2• 11 years ago

Instead of having React render to the DOM it renders to Native views. Be it iOS, or Android.

michaelmcmillan• 11 years 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• 11 years ago

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

hardwaresofton3• 11 years 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• 11 years ago

Yeah, my react code has WM_PAINT all over the place.

mcao• 11 years 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.

hardwaresofton3• 11 years 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• 11 years 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.

amasad2• 11 years 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.

bendyBus2• 11 years ago

Would you be willing to elaborate re my reply to colinramsay?

malandrew2• 11 years ago

My bet is that they are working with thrift for their transport layer. We're moving the same direction. I should be landing a bunch of diffs over the next week to the JS thrift libraries to support XHR and websockets in the nodejs thrift library (for use with browserify).

xasos• 11 years 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/

TheAceOfHearts• 11 years 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), 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• 11 years ago

What was the issues you had with Tint (just curious).

jordwalke4• 11 years 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• 11 years ago

Hi Jordan, when you say native apps what platform(s) will it be possible to target? E.g. windows, osx, ios, android etc?

arasmussen5• 11 years ago

We're currently working on just iOS and Android.

mcjiggerlog• 11 years 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?

zpao3• 11 years 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.

jordwalke4• 11 years 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.

danabramov5• 11 years ago

Does it run using JavaScriptCore? Can we implement something like Hot Module Replacement a la react-hot-loader[1] for it?

I dreaded my Xamarin build times..

[1] http://gaearon.github.io/react-hot-loader/

spicyj4• 11 years ago

Yes, that should be possible – it loads JS packages from a custom server right now but there's no reason it can't use Webpack. You'll be able to reload immediately (without recompiling) already by pressing Cmd-R in the simulator.

peterhunt3• 11 years ago

There will be more detail tomorrow, but at a high level:

* JS engine on a background thread

* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)

* Plug-in for React that speaks that protocol

* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)

* Designed to take advantage of native platform views, NOT be the next Java Swing

josebalius• 11 years ago

Cannot wait!

phoenixbox• 11 years ago

Bananas

bceagle• 11 years ago

So it won't actually use web views? Interesting.

drcode6• 11 years ago

Please, please have constraint-based layout support- I know you want to have it, given your work on react-gss :-)

abalone• 11 years ago

How does it compare to Appcelerator Titanium? That's also a JavaScript-to-native-UI layer utilizing a JS runtime. http://www.appcelerator.com/titanium/

I know one complaint among many was that wrapping native API in a new framework can limit access to functionality and customization; you're limited to the choices of the framework designer. Another is debugging is harder since native tools don't understand the framework and you're dependent on the tool chain provided by the framework makers.

OlavHN• 11 years ago

You guys better be filming the talks! :)

mmgutz• 11 years ago

ha "NOT be the next Java Swing"

TBH, I don't use React right now but this is a game changer.

AnSavvides• 11 years ago

When would this be open to the world? :)

thramp• 11 years ago

How does it compare to AsyncDisplayKit?

dkasper• 11 years ago

According to FB it is conceptually a continuation of AsyncDisplayKit https://twitter.com/fbOpenSource/status/560512580326674432

mrdrozdov2• 11 years ago

Is there sample code? Will this be open sourced?

zpao3• 11 years ago

No sample code yet and yes it will be open sourced.

kcorbitt• 11 years ago

I know it's a bit of an orthogonal concern, but will this project provide a way to style native apps using web technologies (e.g. CSS) as well? I'm very excited about building native apps with React, and would be even more so if I could also leave behind the very-poorly-designed Android style primitives.

peterhunt3• 11 years ago

Yes, a subset of CSS was ported

dengar007• 11 years ago

I'm not at the conference and haven't had a chance to read too much into this yet (so if the answer is just wait you'll see that's good :D)

Can I use the same kind of jsx I am on the web today or is there going to be something different? Will sharing components between web and native mobile apps be possible?

hitlin37• 11 years ago

are you targeting arm platform support as well? I'm interested to know if any plans to have it on embedded devices.

rajington• 11 years ago

I understand Facebook Groups for iOS uses it, but how mature is the current component library (compared to Ionic for example)?

If it's still small do you plan on the majority of future components to be first-party or third-party (community)?

Extremely exciting either way, wish there was a livestream of tomorrow.

arasmussen5• 11 years ago

There won't be a livestream but presentation videos will be uploaded shortly afterwards!

zkhalique• 11 years ago

Wow. It looks like we're going to have to make our platform (http://platform.qbix.com) integrate with React out of the box. This sounds pretty awesome.

In short, how will it work and do you have any links we should check out, or people I can contact? The React virtual DOM has all kinds of elements that map to DOM elements, so how would it render in a native app? What about native APIs and Javascript that can interface with it e.g. like it does in PhoneGap? What is the equivalent here?

Is it like Titanium in some way?

mcintyre19942• 11 years ago

Since we've heard Facebook Groups is built with it, and it's said to be iOS/Android - to what extent is the choice to build Groups with this responsible for the fact it's not in the Play store? Basically, if Groups is ever coming to Android is this helping or hindering porting?

Xuzz• 11 years ago

Facebook Groups is available for Android: https://play.google.com/store/apps/details?id=com.facebook.g...

arasmussen5• 11 years ago

Actually currently only the iOS Groups app is built on top of React Native. (I'm Andrew, I work at FB on React Native)

curiously3• 11 years ago

Jordan, where is this conf taking place and what time (PST here).

You say this is not DOM or some hybrid solution?

Either this is too good to be true or ground breaking stuff.

Do you mean that react could completely get rid of having to write stuff in Java or Objective-C?

spicyj4• 11 years ago

http://conf.reactjs.com/

Yes, with React Native you'll be able to write native mobile apps completely in JavaScript.

jnbiche• 11 years ago

Any word on SVG support?

malandrew2• 11 years ago

Will this layer be released as a separate project so that other projects like raynos/mercury [2] or elm [1] can target this interop layer?

mercury was fully decoupled from virtual-dom [0] (such that you can use virtual canvas or virtual-gl). Would be really nice if this stuff can be used by other libraries easily.

[0] https://github.com/Matt-Esch/virtual-dom

[1] http://elm-lang.org/

[2] https://github.com/Raynos/mercury

doublerebel2• 11 years ago

Yes pleaseeeee tell me I can take advantage of just the View layer and use my own Model and Controller setup. With Titanium views are 'just' JS objects, so I can use Spine, Backbone, and other libraries for business and data logic.

magnatronus• 11 years ago

Apologies - In at the deep end with a very specific (hardcore?) question.

In Titanium it is difficult, if not impossible without resorting to a Native plug-in (which kinda defeats the object of using it IMHO as this is not 'Learn once, use anywhere'), to re-create an interface similar to the Facebook app. i.e. the vertical scrolling timeline with embedded horizontal scrolling images in each post. (on Android it really does suck) due to issue with memory, threading etc.

So I guess my question is, is it something to that React Native could cope with, or would it potentially suffer from the same memory, threading issues?

And my guess is that at some point it has to surface, so a good architectural comparison would be fab.

Perhaps the Hyperloop/React Native race is on :-)

jordwalke4• 11 years ago

I also covered some of the performance related questions in another HN thread here ("zero DOM not virtual DOM"): https://news.ycombinator.com/item?id=8964935

I'll try to address some of the other more specific questions inline.

tilt• 11 years 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

spicyj4• 11 years 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

joeblau• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

arms2• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years ago

oh boy now i can call myself an app developer too

akfanta• 11 years ago

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

jrm2k6• 11 years ago

React-native uses React code to build native applications.

sudhirj• 11 years 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• 11 years ago

Nice summary thanks :-)

devgeeks• 11 years 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?

danabramov5• 11 years 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• 11 years ago

Cue Om Native...

arms2• 11 years ago

God, I would love to see this (or Reagent Native).

bjr-2• 11 years ago

and Sablono Native

amelius5• 11 years 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...

drcode6• 11 years 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.

amelius5• 11 years ago

But then render() has to re-generate all the stuff over and over again, which could be slow.

hueyp• 11 years ago

Swapping out inner html has issues such as losing form data and bound events (etc...). Ignoring that you also have life cycle issues. For instance if you have a component that needs to know its render height you want a hook for calculating that height AFTER the entire DOM has updated. Otherwise you are going to force multiple layouts (bad). React provides these life cycle methods.

As far as the render method being big, the premise React is built on is that the virtual DOM is much faster than the real DOM. Test as necessary for your own comfort / use cases. I personally trust the testimonials of people smarter than me that aren't the React team also feel this is true and are making real changes to their products based on that. I also trust my own experiences that the DOM is slow :)

yazaddaruvala• 11 years ago

There are added benefits for an immutable / FRP style of building a UI, but I think you're more interested in the rest of my answer.

Nothing to be confused about, you have a valid hypothesis: "Rendering and Diffing in Javascript is slower than DOM manipulation". However, all hypothesis need to be experimented before having any real meaning.

It just happens that testing this hypothesis and finding it invalid was the foundation for React.

Watch this video[https://www.youtube.com/watch?v=XxVg_s8xAms] I think it does a good job discussing this hypothesis and why they chose not to worry about it.

amelius5• 11 years ago

So let's assume I have a listbox with N elements in it. I assume the render() method has to visit each of these elements every time an updates takes place, so it is O(N). Please correct me if I'm wrong here.

Now for a certain value of N, things will become slow, unresponsive. I'm guessing now that this value of N is above the value where the browser cannot handle this number of elements anyway. Is this correct?

PS: I understand that it is possible to completely optimize the listbox case. But that is not the scenario I'm interested in. I'm interested most and above all in the typical use-case. I'm just using a listbox as an example here. Just replace it by any other sufficiently complicated and customized UI component if desired.

masklinn• 11 years ago

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?

The browser tries to batch updates as efficiently as possible, but because of the model there are limits on that, reflow and layout thrashing are easy pitfalls to fall into for instance. React's model obviates these issues so the system can make significantly more assumptions about what is happening, and it can combine and batch more aggressively.

Furthermore, React's updates can trivially be delayed as much as necessary (in browsers, usually to sync them with the next repaint using requestAnimationFrame), not so for DOM mutations.

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.

It could be but it usually isn't, and more importantly for these cases (and others) the system can be told that there's no need to re-render the component (`shouldComponentUpdate` in react), the previous result can be reused as-is.

For "pure" components (which simply map application state to render state) it's easy to implement, and downright trivial when using persistent datastructures: it's just an identity check (which is why systems built from the ground up on persistent datastructures like clojurescript/om or elm.html are faster than "naïve" react OOTB: they can assume components are pure, will only use their parameters/state to generate UI state, and that said parameters/state hasn't been screwed with; React being a more general-purpose JS library can't afford to make these assumption, it has to be opted in explicitly)

crudbug• 11 years 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.

yuchi6• 11 years 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

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

doublerebel2• 11 years ago

Titanium comparisons are some of my top thoughts too.

1) How do they access the native API?

If there's no abstraction, just a translation, then the apps must be different for each platform. If there is an abstraction, then how much of the native platform do they cover? It can't be 100%, and the native APIs change with every OS version. Basic calls are easy, integrating things like device keychain, intents, and services are not so easy -- we learned this with Titanium.

2) How will React Native do cross-platform local data storage?

Being able to easily import, retain, and sync remote data is an absolute need for today's apps. Titanium uses SQLite on both sides, and has modules for more (like TiTouchDB). Not abstracting data storage would be a major mistake IMHO.

3) Can we use standard npm modules?

JS's killer feature is the module ecosystem, it's no good having a JS engine if we have to reinvent common modules to match a new API. V8 is the gold standard here, fingers crossed.

4) Debugging?

Speaks for itself. Debugging both JS and native code together bridged from a device is hard. Hopefully they are adapting existing tools and IDEs like node-inspector and Sublime Text.

yuchi6• 11 years ago

Exactly. As Haynie stated on tw, it’s sad that they didn’t included them in the design process. They already solved a lot of challenges.

BTW, did you have a look at titaniumifier? (https://github.com/smclab/titaniumifier) it’s a tool we built to port node packages to titanium (a declination of browserify, actually).

tzm• 11 years ago

Hyperloop is being used other internal APIs as well.

sz4kerto• 11 years ago

Will it work with Reagent?

csulmone• 11 years ago

Does this include desktop apps?

_pb• 11 years ago

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

serve_yay• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years ago

React Native is not built on the DOM and thus is not "hybrid"--it seems it's fully native under the hood.

alwaysdoit• 11 years 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• 11 years ago

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

ZZB• 11 years ago

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

chrisdevereux• 11 years 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.

psulatycke• 11 years 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• 11 years 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• 11 years 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• 11 years ago

React is the Future. Period!

b5i• 11 years ago

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

Use ReactJS to Build Native Apps

Related Stories