
React Native at Instagram - martin_bigio
https://engineering.instagram.com/react-native-at-instagram-dd828a9a90c7#.88g2rf8hr
======
a13n
This is huge. 87-99% shared code between iOS and Android. Someday companies as
big as Instagram won't need to have entire separate product teams for separate
platforms.

> React Native allowed product teams to ship features faster to both our iOS
> and Android apps. The list below shows the percentage of code shared between
> the apps for some of the products, which could be used as a proxy to measure
> how we managed to improve developer velocity:

Post Promote: 99%

SMS Captcha Checkpoint: 97%

Comment Moderation: 85%

Lead Gen Ads: 87%

Push Notification Settings: 92%

~~~
codazoda
I'm working on a project where we are recreating a native app using React
Native. We've found similar results; about 90% of our code is shared between
both platforms. We also build both platforms every time, so both apps match
really well. I'm not sold on React yet but this is a major plus to the
platform.

~~~
what2
That seems like a big plus for React Native.

What are the negatives you have found?

~~~
htormey
I was at the SF React Native developers meet up the other night, the speaker
(Devin Abbott) gave several nice pro/con's slide re react native. Here's a
picture of the slides:

[http://imgur.com/a/T3O7i](http://imgur.com/a/T3O7i)
[http://imgur.com/a/z2oIU](http://imgur.com/a/z2oIU)

~~~
tedmiston
Great comparison. Slides transcribed:

\-- Slide 1 --

Maybe we should use React Native:

\- We know JS / React

\- We have lots of web developers but few mobile

\- Our design is brand-focused

\- We're willing to invest in RN

\- We want to get into OSS

\- We want OTA code updates

Or maybe we shouldn't:

\- We don't know JS / React

\- We already have an iOS team and an Android team

\- Our designs are heavily platform-specific

\- We don't have the time or money for an RN team / OSS

\-- Slide 2 --

Pros:

\- Cross-platform

\- Performant, native feel (with some effort)

\- Great developer experience

\- Push updates over-the-air

\- Strong community

\- Backed by Facebook

Cons:

\- Early

\- Unstable (bugs, APIs)

\- Ecosystem not fully developed

\- Polished apps are high effort

\- You may need native code (so JS + Obj-C + Java)

~~~
gaza3g
Thanks for this.

The thing that captured my interest was the point about being backed by
Facebook. Parse was backed by Facebook and look where it is now.

~~~
eclout
I don't think Facebook backing Parse is relevant. React Native was designed by
Facebook, so I'm assuming they understood the design choices of the mobile
ecosystem at the time.

Parse was an acquisition by Facebook that didn't end up working out.

~~~
spicyj
I'll add that we use RN in our production apps and are building it for
ourselves but never used Parse in the same way.

------
intoverflow2
This is a bad sign to me, talks about how to optimise start up performance and
optimise list views when the processors in our pockets are the fastest they've
ever been.

Do we really have to switch to developer centric development where devs have
an easier life using JS at the expense of performance?

Think the millions of users would prefer their devices to have better battery
life, load faster and have less cruft just to draw a few text boxes of a
profile edit screen or a grid of photos (something I would have thought would
be effortless to mobile devs in 2017). Rather than the handful of devs having
a slightly easier day at the start of the process.

This whole move seems especially strange to me coming from a Facebook company,
have we forgotten the move from native > webtech > native already?

~~~
reggieband
> devs have an easier life using JS

I think that is willfully missing the point. Creative work, especially UI-
centric product development, requires significant iteration. Layouts change
frequently, entire view hierarchies can be re-worked, sizes are tweaked
obsessively.

This isn't just about decreasing the burden of engineering (as if
Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the
time from concept (e.g. Photoshop mock) to implementation (interactive working
app) so that iteration can happen quickly.

As much as I love the performance possible when coding directly against Native
APIs, I also have direct experience using web views in native apps. The
improvement in the design process around web views is worth investing in
getting the performance as close as possible to native. This is multiplied
when you consider the cross-platform benefits. However, the performance and UI
experience of web views is not good enough.

I can't vouch for React Native giving the iterative benefits of pure web view
development nor the performance benefits of pure native development. However,
if it does strike a reasonable balance between them I can totally understand
why people invest in it.

~~~
nonsince
So why not have a virtual DOM-based data-driven layout engine that _isn't_ an
HTML/JS stack. Something in a language that is more optimisable and works
everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard
to get predictable performance from and HTML is extremely complex, we can do
better if we're writing native apps (hell, we should have had a better online
solution years ago too, but we don't have control there).

~~~
reggieband
> why not have a virtual DOM-based data-driven layout engine that _isn't_ an
> HTML/JS stack

I'm not advocating RN, I just understand the motivations behind frameworks
like it. I think "to make devs lives easier" is not a fair assessment. Also,
to be fair, JS performance is generally adequate. My own experience with
performance on mobile devices often fell back to rendering (e.g. managing
textures, making animations smooth, infinite tiled scrolling). Very rarely was
raw CPU processing a major concern. My experience may not be typical.

As for other cross platform native development libraries/platforms/etc. - I've
had some experience with a few of them (e.g. marmalade[0] which was in C++)
and generally they do not work for me. I even attempted to write my own and it
was its own monster.

In general, I am personally biased towards Native. I would definitely take RN
on a test spin if I was in the prototype phase of a new app. I would use that
time to determine if I wanted to bring RN into production or re-write as
Native.

[0]
[https://en.wikipedia.org/wiki/Marmalade_(software)](https://en.wikipedia.org/wiki/Marmalade_\(software\))

~~~
LeoNatan25
What is "adequate"? Any long term task still hangs the business logic thread -
the only thread - unless you fallback to native. At what point does constant
fallback to native for implementing what is not possible in JS a detriment to
development? You may say, multithreading is an edge-case, but is it? I have
not been involved in a single project where actual multithreading was not
needed. Also, the way RN is implemented internally, such as async bridge and
layout (CSSLayout / "yoga"), it is quite impossible to use native optimized
views, such UITableView with reusable views, because this API is designed for
synchronous API calls.

------
40acres
I didn't know what single/multi-dex means so i looked it up.

Android application (APK) files contain executable bytecode files in the form
of Dalvik Executable (DEX) files, which contain the compiled code used to run
your app. The Dalvik Executable specification limits the total number of
methods that can be referenced within a single DEX file to 65,536, including
Android framework methods, library methods, and methods in your own code.
Getting past this limit requires that you configure your app build process to
generate more than one DEX file, known as a multidex configuration.

Do Android apps regularly encompass over 65.3k methods? I assume a majority of
these would be framework type functionality, but it really seems that a multi-
dex product would be near impossible to maintain.

~~~
bitmapbrother
This is one of those Android design decisions that Google probably wishes they
could get to do over again. The DEX header file format allocates only 2 bytes
to hold the number of methods the app can reference. This was a very short
sighted decision that has come back to bite them repeatedly. It would be
interesting to know why they only allocated 2 bytes instead of 4 which would
have given them the ability to reference over 4 billion methods. If their
reasoning was for cost saving measures than it was a pretty silly decision.
There has been some talk about revising the DEX header file format to correct
some of the early design mistakes, but I'm not sure when they'll get around to
it.

~~~
kuschku
It's not that easy, and not just one field.

DEX uses a method table, listing every method with an ID, and using in the
rest of the file only that ID to refer to it.

This ID is limited to 2 bytes.

Obviously, thats an issue, but short of using varint or straightaway uint32
there's few alternatives. And those use either more CPU or memory.

~~~
bitmapbrother
Thanks for the correction. Here's a transcript from the Android Developer
podcast, courtesy of [http://blog.osom.info/2014/10/multi-dex-to-rescue-from-
infam...](http://blog.osom.info/2014/10/multi-dex-to-rescue-from-
infamous-65536.html), talking about the issue with an Android engineer:

>Tor: So [regarding] the infamous 64k method [issue].. I understand that it is
a dex file format limitation.. which is a short integer. Do you have plans to
address this somehow, by either change the dex format or some other way?

>Anwar: So we've talked about revving DEX, so that limitation doesn't exist
anymore. And there's a couple of reasons we haven't done that: one, there're
other things we would like to do better as well, including supporting new
language features. The other reason is - it doesn't help us with devices still
in the field. It's hard to go and say "by the way, we're going to upgrade your
runtime.." So what do we do in order to address that? We will do the DEX byte
code [change], but I think there's sort of building block that we needed first
- what we're calling multi-DEX. And the idea is.. here's something people were
doing - they were breaking up their files into multiple DEX files (each of
which exceeds the 64k limit), the main classes in DEX file could see the
classes and use them in sort of references rather than loading those classes
and having limitations in how you can use them. They will go and use
reflection to find the boot class path and modify it to include their
secondary DEX files. So this is kind of hack, but a necessary one for them.

>What we're doing in L is in runtime we will have a native support for multi-
DEX. All your DEX files that you have in your app will get dexopt-ed or
compiled by us and collapsed into a single .oat file which is a binary file we
generate.. ..And we have a support library on top of that.. ..if you have
multi-DEX it will work on older releases of Android back to Ice Cream
Sandwich.. will work on Gingerbread too, but we're only validating back to
ICS. So once you have that, than that free's you in the future to do the DEX
byte code change, and then something that partitions it and runs on the
existing [devices]..

One interesting note is that he mentions that they'll hopefully have the DEX
revision by M. Well, we're on N so it looks like they missed that target date.
Perhaps O will finally get the long awaited DEX file format revision.

~~~
pjmlp
Available on 0.x% of devices, thanks to them not forcing OEMs to update as
part of Play Store contract.

~~~
bitmapbrother
Yeah, why they don't enforce this is baffling. I can give them a break for
letting their OEM's take their time with OS updates, but not requiring their
OEM's to issue security patches is negligent.

~~~
izacus
Microsoft enforced that and OEMs decided they'd rather build Android phones
than Windows Phone ones. The rest is history.

~~~
pjmlp
I think having an OS available for free was more relevant.

~~~
MichaelGG
Yeah, it's not like Samsung can go make iOS phones. And I highly doubt any of
these hardware OEMs could possibly pull off a software project that doesn't
suck, let alone a whole OS and dev ecosystem.

~~~
izacus
Samsung already releases phones running Tizen to have a side bet against
Android. The quality of software is not very important when your only
competitor builds phones that are significantly more expensive.

~~~
pjmlp
Tizen is a joke for app developers, it was already rebooted so many times, no
one serious would spend a second trying to target the platform.

1 - Meego reborn as Tizen

2 - Tizen gets the Bada C++ SDK, with its Symbian C++ like flavour

3 - Enlightment guys join Tizen

4 - C++ SDK gets kicked out and replaced by Enlightment C libraries

5 - Developers complain that Tizen 2.3 drops C++ and is a C only experience

6 - Samsung announces support for .NET Core as high level native Tizen tooling

Really, what SDK are they going to release next?!

~~~
realharo
There was also a period of only allowing "HTML5 apps" (during the jQuery era
no less) if I remember it correctly.

~~~
pjmlp
It is still the case when targeting Tizen TV devices.

------
huangc10
As an iOS developer, I had to decide between investing more time in Swift or
React-Native. I chose React-Native simply because I thought it will allow me
to broaden my mobile development experience and maybe one day stretch to even
the Android platform. Furthermore, it improved my javascript skills in general
and allowed me to create React web apps as well. I think it is the right
choice thus far. Anyone else have similar experiences?

~~~
RubenSandwich
As someone who was in your shoes last year as I made a job transition into a
lead developer role at a new company. I picked React Native for a small
project over Swift: [https://studio.carnegiemuseums.org/out-loud-
cdc979453ef0#.rh...](https://studio.carnegiemuseums.org/out-loud-
cdc979453ef0#.rh2rkrgsb). It was worth it. Not only because immutable render
functions make view code extremely pleasurable to write, but also because it's
mostly JS and JSX it allowed me to quickly spin up a web developer to work on
this project with me. (About 2-3 weeks.)

Now React Native is not without it's downsides though. You pretty much have to
know the platform underneath if you want to do anything past API calls and
rendering to a list view. (And even that list view does not support the heavy
recycling that iOS manages for you.) For the above project I had to write our
own Bluetooth, Audio and Accessibility Native Modules.

But the speed at which we were able to develop over a native solution was
worth it alone. I highly suggest looking into React Native if your next
project is simple enough.

~~~
Eridrus
> I had to write our own Bluetooth, Audio and Accessibility Native Modules

I hope you open sourced these :)

I was looking at React Native the other day and the impression I got was that
almost every piece that does more than display data from the web needed extra
modules and far from all of them were written already.

~~~
LeoNatan25
This is true. Some great ones exist (like [https://github.com/airbnb/react-
native-maps](https://github.com/airbnb/react-native-maps) and
[https://github.com/wix/react-native-navigation](https://github.com/wix/react-
native-navigation)), but those are few and far between. Most are very
simplistic and only solve very narrow cases. So you end up having to do a lot
of the work yourself, for both platforms. And that is a big chore, as there is
a lot of boilerplate to integrate native components with RN.

Disclaimer: react-native-navigation is developed by Wix, my employer, but I
have not worked on that one.

------
iamleppert
They probably traded a really nice iOS codebase that had been maintained and
improved upon for something that is going to end up with tons of special cases
for when the UI is running on iOS/Android etc and make it incredibly difficult
to test, reason about.

Instead of improving the code on each respective platform, you end up with an
inbred red-headed step child that shares the limitations and thorns of each,
all smushed together.

Now, making a change that once was once limited in scope to a single UI on
Android now has the potential to affect both apps in new and exciting (read:
unpredictable) ways.

I've been down this path before. There's something incredibly satisfying about
reusing code, but there's such a thing as too much of a good thing.

I'd like to see a case study done in a few years once the whiskers have had
some time to accumulate on this codebase.

Steve Jobs knew about the perils of this development methodology which is why
he specifically put his foot down on technologies like Flash -- which (let's
admit it, folks), React Native really has more in common than we'd like to
admit.

~~~
hakanito
I would guess one reason for Instagram to go the RN route is simply easier
hiring.

For every really good iOS/Android developer, there are probably 10 really good
web developers that easily can pick up RN. As a web developer myself, it's a
full time job to keep up with the JS ecosystem alone.

I tried learning ObjC a few years back but gave up because of limited time,
weird syntax and very slow feedback loop.

Now I am stoked that I can finally build native apps with the web tech I spent
so much time learning, and I don't think I'm alone in that regard.

~~~
weixiyen
Instagram is the last group that would have problems hiring iOS and Android
developers. I'm almost certain that's not the reason for the switch to React
Native.

The main reason to switch is that the user cannot tell the difference for
their use case, and they get to iterate faster.

~~~
Bahamut
I'm not sure if this is still the case, but I remember hearing a year and a
half ago or so that the Instagram team was still pretty small then. FB is
pretty lean in terms of number of frontend devs - at that time I remember
being told the number was ~250 or so, which has probably grown since then.

------
artursapek
I opened Instagram the other day and saw a grey error message show up across
the top of the app... it said something about a React error. I didn't get to
read it well because it quickly disappeared. I thought I was tripping. Good to
know I wasn't.

~~~
dcgoss
Same here. Something about a debug error.

~~~
pacomerh
That is the one thing that is difficult in React Native, getting rid of those
debug errors. Sometimes they don't make enough sense to know what they are.
But we google are way out of them. Sometimes they're related to a
compatibility issues, and communication issues between Objective C and RN.

~~~
spicyj
I would not expect any of these error messages to show up in a production
build unless it was misconfigured (which it unfortunately sounds like the
Instagram build was based on these reports).

------
wmblaettler
The careers link posted in the footnote errors when loading:
[https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c5...](https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c57N8Xi13ihf6dqJh6FoNsgrYMTVn7YWz-
VEHqIRY&u=https%3A%2F%2Fwww.instagram.com%2Fabout%2Fjobs%2F&h=8AQFXdAKr&s=1)

"Sorry, something went wrong. We're working on it and we'll get it fixed as
soon as we can."

Based on the URL, is this actually some internal FB link tracking redirect?
You probably simply want direct URL:
[https://www.instagram.com/about/jobs](https://www.instagram.com/about/jobs)

~~~
martin_bigio
Oops, that was an internal link - fixing now.

------
LeoNatan25
Please speak, if you can, on the mental toll the move to web ecosystem has
taken on your native developers that have until now developed on respective
native ecosystems. In particularly, I refer to having to work in JS, having to
install tens if not hundreds if not thousands npm dependencies in order to do
the most routine tasks, having to restart packager and clear cache every few
runs, etc.

~~~
martin_bigio
Packager has gotten pretty stable lately, you shouldn't need to restart it
anymore. In regards npm modules, you only need to do so when upgrading
dependencies which doesn't happen that often.

We also use yarn, an npm client FB built from the ground up to removes some of
the pain with npm's one:
[https://code.facebook.com/posts/1840075619545360](https://code.facebook.com/posts/1840075619545360)

------
ryandrake
Call me old-fashioned, but I thought the Android/iOS code sharing nut was
cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java
(Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as
well.

~~~
erichocean
That's how we do it as well. Bonus: you can test your business logic without
having to run it on a phone.

I'm shocked more people don't do this—I guess they don't know C++?

~~~
LeoNatan25
Web developers are a dime a dozen - very low barrier to entry, both from
learning standpoint, and quality standpoint (sadly). C++ developers - a lot
less. C++ developers cost more. Native developers who are also willing to
learn C++ are also expensive. My cynical view is that with RN, startups are
just able to hire a few web developers instead of having to hire native
developers, so it's a lot cheaper.

------
thecopy
I'm getting tired of having to allow scripts to even get to see the images.
Why dont they use <img> tags?

~~~
xyzzy4
There's a lot of software developers who like to over-engineer things. Some
are probably working at Medium.

~~~
intoverflow2
At times I feel filling the building with just a few too many smart people can
sometimes cause a regression on experience as things are over engineered and
too many people struggle to find smarter solutions to solved problems.

Take Google Maps for example, the old tile based version is blazing fast and
uses almost no CPU. "Modern" version of Maps makes my MacBook Pro fans turn on
almost straight away, chugs and chokes when dragging and although the zoom
motion is clearer the actual data display isn't any better.

------
martin_bigio
@martinbigio here in case anyone has questions

~~~
k-mcgrady
Probably OT but a bug that's been driving me crazy for a while now. When I
open Instagram it reloads the feed every time as if the app had been purged
from memory. This means if I accidentally close the app and reopen it my
scroll position is lost and thanks to the sort algorithm the feed order has
changed and I can't get back to where I was.

~~~
alexpersian
See this every time. Also on iOS if you have the app open, lock the phone, and
then unlock you will be at the home screen. Almost as if the app ran out of
memory or crashed in the background.

Side effects of RN?

------
lewisl9029
Has anyone tried using the React Native plugin for Windows [1] in a non-
trivial app yet? I'd love to hear what experiences people have had with it,
and if there's anything to watch out for coming from the RN Android/iOS camps.
Any open source apps that makes use of React Native for Windows that you can
point me to would be super helpful as well.

[1] [https://github.com/ReactWindows/react-native-
windows](https://github.com/ReactWindows/react-native-windows)

~~~
mnkypete
I mean, the Instagram App is also available on Windows, with almost all
features as the iOS/Android counterparts. So I'm not sure, maybe they are
already using that as well?

------
therealmarv
Great engineering. Instagram always runs snappy and also with low bandwidth
(>1Mbit/s). Meanwhile Snapchat does not even know how to download first
clicked story video first.

~~~
dingdongding
Though Instagram stories are pretty slow to load.

------
antoniuschan99
My project (the weather sensor) is using React Native for the Mobile end. I
would still like to work on a professional project to really see how well or
bad RN is in an enterprise type project. Having used Titanium Appcelerator on
a personal project, I find RN much better than Titanium. I assume it's much
better than Xamarin as well.

I think learning RN is a good bet because, it is coming from Facebook. I'm not
sure if people remember, but FB on mobile was originally built using Webviews
and had notoriously bad reviews because it was slow and laggy. It's because of
this lesson that they are in a good position to create a competent platform.

I also think as web developers, we should try to understand more of the
tooling/language in one of the mobile platforms of our choice.

------
ryancouto
Did this change occur recently? I've noticed in the past 3-4 months Instagram
has become a lot slower. To be fair, it's started to gain some speed in the
past month, but I'd be interested to see how this increase in latency
coincided with the migration to React Native.

~~~
spicyj
When teams at Facebook roll out features or rewrites like this, they almost
always monitor performance metrics so I'm comfortable claiming that React
Native is unlikely to be responsible for slowness you've seen recently.

------
DenisM
So I see they have a lot of code reuse between RN iOS and RN Android.

How much, if any, code reuse can there be between React Native and React
(proper)?

~~~
weixiyen
You can't re-use the UI portion but all the business logic, API calls, stores,
socket connections, etc...

For Sleeperbot it's 50% code-sharing between desktop / mobile, and then 95%
between iOS & Android.

~~~
DenisM
Thank you!

------
beeswax
Thanks for sharing!

I'm currently leading the (soft) transition of a two-platform, not-so-much-
shared-code code base (ObjC, Java, Swift, C++) to React Native.

We hit some snags early on (mostly wrt tooling; also prepare to alter your
mind set) but as the article states RN yields an astonishing amount of code
reuse between platforms as well as heavily reduced turnaround times.

It’s way too early for conclusions/doing a post mortem for our project at this
time.

Nonetheless I’d say we’re able to iterate faster by an order of magnitude and
the added value of discussing features and domain logic/behavior for both
platforms at the same time while enabling UX/UI to get results/feedback faster
is a huge win.

That said, I’m really looking forward to the challenges that lie ahead (i18n,
RTL quirks, proper unit/feature/integration testing scenarios, non-trivial
native bridging, …)

------
DenisM
One thing that draws me to RN is over-the-air code updates on iOS.

Are there any other ways of achieving the same result?

------
jakebasile
React and React Native are pretty great pieces of tech, hopefully the
ClojureScript story for them continues to improve. When I need to make a
mobile app again I can't think of a reason I'd write it in Java/Swift.

~~~
raspasov
The story is already quite good (having shipped a production app myself and
maintained it for 6+ months). Checkout re-natal for a good template to start.

~~~
jakebasile
I had found that earlier, I wasn't sure if it was ready enough for production
use. Glad to hear it worked for you!

------
kumarm
I don't think ReactNative has a reason to exist other than Facebook wanting to
own Platform (Which they might abandon just like Parse).

Good Read:
[https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding...](https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding_react_native/dd1wuzn/)

~~~
iLoch
I think you might be confusing Facebook with Google.

Ask any app developer that's used React Native or any web developer that's had
to create a native app if it has a reason to exist.

Facebook has hundreds or thousands of React developers that - before React
Native - could only develop for web. Now they can move their web developers to
their native apps almost seamlessly.

~~~
sidlls
And that's a good thing? I'm being serious here. The web ranks among the
crappiest user experience I have with software I use today. And when I speak
with colleagues who do the web development at the company I work for they seem
far from happy with their development environments and process. It's like the
presentation, in which MB of JavaScript are required to render a few
paragraphs of text with a side bar or drop-down menu, went to the development
environment where thousands of dependencies are required to produce "hello
world."

The last thing I want is to see yet more traveling down the path of "web app"
style development for my phone's apps.

------
greenyouse
I'm curious what you guys think of PWAs vs React Native? Is there a clear
advantages of one over the other?

------
jz10
For my fellow vue.js enthusiasts, check out
[https://github.com/alibaba/weex](https://github.com/alibaba/weex) for
compiling "vue-like" syntax to native apps

------
SilverWhiskey
Argh, now I see why I can't change anything on the Push Notifications settings
page. Nice experiment, Instagram, but could you please fix it and let me
disable all notifications within the app, not iphone settings?

~~~
martin_bigio
what's the problem? If it's a generic error message that's s server-side issue
unrelated to RN the team is working on fixing.

------
dvcrn
I love react native but only in combination with clojurescript as javascript
replacement. Speaking of high-performance, is anyone here who has some
insights how performance would change when swapping JS with cljs?

------
joe_momma
React Native is becoming the Wordpress of mobile apps.

~~~
kgin
Not sure that's the best analogy.

~~~
joe_momma
Not sure you get it...

------
redtree
This is great news for Enterprises as well, as most have many internal apps
that need to be built for different platforms.

------
gigatexal
This is probably stupid but does react native compile down to the running
environment? Code in react and then build/compile against iOS SDKs?

~~~
martin_bigio
JS code run on JSC, bridge modules are implemented on objc/java

------
Shooogur
Very cool!

------
ClayFerguson
The dirty little secret about React is that it tries to 'reinvent' the DOM
tree, and Web Components will be out soon making it all obsolete. Why not just
move to Web Components NOW, and not have to rewrite your view logic in 3 or 4
years. Polymer wins easily. React got a head start, sure, but the W3C
standards and native browser support for WebComponents makes React redundant
and unnecessary, in the very near future.

~~~
ec109685
ReactNative doesn't even have the concept of a DOM, so how can that be its
dirty secret?

~~~
LeoNatan25
React Native has the native view hierarchy as its DOM, and it also has a
"shadow" view hierarchy, which is very similar to the concept of shadow DOM.

[https://github.com/facebook/react-
native/blob/master/React/V...](https://github.com/facebook/react-
native/blob/master/React/Views/RCTShadowView.h)

------
thebouv
I really want to look at React Native, but every time I pull up my Facebook
app on my iPhone 6, it can take upwards of 30 seconds before the interface is
useable.

That's on a very fast connection.

So to me the FB app is so slow, it makes me hesitant to give React Native much
more thought as you'd figure the FB app would be THE showcase app for it.

Maybe I'm the only one?

~~~
dvcrn
Someone correct me if I'm wrong but AFAIK the Facebook app isn't really using
react native yet, just in very small parts (event dashboard). The rest is
still plain old swift and objc.

~~~
thebouv
It's listed in the React Native showcase:

[https://facebook.github.io/react-
native/showcase.html](https://facebook.github.io/react-native/showcase.html)

