Hacker News new | comments | show | ask | jobs | submit login
Introducing React Native [video] (youtube.com)
542 points by arasmussen on Jan 29, 2015 | hide | past | web | favorite | 184 comments

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.

I too had a WTF moment when I first saw JSX but after seeing a bunch of videos from the FB team explaining the whole concept being React and Flux it just made so much sense.

After playing around with it a little bit I have to admit it's so much better than anything else I tried (vanilla JS, jQuery, Backbone, Angular, Dojo).

React (+ Flux) is possibly a great way to introduce people to web development since it avoids common pitfalls and really allows (forces?) you to think about what you are doing more clearly.

I think everybody reacts quite viscerally to JSX the first time they see it. Mostly because it looks like something that has been tried in the past and didn't work then. It's actually not like that at all, though. It's decidedly not a template language but just an alternative syntax for JS.

It stopped me from paying attention to React until someone suggested it might be the best fit for a problem I had and I followed the introduction's plea to "give it five minutes".

Turns out it's exactly what I wanted and needed. It comes with a lot of (optional but related) other good ideas like immutability and unidirectional data flow. I can't wait to see how React Native works out.

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

Yeah, JSX. Whoops!

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}>
becomes (more or less)

        {attr1: "value", attr2: foo},

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

We've announced a similar framework in December, it already has live-reload development with developer apps for Android and iOS https://eclipsesource.com/blogs/2015/01/15/fast-dev-roundtri...

Since React Native is using the background thread for everything, this limits what can be done with the UI. E.g. how are they going to handle user-directed animation if the operations are not run on the UI thread? These things can't be done in an async fashion... Curious to find out more about their architecture, leaving the judgement for later.

The link gives me a 401. Can you please open up the page or provide credentials to access it?

Ah, my mistake. Here it is again. http://eclipsesource.com/blogs/2015/01/15/fast-dev-roundtrip...

The video shows live-reload development in Tabris.js, with a developer app so you can test and debug on your device as you go. Pretty neat, huh? :)

Up till this day, I still hate JSX but love the rest of React. The syntax problem though, is easy to solve. The verbosity and ugliness of XML was already contested when it was conceived, as it was being called a re-invention of S-expressions. In the end, I wrote all my React apps in sexps with paredit mode. With simple, purely syntactic macros, it's pretty pleasant.

We just demoed something similar at the GWTCreate conference, an Angular-like library called Singular (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)

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

Honestly, this sounds like quite a technical achievement, but...

WHY? WHY? Why... are we still forced to go through these extraordinary lengths just to get pictures and interaction on a screen?

Long term, I want the Web to win. Eventually I think it will. In the 90s, no one ever thought apps like Gmail, Docs, or Maps could exist in the browser, and now no one questions that an Office suite can be done.

Eventually mobile performance, and API surface area will increase to the point where they're "good enough". Then they'll be an inflection point where people write Web apps for cross platform-ness for all but the most demanding stuff (like games or video editing)

But the web is just another set of absurdly arcane APIs upon (something) upon (other things). What I want i something like this:

I realize it's only-O'Caml at the moment, but I think this is mostly the kind of thing we're all striving for?

(IOW: I want you, personnaly, to work for this objective :))

I've been working on just this for a little while now (it's not launched yet, but the ideas and code are up): http://reapp.io

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.

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.

"We're pretty sour on the idea that write-once run-anywhere UIs are possible."

The guy in the video said a similar thing. It sounds like they want people to be able to use the same tools for each platform, not necessarily share all the code.

Oh, I missed that. I'm a big fan of React (working on DOM-diffing stuff myself for GWT), but I skimmed the video, didn't watch it through yet (rushing to airport)

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

That's an odd conclusion. They're clearly possible, perhaps you mean they don't provide some notion of excellent UI. But even then, web apps are rather a big counter-example ... web apps have never looked native, never been consistent with each other, they don't even try, yet many of them are very popular.

The nativeness of UI is something that seems to matter to developers more than end users. Users react strongly to polish and strong design, but if that is totally inconsistent with the platform only a vocal minority seem to care.

I works if you don't try to emulate the native UIs certainly. I agree with that, but some projects have design requirements to use say, native style guidelines.

The point about Swing is that, it's good, so long as we're talking about custom LAF, not the Windows/Motif/OSX PLAF, which look/act sort of like the OS UX, but not quite.

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.

> Web Workers being crippled

As Tom said, you can't do layout or prerendering-to-bitmap in a web worker: there's no DOM or Canvas API unless you bring your own, and despite Emscripten it's foolhardy to bring your own. If you want to decode a JPEG, you have to do that on the main thread and pass it to the worker right now (except in Firefox with its nonstandard ImageData API). [0] Which brings us back to square one.

> no one ever comes close to native widgets

I think a lot of that has to do with the fact that the iOS UIKit internal code for animations is closed source - the best anyone can do is reverse engineer, move their thumb and see how things react. What are the Bezier points on the curve used for the fade when you "back-swipe" from the left of the screen? Good luck figuring that out - it's possible, but only barely. Tom hinted at the idea that if developers were better organized, they might be able to replicate things better, but it would still be an uphill battle.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...

The curves used in iOS are all pretty standard, they're easily to replicate if you want.

It's pretty easily to replicate iOS functionality in iOS itself just because it's a better environment, it's not the 'secret' numbers.

But if taking the example of Paper, it's built on top of Pop which is absolutely open source and handles all the animations: https://github.com/facebook/pop.

So in theory you should be able to replicate all this stuff on the web, but you can't because it's just not build with highly responsive UI in as the focus.

You should help me do this! I have physics / spring based animations in my todo for a React hybrid app platform I'm working to launch now.

Since you are in native you could decode in native in a different thread and pass the decoded data into the Webview, but not sure if thats really better since you would still have to create an image object from the raw bitmap data.

There's quite a bit of hyperbole in this talk. Some web apps do in fact come close to native, but to the trained eye of a Facebook software engineer it will feel miles behind. Your average Joe doesn't give a shit, as long as they can use the app. If they did, Facebook's Paper wouldn't have been such a flop.

This is absolutely a great point, and honestly, I used this exact argument early on in the development of React Native to convince folks that cared a ton about craft and were super worried about performance, that it's more important to make sure you have a reliable application that adds value to peoples' lives, before you even earn the right to start thinking about craft.

My phrasing was somewhat hyperbolic, but I basically said: "Do you honestly think that a person, in the middle of a natural disaster, trying to determine whether or not their family and friends are okay, gives a sh about 60fps animations?"

The real value of React Native is that it allows engineers who know React (and React is really, really easy to learn btw), to build great feeling applications without putting in a ton of effort. Sure, it's possible to get close enough on web, but it's really, really hard to do so.

One of the things we tout in product infrastructure at Facebook is that when building frameworks, you need to enable engineers to fall into the "pit of success". The asynchronous nature of this implementation allows application logic to be run off the main thread by default, which we think is a huge advantage over a traditional web model.

The best part of React Native, if it can deliver on its promises, is that it will provide web developers with a toolset they can use that will satisfy customers or product managers who demand perfect native experiences (whether or not it makes business sense to demand it).

I think the poor reviews of Facebook's HTML5 mobile app shook the company to the core and they swung a bit far in the other direction, abandoning the possibility that the web will ever be mobile ready. I think the truth lies somewhere in the middle; no, you can't get native performance from the web, but you can get close. And every year it gets a little closer because phones are getting ridiculously powerful.

All this said, I think Facebook's approach to the platform fragmentation problem is clever and worth checking out, but I'd still bet on HTML5 over the long term.

Don't underestimate the users. They might use different words, but their comments and ratings will tell the story of web/hybrid suffering. Unfortunately web is not meant for apps, but for interactive documents.

Don't overestimate users either. It's very easy to build for other geeks rather than the General public. Netflix apps are almost all built using web technologies and it doesn't seem to bother most users. I think there's been an overemphasis on pixel perfect UI and on UX in general but people don't want nice UI's, they want useful apps.

For Netflix, the interface can only get in the way. People are there to watch movies and that's basically it. You can't "nail" the interface like you can with applications you interact with more.

It feels like there is a bias against web based apps in general because I usually have a bad experience with them or stop using an application when I get annoyed with the user experience. I'm sure it's possible to create a good user experience with a non-native toolkit. It just seems like the people that really give a damn go native in order to offer a better experience.

> For Netflix, the interface can only get in the way.

I would argue that for most apps, the interface can only get in the way - Facebook included.

Indeed. If I look at Slack which I believe is actually a wrapped HTML5 on iOS + Android it looks already very good.

But it doesn't have a lot of gestures+animations+images, so that might be the difference.

I don't think Slack is a HTML5 app, at least on Android. The apk contains ~2.5MB of bytecode and half a meg of layouts.

Wow. Indeed. thanks! I really thought that they were HTML5 based on how similar the HTML5 version is compared to the Android experience. Thanks again!

I think Slack is partially HTML5 and partially native on mobile.

iOS version is also a native app. As they look almost identical to web version, lots of people assume it's HTML5.

I've already asked them this question. Slack is native.

The desktop app is HTML5

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.

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.

I thought the talk had a nice balance of pitching the idea of native React and the technical ideas behind it.

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.

You're right that it's possible to get really, really close, but the effort required is very large and best avoided if possible. Not to mention, there will always be subtle differences between your UX and native, and it sucks to be in a position where you have to defend that difference to, say, your CEO who's asking why "it just feels different." Or worse, he can put his finger on exactly why it feels different and it's some tiny glitch that's out of your control but ruins the "polish" of the app in his opinion. It puts you in the position of either busting your ass to achieve the impossible or defending mediocrity.

It also sucks to explain to your CEO why it's taken so long to develop multiple versions of the apps. Theres tradeoffs for everything..

Do you have any examples of apps that come damn close ?

i think his answer was that all the magic numbers and heuristics that make the physics and animations and whatnot feel perfectly native are black boxes. if you want to make a "native" iOS/Android experience on the mobile web, you literally need to guess about all of those things -- and it'll always feel a bit off. probably a corollary of the uncanny valley

Isn't that exactly what Famo.us did, http://vimeo.com/86664858 .

Things are still being figured out. There are lots of experiments to make layouts render faster and motions more fluid; Virtual DOMs, JavasScript layout managers, canvas, WebGL, GPU accelerated CSS transforms.

I'm pretty sure an app like Paper is possible using web technologies (if you only support the latest browsers). I don't even see why they bring Paper as an example since I think the app is pretty shit UX wise.

So I have a simple question; how is this better than Swift or Objective C? It seems like Facebook has done everything in its power to avoid writing Objective C. I am also interested to know if this is what powers the current 1.7 star rated Facebook app. I am just having a hard time understanding how Facebook has earned much credibility with their mobile efforts. Also, how is this different or better than Ruby Motion? I just don't get it. We've had a lot of these fake native solutions but how does it work with existing Cocoa libraries, etc. I think the bigger question is why? Is Facebook allergic to actually writing Java ObC or Swift? Before the downvotes, consider the history and track record and quality of Facebook on mobile. I honestly don't know the answers to the above questions (they aren't completely rhetorical.)

Well, my money is on this (concept if not implementation) being the future of client-side development. Absent horrific performance/robustness problems, which seem pretty unlikely from this team, this is sounding like the droids we were looking for, the holy grail ring to unite us all, web and native.

And did even Steve Yegge ever see this next big language coming?

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.

To some extent the virtual DOM is what enables that, because it allows that style of programming while still having good performance.

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

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

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.

Is 'tomorrows' video online yet? Can't seem to find it, or has it not been tomorrow yet? :)

Here is the philosophy behind React Native: https://www.youtube.com/watch?v=KVZ-P-ZI6W4#t=1725

"Learn once, write anywhere."

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!

> react is the best thing happened to javascript


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

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

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.

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.

Take a look at this blog post on improving scroll performance. https://nolanlawson.s3.amazonaws.com/www/ionic_list_perf/ind... The biggest trick is to use CSS and pseudo elements instead of actual DOM elements and bindonce wherever possible. Performant scrolling on older Android will always be tricky, even on native.

Dude you should try Swift. Much easier.

I would, but I have not upgraded my macbook to mavericks yet. :-/

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?

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!

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

Honest question: Would you even need something like react on windows given that wpf/winrt already support dependency properties and data binding?

TL;DR to below: focusing on JS instead of Xaml seems like a smarter play for a .NET developer that hasn't used Xaml in WPF or SL previously.

I put "web oriented .NET developer" in my response for this specific type of question. I kind of defaulted (11 years ago) into ASP classic and ASP.NET as a result of ad hoc consulting/support work for MS technologies back in 2000. But despite my affection for C# I abandoned ASP.NET's faux desktop event driven emulation for MVC as soon as it was released. Ever since then I felt sort of stuck in between thinking of myself as a Web Developer vs thinking of myself as a .NET Developer.

Which brings my long winded response back to your original question about WPF and data binding. WPF and Xaml are pretty foreign to me (I still have no idea about how WPF/SL/WinRT Xaml differ it all seems like Xaml to me) despite a long history with C#. But I am interested in native app development, so I have been torn on whether to go all in with C# knowing I could take it cross platform with Xamarin but need to reorient myself into the Xaml world or go all in with HTML5 knowing Cordova could be "mostly good enough".

I'm a Microsoft fan (I actually enjoy my Surface RT and Windows Phone) so WinJS on Windows 8 seemed like a good hedge for not throwing away all my JS knowledge (which is becoming a predominant part of my work with SPAs) but still letting me go fully native. But the overall Windows dev community seems to have spoken, Xaml is it and WinJS is a pariah, MS doesn't help much by staying mum on the matter but I think they are trying to shove WinJS into the Cordova camp and double down on Xaml for Win 10 with WinJS eventually fading away.

I program in WPF in C# with absolutely no XAML. I used to use dependency properties/data binding a lot, I even made a wrapper [1] so you could write things like:

    w0.Right.Bind = w1.Left + w2.Width;
And that would automatically generate a one way data binding in WPF (so if w1's left property, w2's width property, or w0's width property changes, w0's left property is automatically recomputed).

I've since moved on to my own dependency management (rebranded hence forth as managed time) system called Glitch [2], but that's because I'm trying to invent what's next.

I'm an MS employee but I have no idea what what is being done in this area. I do have lots of respect for WPF, it was weird that the other platforms couldn't put forward a decent UI platform for so long (well, JavaFX, but it didn't go anywhere).

[1] http://bling.codeplex.com/

[2] http://research.microsoft.com/en-us/people/smcdirm/managedti...

I should have mentioned that I don't actually have a problem with WPF or Xaml from a technical standpoint (I've been watching several Pluralsight and MSVA courses and the binding certainly looks very powerful). My wavering between WPF/C# vs HTML/JS/C# is more about where I think development will be going in the future and how that works out for me professionally. That is why I really was hoping WinJS would take off so I could get the best of both worlds, being able to develop for an OS (WP/Win8) I actually enjoy but also not letting my web dev skills atrophy. I'm very curious to see if WinJS gets mentioned at Build this year or if it will fade quietly into the background.

React, as the developers argue, is a step beyond data binding. It emphasises immutability and a single data flow, rather than the combinatorial interdependency of the data binding approach.

One way data binding is supported by WPF also, I mean, two-way data binding is the unusual odd man out. And of course, the one way data flow functions have to be immutable and you have to take a dependency whenever when you read a property imperatively.

What they've done with react native sounds a lot like how WPF works anyways (scene graph updated in UI thread, rendering thread then renders scene graph). Now, there is nothing wrong with that, I think its all good. But I don't think there is a good reason to use React in Windows project since most of the problems it solves have already been solved.

Having worked on production software with both WPF and React, I can tell you why React's "data binding" approach is categorically different (better, in my opinion) than WPF's.

Like many abstractions in WPF, bindings have a "shadow world" feeling, where they are their own little isolated DSL. With the React model, "bindings" are just JavaScript expressions. Sure, with WPF you can overload operators and create "ExpressionBinding" converters and play other tricks, but you can feel the seams between the subsystems.

On the topic of the scene graph: React's scene graph is an abstract service that you can only interact with in limited ways. WPF's scene graph is a big mutable machine with most of its moving bits exposed. To a first approximation, React's rendering strategy is laziness and WPF's rendering strategy is fixed point iteration. The former is much more likely to produce easy to understand and high performing UIs, even if it comes at the cost of making a few special use cases harder. In such cases, you can bypass the abstraction and muck with the platform guts, which seems to be the default choices in the dependency properties context.

Right, WPF's declarative databinding support is separated from imperative semantics, even if they can interact a bit (a databinding relationship can be formed and destroyed imperatively). But I've moved away from WPF to Glitch, which doesn't have that problem: all code runs in the same world, with dependency tracing, re-evaluation on dependency change, and logging to support rollback as needed. In that case, now I'm curious how React compares to what I'm working on right now.

I've never heard anyone claim that laziness leads to more performant UIs. It has always been the opposite in my experience: by loosening up evaluation orders and allowing for glitching, you reduce the amount of book keeping needed to come up with optimal DAG-style re-computation orders. For example, consider a double-indirect (flat-map-style) dependency:

    countLabel.Content = folderView.Selected.Count;
If count changes, you update the label. But if selected changes, you have to stop observing the previous selected folder's count property and start observing a new selected folder's count property. Carefully tearing down and building back dependency chains is tough, but if you just play lose with the dependencies, it is actually quite easy to handle (you might get some spurious re-evaluations). Note that WPF can't handle this without lots of hackery, which is one reason I moved all my UI work to Glitch (the other is that WPF is totally inappropriate performance wise for writing compilers and language-aware editors). I'm curious how React handles indirect state? Or does it need to do dependency tracing at all (it wouldn't if its not incremental; I can't tell by looking at the website)?

It doesn't have to track dependencies at all, but it is certainly still incremental. Maybe you should study it before judging it.

I've looked at the examples; I guess we just have different definitions in what incremental means.

cause I'm starting to excell in javascript and never even touched C#?

Honest question: you don't mind switching from a modern well-designed static language to legacy hastily-designed dynamic language?

I do a lot of Javascript for the front end SPA of our WCF based api, so I'm content with both js and C#, I try not to get too hung up on either language's respective baggage.

This is awesome.

I can't wait for the API docs and sources to be released.

Tweets and videos are lousy at conveying information : )

Nice! What about windows phones?

Yep - is there any reading-based info on this? I can't bear absorbing tech info via a channel as slow as watching or listening to someone...

Link please!

iOS and Android.

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

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

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:


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.

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.

The demo doesn't render on Safari on iOS 8. :-\

I'm Jordan and I'm on the React (and React Native) team. There's been some great questions and insight on this thread. React Native offers a ton of benefits around productivity (and ability to use React of course), but since there are many questions about performance, I thought I'd share some of my own personal perspective on the matter.

React Native is very different than other approaches because:

1. We're not promising to give you One Weird Trick that allows you to change nothing about your development philosophy/practices and yet automatically create excellent mobile experiences. If you're developing for mobile, and you want an excellent user experience, you must care about performance and you must care about programming nuanced interactions. Behind any great mobile experience, is someone who cared. Don't believe anyone that tells you differently. However, I feel that the amount of work that React Native asks of developers in order to achieve it, is much less than any other alternative that I've seen.

2. React Native doesn't use the DOM at all. React naturally tames many of the performance issues that typically arise from unpredictable programming practices in the browser, but that can only get you so far. React Native takes it to the next level, beyond what can be done in the browser. React Native shows that ReactJS has always been more about "zero DOM" than "virtual DOM" (contrary to popular belief).

4. React Native is different because we want to keep some of the best parts about web development. Just because we want the performance and resource control of native views, that doesn't mean we should abandon the great things about the web. With React Native, you can use CSS FlexBox to lay out your native views, and many other familiar style attributes - but without the catastrophic CSS style reflows. The event system also works exactly as it does in your React apps today because it runs the same library code. By building in terms of the subset of web styles/layout that we know we can make fast native implementations for, it allows developers to build great apps today without setting back progress of the web in the future. I feel this is strictly better than encouraging developers to abandon anything remotely resembling web technology and instead learn a completely different toolchain (or two or three).

3. React Native is different because it makes high quality apps written in JS possible. With browsers, you will likely run up against a fundamental limitation and there's nothing you can do about it. Either you don't have access to a platform component (certain scroll view with physics/Maps), or the interaction that you're implementing keeps getting interrupted by image decoding and there's nothing you can do about it.

With React Native, you can do something about it. You can build ReactJS apps using native platform views that could never be implemented in JS (like Maps), and you can also build using higher performing granular building blocks (multi-threaded decoded <Image />) (<View/> blocks that don't use the DOM at all). The result is that this unlocks an unprecedented level of quality that feels great and matches the platform characteristics.

Is the JavaScript 'react host' implemented in native (Objective-C/Swift/Java) language and interpreted during runtime? How are the calls between threads managed - especially wrt marshaling of data structures?

Flux store now originates from native source - do we now have a 'native -> JS interpreter -> native' double transition on every flow?

If the JavaScript is interpreted, would hot-loading mid-flight to change behavior of the native app be possible?

Do you guys have a set of cross platform components like <Image> , <View> , <Map> that will work across Android , iOS and Web ?

The native components might behave slightly different on each platform so I was wondering if you guys have subclassed the native components to behave similarly on all platforms.

We have a <View> and <Image> that works on iOS and Android. We also had web implementations working as a proof of concept but I'm curious if the community would be more interested in helping us implement/maintain the web implementations since we want to focus more on the integrations with each native platform for now.

You're probably aware, but it's always good to keep in mind that we don't have a goal to allow people to "write your app once, run anywhere". You should be able to share as much code as you want to share, but the truth is that great mobile experiences design not only for the platform, but even for the device. We should build apps that take advantage of the extra screen real estate on an iPhone6+, for example. So even within a single platform, you'll want to design specific experiences, and the same goes for implementations across different platforms.

That's interesting. I guess I can't really understand it until I see it finally released. A set of basic widgets like Lists,Sliders and Switches should definitely cover most use cases.

How are react native apps architected ? Is it something like a model that is written in pure JS that is common for all platforms ?

So after I've created the model in JS , would I have to tailor the render() method for each platform ?

Is it going to be fairly simple to drop-in/build a framework like marty.js & have it render React Native?

Is there plan for windows phone ?

Hi Jordan, I'm interested on which CSS rules causes reflows?

Avoiding CSS reflows in modern browsers should be pretty well documented, and I imagine it only makes sense to discuss reflows in a particular browser. @vjeux will cover more about the style/layout API in React Native tomorrow, but the main point I wanted to get across is that React Native's style rules are a limited subset that are generally cheaper to compute. More importantly - the result of these computations aren't given to the JS environment in a synchronous manner. You can't read/write/read/write style properties/computations and inadvertently trigger more reflows than necessary. I've seen that pattern make web experiences unusable. In React Native, reads must be done asynchronously, and they are batched together for efficiency. Not only is this one major footgun that React Native takes away, but the asynchronous nature also means that style computation (layout primarily) can be done in a different "pipeline" stage, which opens up future opportunity to parallelize that work with JS execution.

http://csstriggers.com/ (appears down at the moment, in the meantime see http://css-tricks.com/css-triggers/)

Does JS run on the device or it's RN a pre-compiler?

Minified JS runs on JavaScriptCore

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

The memories of GridBagLayout still haunt me to this day (see username).

This is a classic gridbag cartoon: http://madbean.com/anim/totallygridbag

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.

Heh, I remember coding a vertical FlowLayout in 1999 (before that was included) out of fear and loathing of GridBagLayout...

What is the defacto best way to learn React? I like the architecture and the coding style, but there doesn't seem to be a lot of talk about best practices.

I second this

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

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.

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.

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

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.

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.

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

Scroll down? CTRL + F the comments, and you'll see that someone did a "tl;dw" hours ago

I scrolled but I didn't notice it, thank you

You can skip the first 20 minutes if you just want to learn about React Native.

Yeah, is it really native or is it just marketing speech about same ol' crappy JS?

Looks like React is reaching critical mass.

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.

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.

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" ;)

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.

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?

React follows an approach similar to 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.

You basically instantiate a view controller with a string of js and it works. Can drop into existing app for one view.

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 [2] https://itunes.apple.com/us/app/facebook-groups/id931735837?...

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.

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.

Thanks, much clearer now. :)

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?


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 ... self contained components, completely parallelizable etc. Also in PHP and JS :)

And it all works!

I understood that the native react serializes the ui "DOM" to some format and sends it to the native process. Will the native rendering engine be open source and/or will the protocol be open/specified ? This could be handy for embedded targets.

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! :)

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.

Nope, there's no DOM or HTML. It's creating native iOS/Android views.

Hey, our team is using React to build STB interfaces. Would love to chat about your experiences, drop me an email? davedx@gmail.com :)

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

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.

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

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

Jing said there's full binding and easy access to any native service

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

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

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

A lot of people here feels offended by new ideas. I bet that many here commented even before the end of the video, and probably never used React on real apps. Could We avoid the tribalism and territorialism, please?

Basic question - does this make it easier for someone who knows (or can hack around in) JS to create a native android app? I'm thinking/hoping yes from the video and comments...

Sounds excellent. I need it today.

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

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

Already done with Smartface App Studio.

What is this and why is it a big deal?

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

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

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.

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.

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

How can you possibly say this without seeing a single line of code?

Those mobile Javascript frameworks uses the DOM. React native won't.

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.

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.

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.

One of the reasons I have more confidence in React than Angular is that Facebook and Instagram actually use React in flagship products. I wouldn't worry about React abandoning the web until Facebook and Instagram stop using it for their web products.

Also, while all Dart does for Angular is fragment the community (because now we have Angular web devs using Dart, Angular web devs using JS and soon Angular web devs using AtScript), React Native actually does the opposite.

A lot of web devs already also do mobile development or at least work on hybrid apps (i.e. WebView-based mobile apps). React Native enables web devs to develop mobile apps that wouldn't have been feasible before (either because of the limitations of WebView or because they would have had to worry about learning an entirely different stack that is orthogonal to their web technology knowledge).

I work on React. We're not abandoning the web.

But you are deemphasizing it, no?

> If I'm one of Reacts competitors I'm ecstatic that they're abandoning the web.

Wait, can you quote where they said that. Maybe a particular time in the video...

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

Instead of "abandoning the web" I'd call it a "post browser" framework. What we're seeing here is the first piece in the next-gen internet world that doesn't require a web browser.

Where was the web abandoned?

React is no longer a web library, so today.

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

Expansion != abandonment. In fact, were I a "competitor," I would be concerned about the philosophical buy-in that said expansion could induce.

It's not? I must have missed that announcement.

I think you misunderstood. they are adding a non web library, not leaving the web.

The benefits of using Dart are debatable. There are however no such doubts on the utility of native mobile apps. The lack of adoption of Dart is due to the lack of interest within the broader JS community; the same community which is going to be excited about React supporting native apps. This immediately improves the targets to which they can deploy with skills they already have.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact