Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Native at Airbnb

medium.com

Post reply on HN
Print view View original

121–130 of 259 posts

Re: React Native at Airbnb

#121

Post by ascorbic »

danabramov wrote: post #58
eysquared wrote: post #35

Earlier quoted context omitted.

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

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

That's interesting. Do you think there are situations where it would be beneficial for third parties to use RN from master rather than waiting for releases?

Re: React Native at Airbnb

#122

Post by ascorbic »

andrewstuart wrote: post #77
acemarke wrote: post #15

Earlier quoted context omitted.

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

"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-reac…

> Redux is magnificent, but it should take a lesson from create-react-app

...which is ironic, considering the fact that Dan Abramov (co-)created them both.

Re: React Native at Airbnb

#123

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

Re: React Native at Airbnb

#124

Post by hardwaresofton »

pgsandstrom wrote: post #116
crabl wrote: post #110

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?

In my experience, in such a large and "app-centric" company the requirements on the app is changing constantly. Just having a specification that you implement is a hundred times easier than building a constantly evolving target.

Also, once you have a lot of developers, the urge to over-engineer grows exponentially

Re: React Native at Airbnb

#125

Post by mychael »

hardwaresofton wrote: post #124
pgsandstrom wrote: post #116

Earlier quoted context omitted.

In my experience, in such a large and "app-centric" company the requirements on the app is changing constantly. Just having a specification that you implement is a hundred times easier than building a constantly evolving target.

Also, once you have a lot of developers, the urge to over-engineer grows exponentially

Truer words have never been spoken on Hacker News.

Re: React Native at Airbnb

#126

Post by osrec »

hardwaresofton wrote: post #124
pgsandstrom wrote: post #116

Earlier quoted context omitted.

In my experience, in such a large and "app-centric" company the requirements on the app is changing constantly. Just having a specification that you implement is a hundred times easier than building a constantly evolving target.

Also, once you have a lot of developers, the urge to over-engineer grows exponentially

This is often driven by the developers who don't want to appear to be redundant (and who can blame them - everyone wants to hold on to their job!)

Re: React Native at Airbnb

#127

Post by mychael »

hitekker wrote: post #19

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

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

Re: React Native at Airbnb

#128

Post by ascorbic »

mephitix wrote: post #66
eysquared wrote: post #22

Earlier quoted context omitted.

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

I invested a lot into a full React webapp - it would be great to share some of that code with mobile apps. I have an iOS background but was intending to make a RN app so that I could share the bulk of the React webapp code and get Android support as well. I have separation of container components and presentational SFCs so I’m thinking I could easily re-implement UI layers in RN if I wanted to without sacrificing the…

Just use RN. It works great for sharing non-UI code.

Re: React Native at Airbnb

#129

Post by 101km »

crabl wrote: post #110

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?

My pet theory is that valuation is in part derived from engineer head count.

Please note that this isn't a "I could build twitter in a weekend, why do they even have so many people" comment. I am not privy to the scope of work inside of AirBnB and can't really comment whether a large amount of inefficiency exists - but if it does, perhaps this is a plausible explanation as to how that can be.

For an earlier stage company some mental gymnastics can justify the statement that in the event the startup doesn't become a unicorn 100 engineers are still "worth $100m" to big corporate buyers as a sort of big acquihire. This provides a hedge against failure.

It also provides arguably necessary redundancy during a volatile growth stage. A higher bus factor if you will. https://en.wikipedia.org/wiki/Bus_factor

And so a slightly inflated head count early on based on the above principals ensures that bureaucracy, having reached critical mass, keeps on expanding.

At the present point, there's no plausible scenario for 100 to be reduced to 25 when the company is growing and doing well.

If AirBnB suffers a calamity and its network effects somehow start disintegrating, holding on to these people could ultimately increase the sale price - the brand would have suffered, the apartment inventory is reduced, but you're still left with IP and engineers to hawk.

In the event there are no buyers you could significantly stretch out the runway by multiple rounds of layoffs from this group, claim a successful turn around with the fat trimmed, and raise a new round of financing.

Re: React Native at Airbnb

#130

Post by ptx »

hesarenu wrote: post #101

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.

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

Post reply on HN