
Introducing React Native [video] - arasmussen
https://www.youtube.com/watch?v=KVZ-P-ZI6W4
======
iLoch
I'm part of the group that thought "what the hell?" when I first saw the React
syntax - but seeing this has completely changed my mind and I'm really looking
forward to picking up React as soon as possible.

If this delivers on its promises (no reason to assume it won't, seeing as it's
already being used in large apps) then it's going to change the mobile
development landscape.

It sounded like they may even be hinting at in-browser testing the way they
were knocking on provisioning profiles and perhaps maybe even some sort of
live-reload development tool? I'm really interested in seeing what kind of
tools Facebook will make available along side the core React Native project.
Mind you, this is a huge gift even if they don't have any fancy tools to go
along with it.

Really excited, thanks FBOS team.

~~~
masklinn
> when I first saw the React syntax

Do you mean JSX? Because "the React syntax" is just plain JS unless you're
using JSX, is it not? IIRC even vdom nodes can be created by hand with literal
objects.

~~~
iLoch
Yeah, JSX. Whoops!

~~~
masklinn
Yeah it's completely optional, facebook built it because they had built
something similar previously and they like it, and I guess it may be simpler
for "pure" designers used to HTML and stuff, but it's AOT-compiled to the
corresponding JS calls and the mapping is fairly simple:

    
    
        <Component1 attr1="value1" attr2={foo}>
            <Component2/>
            <Component3/>
        </Component1>
    

becomes (more or less)

    
    
        Component1(
            {attr1: "value", attr2: foo},
            Component2(),
            Component3()
        );

------
cromwellian
We just demoed something similar at the GWTCreate conference, an Angular-like
library called Singular ([http://daniel-
kurka.de/talks/gwtcreate15/singular.pdf](http://daniel-
kurka.de/talks/gwtcreate15/singular.pdf))

It differs in that it uses the same techniques as Google Inbox to run native
code. We cross compile to Objective-C with j2objc, and cross-compile to JS via
GWT, the data binding, controllers, are shared code on all platforms that run
full speed native, while the UI templating language on each platform is
platform native (e.g. angular directives directly in Android XML files)

It produces completely platform-impedance matched apps on each platform (e.g.
native on mobile, JS on Web) while allowing the continued use of the regular
UI design toolchains people are used to (Android Studio/Xcode Interface
Builder)

~~~
lomnakkus
> 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?

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

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

    
    
       https://www.youtube.com/watch?v=UEIHfXLMtwA
    

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

------
bobajeff
I wish they'd go into more detail on why they can't make an app like paper in
the browser environment. They mentioned something about Web Workers being
crippled and later on explained how their framework puts JavaScript in it's
own thread by default.

I'm also wondering why in their experience no one ever comes close to native
widgets when imitating them in a Web apps.

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

~~~
tomocchino
You're absolutely right that it is possible to get close. I think my main
point here, (though I probably didn't cover this well enough and I was being
somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the
default on web, and it's actually really, really hard to get there.

Sorry for coming across as a sales person. Someone tweeted about a previous
presentation of mine in the past asking "who the hell is this marketing guy
they had do this talk". I assure you I'm not in either marketing, or sales, I
just get really excited sometimes.

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

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

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

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

~~~
donw
Having spent the past six or so months working with React and Flux, I sure
hope so. For the first time in my technical career, I've actually _enjoyed_
working in Javascript.

The real power of React isn't just the virtual DOM -- it's being able to
leverage Flux and an immutable, single-source-of-truth app state. Pretty much
every time I turn around to build something, this combination has made what
used to be an exercise in hair-pulling into an absolute joy.

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

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

~~~
rattray
And just as a heads-up to those who haven't watched, implementation details
and code samples are coming tomorrow.

But basically the tl;dw seems to be that you can write JavaScript React code
that runs efficiently on mobile and renders _native_ primitive components
instead of dom primitives (<View> instead of <div>).

It also introduces the idea of "Learn once, write everywhere" instead of
"Write once, run everywhere", which I think is a great idea.

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

------
DAddYE
I think this can be really amazing as is react js now.

\--

I had to build a simple at first but very complex under the hood. I wrote that
app in a weekend with react and was a ton fun and most important worked well
since day one.

I have been out from the web development since like 1.5 year, but yeah IMO
_react is the best thing happened to javascript since ... ever._

Thanks again guys!

~~~
k__
> react is the best thing happened to javascript

Why?

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

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

~~~
squeaky-clean
Same situation here, using Ionic, but this seems extremely cool. I'll
definitely build something with ReactNative as soon as I can. We're only
making a news app, but Ionic feels completely native once we optimized it
correctly and use the latest beta features.

As for Android being slow does that include 4.4 devices, or just older version
of Android? If it's older devices, you should try the new Ionic beta with
Crosswalk integration (you'll need to install/enable Crosswalk, but it's very
easy to do). Sadly, it'll add about 25mb to your .apk, but on phones earlier
than 4.4 the performance boost is at least 10x if not more.

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

~~~
perryg
Take a look at this blog post on improving scroll performance.
[https://nolanlawson.s3.amazonaws.com/www/ionic_list_perf/ind...](https://nolanlawson.s3.amazonaws.com/www/ionic_list_perf/index.html)
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.

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

~~~
evv
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!

~~~
jbigelow76
Very interesting. Microsoft allows you to build fully native (not webview
wrappers) apps using WinJS, and they have shown that React (along with
Angular) can be used to build those apps [1]. I wonder if Microsoft will put
resources into bridging the gap between React Native and Windows 10.

As a long time web oriented .NET developer wanting to pick up mobile who has
been wondering whether to go Cordova or dive in fully native (ObjC/Java/Xaml)
this is going to make the choice very difficult.

[1] [https://github.com/winjs/winjs/wiki/Using-WinJS-with-
React](https://github.com/winjs/winjs/wiki/Using-WinJS-with-React)

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

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

~~~
seanmcdirmid
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/](http://bling.codeplex.com/)

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

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

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

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

------
rattray
Just a minor quibble; I think the speaker is a bit too negative about faux-
native apps, especially with React. For example, see this demo by Pete Hunt:

[https://medium.com/@floydophone/building-a-real-time-
frosted...](https://medium.com/@floydophone/building-a-real-time-frosted-
glass-effect-on-mobile-web-87ce4a41019f)

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

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

React Native is very different than other approaches because:

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

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

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

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

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

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

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

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

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

This is a classic gridbag cartoon:
[http://madbean.com/anim/totallygridbag](http://madbean.com/anim/totallygridbag)

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

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

~~~
lllllll
I second this

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

------
tinganho
I wonder why it is such a big of a deal of not having DOM API:s on the
WebWorker thread? I think the discussion from Browser vendors is that there is
no use case or benefit of having them there.

And not having the "native feel" or performance. I think browser vendors are
on the verge on closing this gap totally. If not browser vendors, hardware
will do it.

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

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

------
somethingreen
When I tried similar solutions (running business logic in JS and abstracting
native platform specific UI implementations), one of main problems I
encountered was that JS was running in a clean VM while most libraries rely in
some way on either browser or node.js environment. I wonder if React Native
addresses this.

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

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

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

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

------
calebm
Looks like React is reaching critical mass.

~~~
briandear
Based on what metric? A Facebook team talking about a Facebook framework and a
HN thread filled with React enthusiasts? I am not bashing any of it, but to
suggest critical mass is a bit immature.

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

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

------
ceeK
Can someone elaborate on how React Native would fit into the app development
workflow (iOS)?

Having a brief look over the ReactJS webpage, it seems like it would replace
view controllers and perhaps Storyboards?

Or are we talking about writing the entire application in Javascript,
declaratively?

~~~
rickyc091
React follows an approach similar to ReactiveCocoa
([https://github.com/ReactiveCocoa/ReactiveCocoa](https://github.com/ReactiveCocoa/ReactiveCocoa)).
It helps modularize the code into components instead of having a spaghetti
string mess that often happens in view controllers.

Currently there is no details on React Native, however, I don't believe it
would replace the Storyboard as views are still necessary for the React code
to interact with the components.

What you would be doing is coding in JS and behind the scenes your app would
interact with the views and do the necessarily updates. I'm guessing it'll be
a hybrid approach. While you'll most likely still need to know Obj-C or Swift,
you can probably get away with a lot of boiler plate code with React.

------
stanzheng
From the video, Facebook mentions that they are using the React native for the
Facebook iOS groups application. Theres a live demo to demonstrate. Video
starts at 24:05.

[1] [http://youtu.be/KVZ-P-ZI6W4?t=24m5s](http://youtu.be/KVZ-P-ZI6W4?t=24m5s)
[2] [https://itunes.apple.com/us/app/facebook-
groups/id931735837?...](https://itunes.apple.com/us/app/facebook-
groups/id931735837?mt=8)

------
Nilzor
Can anyone please explain what a "declarative API" is, and why that is better
than an imperative? He claims this is the best part of the framework, but I'm
just left with a big "what?" since I don't understand what the hell that
sentence means.

I mean he admits he had to build a bunch of products before he understood the
concept, but didn't waste a single slide to explain it in the presentation.

~~~
robertfw
The briefest explanation is that imperative is a list of instructions
describing how you want something done. A declarative approach describes what
you want done.

The typical example for this is SQL - you don't tell an SQL database how to
run a query, you tell it what you want, and it figures it out.

In Reacts case, you describe your application in terms of components that know
how to render themselves given different sets of data, or states. When the
application state changes, the entire application is re-rendered. The "magic"
of React is that the use of a virtual dom to create an efficient diff from the
current dom state to the new dom state allows this to be very performant,
ensuring a minimum of actual dom changes are made.

The resulting components are much, much easier to reason about. You can see,
looking at the code, exactly how the component will behave given different
data. In essence, what you see is what you get. This is a far better dev
experience than working with components that can be mutated by events; you
need to build a mental model of all the various states that the component
could find itself in.

I was driven to this approach using Backbone to tame a particularly complex
interface, similar in complexity to the ads example shown in the video. But as
mentioned, doing this naively (in this case, re-rendering a backbone template
instead of mutating it), leads to all kinds of user interface glitches. React
smooths over those glitches.

~~~
Nilzor
Thanks, much clearer now. :)

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

------
zkhalique
[https://www.youtube.com/watch?v=KVZ-P-
ZI6W4](https://www.youtube.com/watch?v=KVZ-P-ZI6W4)

Look at 10:00 ... that sounds very much like what we were going through and
building at the exact same time

[http://platform.qbix.com](http://platform.qbix.com) ... self contained
components, completely parallelizable etc. Also in PHP and JS :)

And it all works!

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

~~~
arasmussen
Yep, you've got the gist of it. We render the app in JS, React creates this
view hierarchy (still in JS), this is serialized and sent over the bridge
(asynchronously) to the native engine who then creates the equivalent native
view hierarchy and renders it.

The source code for the iOS native engine (and the JS infra, and some
examples) will be given to attendees of React.js Conf tomorrow (Jan 29). The
iOS and Android versions of React Native will be open sourced soon! :)

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

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

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

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

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

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

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

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

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

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

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

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

------
aceperry
Sounds excellent. I need it today.

------
yuchi
\-- Attention -- Cross posting from the other thread --

Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of
people here is comparing this announcement from the react team to the Titanium
Mobile SDK. I’d like to give some info to shed some light on the differences,
and probably anticipate the challenges they have to (or had to) solve.

## Architecture

Both Titanium SDK and this Native React thing do have a JavaScript runtime
behind the curtains.

Both frameworks will run the JS runtime on the background, on a different
thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using
factories (`Titanium.UI.createScrollView({ })`) and you add those views to
parent views (`parent.add(child)`). This is very similar to a browser DOM, and
in fact it’s cumbersome to work with. They built an xml preprocessor called
Alloy which does a better job at exposing the view hierarchy right in the
source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation at least for the following reason: every
time you update a property on a view (actually on a proxy object to the real
view) you’re crossing the bridge and you have to pay that penality. The bridge
is the void between the JS runtime’s thread and the main, UI’s one. This is
incredibly painful when trying to do JS animations, sometimes if you’re not
careful you can get hurt very badly. You can still do great things, but it’s
way better to use the native `.animate()` methods, which cross the bridge only
twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will
be batched and updated on a update loop basis or at least debounced. Or at
least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don’t want the developers
to understand every layout system every platform provides, they have to
normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy
to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the
parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to
horizontal.

Native React will probably follow a more intimately web-ish approach, just
look at this JS/C/Java implementation of the box-model and flex-box
specification by Facebook itself [1]

[1]: [https://github.com/facebook/css-layout](https://github.com/facebook/css-
layout)

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with
it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by
proxying from native-land to JS-land;

2) they have to follow every release of the platform’s SDK;

3) you cannot just put native code along-side your JS code, so you cannot go
where they didn’t.

Let’s see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this
issues. The project is code-named Hyperloop and is already working behind the
curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I’ll stop here.

It’s interesting, but until they show us some (native) code... it’s just
ideas.

Follow me on twitter (@_pier) and github (@yuchi [2]) for Titanium related
stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on
gh we’re @smclab)

[2]: [https://github.com/yuchi](https://github.com/yuchi)

------
kas0
Already done with Smartface App Studio.

------
bronz
What is this and why is it a big deal?

------
solarexplorer
Am I getting this right: they use something like Display Postscript[1] instead
of the virtual DOM? Are we back in the 80ties?

[1]
[http://en.wikipedia.org/wiki/Display_PostScript](http://en.wikipedia.org/wiki/Display_PostScript)

~~~
jdub
No, React Native translates a declarative API into imperative calls. Just like
React does in the browser (after going through the Virtual DOM as,
essentially, an optimisation).

~~~
solarexplorer
Yes, just like the DPS interpreter translates (high-level) DPS into (low-
level) pixels. Looks pretty similar to me. (but then I am not overly familiar
with DPS or ReactJS)

EDIT: To clarify, I am sure that the current UIKit also tries to do optimize
rendering. They probably do some kind of internal batching, etc. But they have
no (public) data format like DPS or a virtual DOM that is generated, optimized
and rendered. I don't think that DPS is all that different.

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

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

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

~~~
digvan
It's not about DOM. UIKit is pretty sofisticated to build layer to translate
JS to native code. It needs years of work and constant update.

~~~
aaronbrethorst
::cough::
[https://twitter.com/andy_matuschak/status/560511204867575808](https://twitter.com/andy_matuschak/status/560511204867575808)

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

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

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

~~~
Touche
But you are deemphasizing it, no?

