
React Native at Airbnb - msoad
https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
======
kbyatnal
"While debugging, React Native attaches to a Chrome Developer Tools instance.
This is great because it is a powerful debugger. However, once the debugger is
attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of
the time. However, in one instance, we got bit when toLocaleString worked on
iOS and but only worked on Android while debugging. It turns out that the
Android JSC doesn’t include it and it was silently failing unless you were
debugging in which case it was using V8 which does."

Wow, I can't imagine how frustrating this must have been to debug.

~~~
rpeden
I ran into a fun one like that many years ago in IE. The JavaScript I had
written was failing, but when I opened up the devtools to debug it, it worked.

It turned out that in that version of IE, the console object only existed when
the devtools were open. So a stray console.log call was causing an exception
because console was undefined. But when I opened the devtools to see what was
going on, console existed and so everything ran just fine.

I suppose that's the kind of error that only bites you once. When you know
about it, you tend to never make that mistake again. But that first time you
run into it can cause a painful few hours of head scratching and attempted
debugging.

Funnily enough, I ran into a React Native error like the one described in the
article, where something worked only while debugging. My previous experience
with the heisenbug in IE led me to immediately dig into what was different in
RN with the devtools open vs without them. So in a way, those hours I wasted
in IE back in 2010 prevented me from potentially wasting hours debugging RN in
2017.

~~~
kaixi
Programming doesn't change that much after all.

gRPC is just a modern SOAP. There, I said it.

~~~
rpeden
Modern SOAP doesn't sound too bad to me! But then again, I never found SOAP to
be all that bad.

I might have been lucky, though. Every time I had to use SOAP, it was just a
matter of auto generating a client interface in whatever language I happened
to be working in and then proceeding from there. I suppose not everyone was so
fortunate.

~~~
zxcmx
I found that autogeneration rarely worked well unless the client and the
server were using the same tooling.

The monstrous flexibility of xml and soap meant that in practice every soap
server interface I had to consume had _some_ quirk or incompatibility with the
client I was trying to use.

The worst offender was security extensions.

------
pjmlp
Yet another company discovers what many of us did ages ago with multi-platform
frameworks.

Additional layers not supported by platform owners, mean extra debugging
efforts tracking down which layer is responsible, catching up with native SDK
features, need to be an expert at both layers, lack of integration with native
debugging tools...

But business always wants the Ferrari solution at the cost of a Fiat panda.

~~~
RussianCow
While I don't disagree with your premise, "need to be an expert at both
layers" is absolutely still true if you build your app natively for each
platform (more so, even). At least with a common platform, if nothing else,
you can share quite a bit of code, and that alone might make it worth the
extra layers.

~~~
LeoNatan25
And “developing” in RN requires you to be an expert in three fields: iOS,
Android and the RN layer, which is often buggy. How is that better?

~~~
dwild
If you are already using React for the web (which I would believe is the
biggest reason to use React Native), then the RN layer is pretty much already
taken care of in term of expertise.

For the iOS and Android side, that's a constant between the two possibilities.

It's better because now your iOS and Android experts can concentrate much more
on what they do best and your React experts can keep working on your UI like
they always did.

~~~
LeoNatan25
React “experts” are not mobile experts, and often lack (and refuse to learn)
basic mobile principles such as platform standards and accessibility.

------
vinceyuan
Great article. I started iOS programming in late 2009 and had solid experience
of native mobile programming (iOS/Android) and web frontend/backend
(RoR/Node.js/React/Go) before I started to use React Native in late 2016. I
totally agree with the auther on what work well and what don't work well about
React Native. Sad to see Airbnb sunsetting React Native.

In my opinion, 2 of the reasons Airbnb had more and more issues with React
Native are:

1\. They don’t adopt type checking for JavaScript.

“We explored adopting flow but cryptic error messages led to a frustrating
developer experience. We also explored TypeScript but integrating it into our
existing infrastructure such as babel and metro bundler proved to be
problematic.”

“A side-effect of JavaScript being untyped is that refactoring was extremely
difficult and error-prone.”

This is absolutely not just "a side-effect". In a real project, many
developers modify the same code base, and the interfaces (Classes, function
paramenters, props, etc) are changed frequently. I think type checking system,
e.g. Flow, is a must for writing JavaScript code for either backend or
frontend. My team is using Flow, and I ask my team members to adopt type
checking as much as possible. When I see something like this funcA(a, b), I
always ask the developer to change it to funcA(a: TypeA, b: TypeB): TypeC. It
is really very helpful, especailly when we need to change code.

2\. They don’t ask engineers to keep most code in JavaScript.

“Often times, it is not clear whether code should be written in native or
React Native. Naturally, an engineer will often choose the platform that they
are more comfortable which can lead to unideal code.”

All logic and UI should be written in JavaScript. Native code should only be
used when we cannot do in JavaScript or the performance is very bad.

When I am using React Native, I do miss the simplicity of writing and
debugging native code. But when you need to support both iOS and Android, it's
great to just keep one code base in JavaScript. Again, espeically when you
need to change the code frequently, you don't need to do the some thing twice.
(One for iOS, the other for Android.)

~~~
vinceyuan
Typo. It should be "you don't need to do the same thing twice"

------
fs111
As a user of AirBnb I would be so happy if they just stopped updating the app.
They are making it worse and worse. When I travel and I arrive at an airport,
I do not need spiffy animations and "fun things to do" in the city I am in, I
need a way to quickly find the address of the place or a way to message the
host. Stop with all this experience stuff and give me the facts I need right
now

~~~
spiderfarmer
Hey, they hired so many people. You can't let them just sit there doing
nothing.

~~~
forgot-my-pw
Soon to be released: Airbnb Lite

------
crabl
Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC
of app code, 40K LoC of infra, and 220 "screens". We've got an app with about
the same "dimensions", developed in a similar timeframe, with some very
complex financial business logic and 2 developers working on it... what on
Earth do their devs spend their time on? Is their engineering organization
really _that_ inefficient?

~~~
apahwa
"For reference, we have about 10x the amount of code and 4x the number of
screens on each native platform". So the amount of code and the complexity is
substantially more difficult than you describe. You probably also don't have
as rigorous AB testing, logging, internationalization, contributions to open
source, etc.

~~~
Tade0
I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex
at times)JS and there were four of us working on the LTS(4.x) - we were
_somewhat_ understaffed, but not "we need a hundred devs for this"
understaffed.

On the other hand last year I spent two weeks working on a project for which I
was borrowed from another one - they had a total of 120k LOC(Java,
TypeScript), twenty people and at least the front-end was a dumpster fire.

I guess people don't scale well.

~~~
hokkos
I guess quality is a factor, because CKEditor 4.X might have a lot of lines
but it is one of the worst library I had the displeasure to use.

~~~
bigmanwalter
I use it extensively in my current project and it is a joy. Different strokes
for different folks.

------
onedev
Others have been coming out and talking about similar experiences with React
Native. This thread made the rounds on Twitter and Medium fairly recently:

[https://twitter.com/sandofsky/status/1002634185566236679](https://twitter.com/sandofsky/status/1002634185566236679)

[https://twitter.com/VivekxK/status/1002694526467653632](https://twitter.com/VivekxK/status/1002694526467653632)

~~~
eysquared
The common thread I see is that mixing native and react-native is hard. Doing
so while working across organizations that may or may not use react-native is
doubly so. Sometimes this boils down to the technology, knowledge, and the
engineering systems needed to support both but I've also found native
developers tend to strongly dislike react-native and lobby against whenever
they can.

For me, I'm using it to successfully build mobile apps for a large tech
company with very limited mobile developer resources. We've been able to ship
Android and iOS apps in a couple months using 100% react-native. I attribute a
lot of this to knowing the limitations of the platform and designing a cross-
platform experience from the start rather than trying to get the "best of
native" out of abstracted JavaScript.

I'll always argue that native is the way to go for the best user experience
but react-native is a great tool to have in the mobile space.

~~~
danabramov
_> The common thread I see is that mixing native and react-native is hard._

We've experienced some of the difficulties in this area at Facebook as well.
If you're curious, making native <-> JS integration more seamless is a big
motivation for the ongoing architectural revamp that we've recently posted
about: [http://facebook.github.io/react-
native/blog/2018/06/14/state...](http://facebook.github.io/react-
native/blog/2018/06/14/state-of-react-native-2018.html)

It's a shame we weren't fast enough to help Airbnb in these areas, but the
native interop will get better when the revamp is finished.

~~~
eysquared
I'm excited about the proposed changes and think they are a step in the right
direction, but I also worry that they will add more fuel to the fire that
react-native as a platform is a constant moving target.

You obviously have much more insight into what the re-architecture will entail
than I do but I've heard a lot of worry around that post with regards to
backwards compatibility of third party libraries and in-house native
components.

~~~
danabramov
To provide some extra context on this: at FB, we can't ship any RN update (or
really, any RN _commit_ ) without updating our own apps for it. No product
teams at FB are going to agree to rewrite their code just because an
infrastructure team came up with a new way to do something.

The reason updates are easier at FB mostly has to do with atomicity of
commits. Because FB uses RN from master (and in practice all code lives in the
same monorepo), codemods can be applied to products together with the
corresponding infrastructure changes. Since the upgrades have a commit
granularity instead of the monthly stable releases we cut in open source,
there are no big delays between a regression being introduced and fixed for FB
products. This discrepancy is unfortunate, but I don’t really see a way around
it for an actively developed library--which might be your point.

Undoubtedly RN is in active development, and being a moving target, it's
easier for FB teams to “follow” it. Still, large backwards-incompatible
changes are just as infeasible for us as for everybody else without either an
automated codemod or an opt-in strategy.

~~~
guelo
Wow thanks, that explains a lot. So Facebook basically treats RN as an
internal library, a single commit can change the framework API and the
implementation at the same time so the constant API churn is not a problem.

~~~
danabramov
I'm talking about mostly mechanical changes (think find-and-replace or
slightly more involved). Those are easier to do because they can be done on
both RN _and_ products at once.

This doesn't work for any larger changes because nobody is able to rewrite a
ton of files by hand just to change some API. So this is why we can't make big
changes to the API without a gradual adoption strategy, even internally.

------
benawad
"Redux is notorious for its boilerplate and has a relatively difficult
learning curve. We provided generators for some common templates but it was
still one of the most challenging pieces and source of confusion while working
with React Native."

Interesting to see even Airbnb struggles with Redux

~~~
acemarke
As a Redux maintainer, I'd be really interested to know what approaches they
used, and what sorts of difficulties they had.

(I'll throw out my obligatory comment that you are always welcome to use as
much or as little abstraction as you want on top of Redux, and there's plenty
of options available to trim down "boilerplate" depending on your situation.)

~~~
andrewstuart
"Requires boilerplate" will forever be a criticism of Redux unless redux
itself takes the (radical) decision to get rid of the boilerplate.

Just saying "well you don't need to use it" means that Redux maintains all
that crust and cruft of boilerplate which remains a huge cognitive impact not
only on beginners but also possibly experienced Redux users.

Redux is magnificent, but it should take a lesson from create-react-app which
did the job of getting rid of all the crap that webpack and babel disastrously
imposed on all JavaScript developers with their "maximum config" approach as
opposed to zero config.

The message to JavaScript library and tools developers is "get rid of your
config or some other tool will come along and do it for you". Redux's
boilerplate is just config. If you apply every brain cell you have to the task
of getting rid of boilerplate, what would Redux be left with? That's what it
should be.

I think the success of VueJS can be laid squarely at the feet of the
complexity of the ReactJS ecosystem - not even necessarily React itself. Every
part of the larger React ecosystem needs to reduce the cognitive load it
imposes and the primary task there is getting rid of
configuration/boilerplate.

My theory is that "all software that CAN BE more simple is replaced by some
other good enough solution that IS more simple". Thus VueJS, which whilst I
wouldn't use it, is certainly simpler for beginners to grasp.

~~~
acemarke
Part of the issue is that _everyone_ has a different definition of what
"boilerplate" means.

So, legit question: what do _you_ mean by that term? Use of actions? Action
creators? `connect()`? Immutable update logic in a reducer? Store setup?

I honestly get frustrated that people keep throwing around that term, but few
people seem to point to a specific _thing_ that can be improved. (People also
don't seem to understand the context that Redux came from and the intent
behind its original design, something that I tried to capture in an extended
blog post a while back [0]).

Early last year, I filed an issue asking for discussion of ways we can improve
the learning / getting started experience, and resolve some of these
"boilerplate" complaints [1]. There were a bunch of comments and some decent
ideas, but I already have a lot on my plate, and no one from the community
really stepped up to help push any of the ideas forward.

I do have a small "redux-starter-kit" lib [2] prototype that I've put together
as a tool that can help simplify the store setup process and reducer logic.
Again, though, I haven't had time to do much more with it myself since I first
threw it together.

I am _always_ open to legit suggestions on ways we can improve the docs or
find ways to make using Redux easier. Unfortunately, it seems like very few
people are interested in actually getting in touch with us and offering
assistance in doing so.

[0] [https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
ta...](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-1/)

[1]
[https://github.com/reactjs/redux/issues/2295](https://github.com/reactjs/redux/issues/2295)

[2] [https://github.com/markerikson/redux-starter-
kit](https://github.com/markerikson/redux-starter-kit)

~~~
andrewstuart
For me it is specifically this.

Here is a class:

    
    
      import React from 'react'
      
      export default class class ChooseFontLevel1 extends React.Component {
      
        constructor(props) {
          super(props)
        }
      
        render = () => <span>foo</span>
      }
    

And here is the (almost) same class, with the boilerplate required to use
Redux:

    
    
      import React from 'react'
      import {connect} from 'react-redux'
      
      class ChooseFontLevel1 extends React.Component {
      
        constructor(props) {
          super(props)
        }
      
        render = () => <span>foo</span>
      }
      
      
      function mapStateToProps(store, ownProps) {
      
        return {
          fontPreviewsCache: get(store, `fontPreviewsCache`),
        }
      }
      
      function mapDispatchToProps(dispatch) {
        return {
          onTodoClick: id => {
            dispatch(toggleTodo(id))
          }
        }
      }
      
      export default connect(mapStateToProps, mapDispatchToProps)(ChooseFontLevel1)
    
    

To use Redux I need to entirely restructure my code.

And if the comment is "You don't need all that stuff", then why is it an
option at all?

Also mapStateToProps is poorly named and confusing because it isn't talking
about anything to do with ReactJS component state, although it's a reasonable
assumption, it's talking about the Redux state... there's a bag of confusion
for you and enough to make a beginners head spin because their head was
already spinning about what ReactJS state is.

I'd also suggest that Redux has made a rod for its own back by calling "the
thing that gets data out" as "reducers", instead of something like "getters".
"Reducers".... argh we're now in computer science land and not the land of the
practical programmer. A reducer, what is that? Beginners certainly don't know
and you have to learn and become experienced with Redux to come to understand
that in fact a Reducer is

Equally, cognitive load would have been reduced if actions were named
"setters" or something familiar and similar to the actual functionality.

Redux itself isn't that hard once you understand it, but it's put up big
cognitive barriers around itself so that you need to be an expert to
eventually discover that you don;t need to be an expert.

~~~
acemarke
Well, the `mapDispatch` example can certainly be simplified. `connect`
supports an "object shorthand" \- just pass an object full of action creators
as the second argument, and they'll all be bound up and passed in as props.
So, your `mapDispatch` example can just be:

    
    
        const actions = {onTodoClick : toggleTodo};
    
        export default connect(mapState, actions)(ChooseFontLevel1);
    
    

Other than that... there's 1 import line for `connect`, 1 function call to
`connect`, and the `mapState` function.

Is that truly too much to write? Also, how does that qualify as "entirely
restructuring your code"? Your component is still the same - it's getting data
as props. It's just now getting them from a component that was generated by
`connect`.

The alternative is to write the store subscription code yourself, by hand, in
every component that needs to access the store. I've got some slides at
[https://blog.isquaredsoftware.com/presentations/workshops/re...](https://blog.isquaredsoftware.com/presentations/workshops/redux-
fundamentals/ui-layer.html#/) that show what that would look like, and THAT
would truly become tedious and painful.

The point of `connect` is to abstract out the process of subscribing to the
store, extracting the data your component needs, and only re-rendering your
real component when that data changes.

As for the naming of `mapState`: the word "state", in general, means "data
that represents what's going on in my application". So, there's the generic
aspect of "state", there's "state that is being stored in my React component",
and there's "state that is being kept inside my Redux store". Those are all
valid uses of the word "state" (and especially given that the Redux core is
entirely independent of React).

The term "action" comes from its original design as an implementation of the
Flux architecture (which is part of my point of people not being familiar with
where it came from). "Reducers" comes from the `someArray.reduce()` method.

(Also, note that in both of your examples, the constructor isn't actually
needed because you're not doing anything meaningful in there, and your
`mapState` example isn't making use of the `ownProps` argument and therefore
shouldn't declare it for performance reasons.)

~~~
andrewstuart
Easy for you (and me to some extent) to read what you say and see hey yes it
could be more simple....

What is simple for any Redux-experienced person is a gigantic cognitive cliff
for people who are not experts. I can still remember trying to learn ReactJS
and Redux and bailing out on Redux while I tried to make sense of mapping
dispatch to props. Redux should not be losing users at that point.

Your earlier post expressed frustration at not being able to get people to be
specific about what boilerplate is.... well this is it (or my definition
anyway).

IMO, ideally Redux would be nothing more than an object that I instantiate and
then call methods and properties on - including defining my reducers and
actions. A single object for Redux leaves the question of how to ensure that
changes to the Redux store result in a props refresh being pushed down through
the component hierarchy, but surely the big brains on the ReactJS project can
come up with some other way to handle that behind the scenes rather than me
needing to change my code structure.

And may I say I love your work and I'm a big fan of Redux!

Although if I found something that operated like I say - a single object to be
instantiated and driven via methods and properties with total immutability,
with changes resulting in a props refresh on update, then I'd switch.

~~~
acemarke
Unfortunately, the library you describe wouldn't be Redux at all. Part of the
core point of Redux is to separate out the act of describing some event or
update that needs to occur, from the process of applying that update. That's
what makes time-travel debugging possible, and it allows middleware to modify
the actions that are passing through the store. In all honesty, if you want
objects with methods, MobX is what you're looking for.

Not quite sure what that "single object" sentence is trying to say, but that
also sorta sounds like MobX's wrapping up of components with `observe()`
(which ultimately does the same kind of thing `connect` is doing, just in a
rather different way).

(Also, fwiw, Redux is completely separate from the React team. Dan Abramov and
Andrew Clark, the creators of Redux, _do_ work on React at Facebook now, but
Redux is not a Facebook project, and Dan and Andrew are no longer active
maintainers. We talk with them a lot, and they obviously have a vested
interest in Redux, but it's separate.)

And thanks, appreciate the compliment.

------
hitekker
>Due to a variety of technical and organizational issues, we will be
sunsetting React Native and putting all of our efforts into making native
amazing.

Buried lede. Why not just say it outright?

~~~
mychael
Airbnb has managed to over-engineer a Medium blog post.

------
rboyd
Very good write-up, thanks for posting.

Some of the frustrations definitely hit home. I think for small teams and
indies React Native is an awesome piece of technology that can enable them to
target both platforms where it would be nearly impossible otherwise. I can
understand how orchestrating the work of a huge team could introduce new
issues though.

It would be interesting to know why some of the infra layers that the article
mentions (i18n, networking) were behind bridge when they seem like prime
candidates for js implementation.

What I'd really like to know though is how other teams are managing the design
pipeline (getting from psd/sketchapp to code without hand coding flexbox
styles). We've looked at some tools like supernova.studio and BuilderX, and
while showing promise these seem like they have a long road ahead.

~~~
jongold
we have a new tool that we're trying internally to design cross-platform
components - [https://github.com/airbnb/Lona](https://github.com/airbnb/Lona)

pretty early still, but the idea is that short-term it generates assets that
fit into our existing Figma / Sketch product design workflows for consumption.
having a cross-platform source of truth for _components_ is higher impact than
outputting their _consumption_. this was mostly the reason we first did the
things we wrote about here - they laid the groundwork for Lona and a more
component-centric design process. [https://airbnb.design/painting-with-
code/](https://airbnb.design/painting-with-code/)
[https://airbnb.design/sketching-interfaces/](https://airbnb.design/sketching-
interfaces/) [https://airbnb.design/the-evolution-of-
tools/](https://airbnb.design/the-evolution-of-tools/)

~~~
rboyd
Thanks very much. I'll take a look at Lona.

A couple of days after I posted that I started thinking about whether it would
be possible to develop a sketch plugin to render react components onto
artboards, then I googled my way into your react-sketchapp and a talk you
delivered at ZEIT. You guys are doing some really cool and useful work.
Thanks!

------
xenadu02
I’ve never seen anyone do a battery impact analysis of React Native. I wonder
why?

Person sally, I don’t want to use products where the developer prioritizes
their problems over my experiencs but YMMV. Some will argue that an Electron
dumpster fire is superior to nothing. I consider that debatable.

~~~
bengotow
Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is
fairly fast, business logic doesn't take that long to run (100ms vs 200ms,
whatever.), and it all pales in comparison to running GPS or the display for a
few seconds. Unless you're playing a game or running some complex algorithm,
most of your phone's battery goes to the wifi / cell radio and the display.

~~~
maga_2020
I agree with you, that for the same 'business logic', having it JavaScript vs
native, unless you do lots of sorting/copying of data -- will not have battery
impact difference.

However, React itself (not the javascript engine) brings in additional
dimensions, that are somewhat unique to react.

For example, React's (and therefore ReactNative) TextInput control,
essentially (in my understanding) encourages you to update a state variable,
_every single time_ type a letter into that control

(because the values displayed in the control are coming from the state, so the
only way to display the character you typed, is via updating the state).

So that round trip of the character update, to updating the object with state
variable, calling .setState, forcing the re-rendering, will consume more
battery power. In my view

(I know textinput in particular has the 'uncontrolled model').

My point, that the constant 'create new object', update the state with it, and
Re-render -- could be slower (and less battery efficient), than doing may be
something similar (or more efficient) in Native Code.

------
ksec
What is wrong with TurboLink 5? Not Turbolink 3 or previous version, v5 is
very much a total rewrite. Turbolinks 5 allows hybrid Apps that offers most of
the benefits without many of the complexity, it is HTML after all.

It seems there are sites that uses Rails, including AirBnB. But I have yet to
seen a site that uses Turbolink apart from Bassecamp, even Github uses its own
version of pjax rather then Turbolink.

~~~
deedubaya
I use the turbolinks libraries for iOS and android and the experience has been
great.

~~~
ksec
I am just wondering if there are any pitfalls. While not many are writing
about their technical failure of React Native or whatever tech it is. You will
at least know they have changed the stack, or words on the street / twitter
they are retrying new things because old things didn't work etc.

But TurboLinks 5? None, not even a mention or beep. As if no one is using it.
While we are happily using it someone else may be running into issues we
haven't yet doubt with.

It is pretty much like Startup news, I don't want to read about how you
succeed this just once. I want to read about your thousands other failure,
what works, what not, and what you ( Or I could ) learned from it. By stating
your problem, your intended solution, and the results I could make a better
informed decision somewhere down the line. And all the time we got on the
internet is everyone cheer leading mindlessly.

------
msoad
This is a really good write up and I love how they were cautious not to feed
the ongoing fanboyism in for and against React Native folks.

Say what you like but this is a very mature move from a young engineering
organization.

~~~
faitswulff
I have to agree. It was really interesting that they highlighted that nearly
2/3rds of their engineers would use React Native again. I also assumed that
the last part of the blog series was going to be mostly fluff / product
announcements, but their efforts in server side rendered native screens and
drastic reductions in build time are legitimate takeaways from devs who are
used to development cycles at React-Native speeds.

~~~
philipwhiuk
You have to wonder how many of their 100 engineers are going to dislike having
to become iOS/Android devs.

~~~
gpeal
The vast majority of the 100 always have been and are still Android and iOS
devs. React Native never made up more than 10-20% of our mobile engineers and
many of them came from Android or iOS backgrounds.

~~~
heyheyhey
How's FB's RN team reacted to Airbnb's decision to move away from RN?

------
Apocryphon
Really curious as to how Flutter (and Xamarin, NativeScript, Ionic, Vue-based
write-once frameworks, etc.) can overcome the difficulties expressed in this
piece.

~~~
jgalentine007
I've tried pretty hard to get into RN with a few hobby projects and I've given
up. I'm wondering if PWAs are the way forward for the average data driven
mobile app.

~~~
pjmlp
I would say they can be, depends on how they evolve.

On Windows they have access to the native APIs if signed and delivered via the
store, as Microsoft is building on JavaScript development story they
introduced with WinRT.

[https://docs.microsoft.com/en-us/microsoft-
edge/progressive-...](https://docs.microsoft.com/en-us/microsoft-
edge/progressive-web-apps/windows-features?branch=pwa)

------
s17n
tl;dr:

> Due to a variety of technical and organizational issues, we will be
> sunsetting React Native and putting all of our efforts into making native
> amazing.

------
ex3ndr
While i don't have much experience in RN, but have a decade of mobile native
development (android + iOS) and two years of React.

The whole 10 years there were people that think that they can just get "web"
technology and speedup mobile development.

Almost always this companies had no mobile engineers that know how this stuff
works. Developers that know that you just can't listen to scroll and update
animations by sending messages to background js thread. This just completely
wrong on mobile. Most mobile devs spend months to make it fast and easy to
use. There are no way to do this in most cases on RN. AirBNB's app is a
perfect example of this. Trying to deliver "better" experience they completely
kill scrolling performance. Even top level iPhones feels laggy. But yay! We
have animations! AirBNB's app is barely usable on two-year-old androids. This
is just simply wrong, this is not how you can achieve good performance and
nice animations on such small devices. In most cases this is a kind of art and
a lot of testing and tweaking for every device. This can be done by only ONE
talented developer per platform per year. Surely AirBNB has resources. Just
take specific screen and tweak it to hell. On the other side, react and
declarative kind of state is really doesn't work well for non-page oriented
apps. Mapping history of navigation via redux store is just an awful and
useless idea that helps with nothing. Right now there are still no navigation
library.

Every time i tried to start something in React Native i failed since i wasn't
able to apply my skills to make it behave fast there are just no easy way to
do this.

React Native for sure is a good thing, but it's evolution shaped by web devs
that try to reflect their experience from web development, but building a good
mobile app is completely different from web one. For example, there are no
dom, UI manipulation is not slow, navigation between pages and keeping it's
state is not a problem most of the time (there are no real "back" button that
you have to handle somehow). UI frameworks are more mature (while have less
API than HTML).

~~~
jeanregisser
> Right now there are still no navigation library.

React Navigation and React Native Navigation are both viable options with
their own pros and cons. Been using them successfully in different projects.

[https://reactnavigation.org](https://reactnavigation.org)

[https://wix.github.io/react-native-navigation](https://wix.github.io/react-
native-navigation)

~~~
filleduchaos
I think what they meant is that there is no built-in production-ready
navigation library, which is honestly atrocious.

~~~
k__
I never understood the obsession with native navigation libaries.

I built a bunch of apps with JS navs and nobody ever complained...

~~~
mwcampbell
Did you test your app with VoiceOver, the iOS screen reader for blind people?
The difference between non-native and native navigation is particularly
noticeable in that case, unless perhaps you fire a
UIAccessibilityScreenChangedNotification after navigating to a new screen.

That's just the scenario I'm aware of. I haven't done any real projects with
React Native, so there may be other pitfalls.

~~~
LeoNatan25
Of course not. They are a lazy developer that care little about the user
experience.

~~~
mwcampbell
As passionate as I am about accessibility, I try not to use an accusing tone.
There's no way we can know the state of mind, priorities, and constraints of
the developer in question. Even large companies don't have unlimited
resources. So we can't fault developers for looking for ways to do more with
less. We just need to do what we can to make sure developers are informed
about the pitfalls, and plead with them to consider important user experience
factors like accessibility.

------
cpeterso
I haven't used React Native, but I've ready a few posts from people adopting
it. They typically test the waters by writing new app views in React Native
instead of rewriting everything. But how much cognitive overhead is there in
maintaining multiple toolchains (React Native and native and/or web views) and
debugging views in different languages in one app?

~~~
MBCook
I work on an app that is written with a combination of iOS native code, JS,
and server side code.

It’s not easy to debug at all. The problem they mentioned where your stack
traces just end at layer transitions is a real problem. Even if the server
side isn’t involved in the bit you’re working on.

------
buremba
The article doesn't seem to explain specifically why RN didn't work for them
but I believe that the real pain for them is to organize 100 engineers to work
on the same project.

Often they were confused about native vs RN approach and had to write native
libraries and integrated them with RN which requires 3 different teams to
write & test and integrate their code. I can see that if one of the teams is
either slow or run into strange bugs, they will be the bottleneck and slow
down all of them.

From this perspective, similar to why Netflix or other large organization
choose micro-services rather than monoliths, it would be better for Airbnb to
develop 2 different native apps separately rather than having 3 different
teams depending on each other.

------
ajcodez
I remember mid 2017 react native and the upgrade pain distinctly. It took a
full week to set exact versions and run yarn outdated over and over, pull up
the release notes one package at a time, try bumping the version, see if it
breaks, try the next version, no that’s broken, try bumping react, no that
breaks the other one, etc. It was hell.

------
hesarenu
I have come to same conclusion. Have few production apps and an ongoing one in
react native. Dealing with native code has been frustrating, additionally
plugins would not be up to date as well. Going native would be a better
choice.

I would though love react jsx syntax for building native views in
swift/Kotilin.

~~~
ptx
Kotlin doesn't need JSX, as it already has features for building DSLs for such
things[1], allowing you to easily express hierarchical structures as perfectly
normal Kotlin code.

[1] [http://kotlinlang.org/docs/reference/type-safe-
builders.html](http://kotlinlang.org/docs/reference/type-safe-builders.html)

------
smt88
None of the recent articles or HN comment threads about React Native spend
much time evaluating Haxe. I guess it's not that widely used for CRUD apps and
is more popular for games?

Anyway, I'd love to know how it would work for an Airbnb-like org.

~~~
SneakerXZ
It is same with Xamarin. They don't have people that would know these
languages, and they would be passionate about them.

~~~
woolvalley
Xamarin and co suffer from the same dual layer issues that react native has
when I last looked into it.

C# isn't that popular from a silicon valley engineering perspective, since the
first class C# implementation wasn't open source until very recently. Yes mono
has always be OSS, but it has also been a second class citizen too.

~~~
SneakerXZ
Only Xamarin.Forms introduces another layer for you (it is the same concept as
React Native). If you use Xamarin.iOS and Xamarin.Android you call underlying
APIs directly. Although there can be issues with bindings, nothing like you
will face with React Native.

I am aware of why C# isn't popular among startups. It is sad because C# is a
great language that has amazing tooling support. It runs everywhere - Xamarin
for apps, ASP.NET for servers, Blazor for browsers, and it is getting only
better, and I cannot imagine how awesome it would be if other companies helped
Microsoft. But I can only dream.

~~~
woolvalley
Even with Xamarin.Android/iOS I read about unique bugs that resulted in you
needing to be an expert in both layers to understand. And bugs in the wrapper
themselves.

It's a problem with the entire design type, which has been shown throughout
computing history to not work that well.

And why use C# when the Java ecosystem is pretty much the same tooling wise?
C# feels like a 1.2x better Java, which isn't enough.

~~~
pjmlp
As someone that works daily with Java and .NET platforms, C# still has a
better stories around AOT and value types.

Also Sun really bombed their Java Gaming initiative (who remembers that
JavaONE?) with C# becoming the C++'s complement in most studios.

------
dawhizkid
I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18
months testing a new font. A _5_ part series on React Native is again next-
level indulgent.

Why am I not surprised engineers at Airbnb have so little to do than to write
a novel about a framework?

~~~
eugeniub
Yeah nothing weirder than engineers writing about their experiences with
different technologies.

~~~
dawhizkid
A 5 part series. 5!!

------
tannhaeuser
I was looking forward to using RN but I guess I fell victim (again!) to
whishful thinking and the "No silver bullett" fallacy. Come to think of it,
why have we accepted React as the go-to approach to this degree? React doesn't
even make an effort to isolate from HTML and DOM at the conceptual level, and
I'd wager an opinionated framework about "panels", "fields", "field groups"
and events is more representative of what folks typically want to do with
React, rather than manipulating pseudo-markup using JSX however elegant and
neutral.

------
underwater
I feel like we’re missing a lot of the story. Many of the React Native issues
sound painful, but they handwave away a lot of the complexities and drawbacks
of their new architecture.

For example their answer to RN’s one second rebuilds is a custom Android build
configuration that eliminates most of their _5 minute_ builds. They are
proposing a custom server rendering setup and don’t know how to solve the
hardest problems like wiring up events (HTML anyone?).

------
ArtemTrityak
It looks like if you have small team and you want to develop iOS / Android
prototype fast RN is good choice. This case you're looking not for "best user-
experience" but "okay user experience fast".

But for big companies java/kotlin or/and Objective-C/swift native apps will be
more efficient.

------
jaequery
well, its unfortunate that React Native didn't work for them. i think RN is
great solution and direction for mobile in general. sure it can be improved
but at the moment, it is the best we have for cross-platform mobile
development.

~~~
Reedx
Have you tried Flutter? That's looking promising.

~~~
weka
Yeah... but... dart.

~~~
Apocryphon
Is there actually something wrong with the language? If it's a matter of the
issue of having to learn a new language, it's not as if there were many
Objective-C, Swift, or Kotlin developers before mobile.

------
samfisher83
If you are a small startup using react native makes sense. If you are a
billion dollar company why not just have a team for each platform. Or better
yet have have 2 teams for each and let them compete for whose product gets
shipped.

~~~
melvinram
Resources, even at a semi-large company, are finite. Teams have limited head
counts and usually an ever increasing list of asks from Product team. Being
efficient is not optional.

~~~
samfisher83
Lets do a little math. FB has 25k employees. Lets suppose they pay everyone a
million buck. That is 25billion. Their gross profits were 35 billion. They can
afford to have two teams or 3 teams or 4 teams working on the app. I don't
know what Airbnb's numbers are, but I am sure they can afford to have multiple
teams.

~~~
apahwa
I can't tell if you are trolling or not.

------
flamedoge
tldr; [https://medium.com/airbnb-engineering/sunsetting-react-
nativ...](https://medium.com/airbnb-engineering/sunsetting-react-
native-1868ba28e30a)

------
akmarinov
Reading a bit between the lines and keeping in mind that rumour that Facebook
was removing RN from some of their projects…

Could it be true? Does AirBNB see the writing on the wall somehow?

I know that RN is open source and people will continue to support it and
everything will be great, but without Facebook behind it, I wonder how much
traction it’ll have.

~~~
shafte
That rumor was thoroughly debunked (see the discussion in the original HN
thread:
[https://news.ycombinator.com/item?id=17216628](https://news.ycombinator.com/item?id=17216628)).

Please don't repeat and spread false rumors. It cheapens discussion about
legitimate technical choices that organizations make.

------
sandGorgon
Isn't React Native end of lifed at Facebook? The effort is taking the best
principles of React Native and focusing on Litho
[https://fblitho.com](https://fblitho.com) or ComponentKit - the effort to
have a unified framework for both iOS and Android is pretty much abandoned.

I think React Native is in legacy support mode rather than active innovation.

~~~
Steltek
I can't find any reference to that with Google. Mind sharing a link?

~~~
ldavison
This was recently making the rounds, I suspect this is what OP was referring
to:

\-
[https://twitter.com/sandofsky/status/1002637340291018754](https://twitter.com/sandofsky/status/1002637340291018754)

Responses from someone at FB:

\-
[https://twitter.com/sophiebits/status/1003101478427357184](https://twitter.com/sophiebits/status/1003101478427357184)
\-
[https://twitter.com/sandofsky/status/1003104331833532416](https://twitter.com/sandofsky/status/1003104331833532416)

