Live data from Hacker News

React Native at Airbnb

medium.com

151–160 of 259 posts

Re: React Native at Airbnb

#151
post #4

"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

A big contributor to the difficult learning curve in Redux is the very poor naming of things. It's off the charts unintuitive, especially if you're an experienced programmer. I imagine their thought process went like this: Types: People like strongly typed languages, maybe if we call our events "types", they will like Redux more? Reducers: Switch statements are so boring and uncool. Lets call this "reducer" instead o…

Given that Redux is an implementation of the Flux pattern, your grievances may actually be with the naming conventions in Flux itself.

https://facebook.github.io/flux/docs/in-depth-overview.html#...

Re: React Native at Airbnb

#152

Earlier quoted context omitted.

I'm getting a pretty good React Native app working without understanding any Objective C or Swift underlying stuff. Sometimes you just want a Honda.

You are getting your users a pretty bad experience because you are lazy and only think about yourself. Users want Porsches, and they deserve them.

Users may want Porsches, but only a few are actually ready to pay for them.

Re: React Native at Airbnb

#153
post #45

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

Me too. Last time I played with Ionic it was still mostly wrapped webviews though. And Vue-native is actually the worst. It transpiles Vue code into React Native code that then gets sent across the bridge to native apis.

Sorry, have you got any source for the vue-native part? I haven't heard of that and I'm interested.

Re: React Native at Airbnb

#154

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

Flutter's approach is more like "similar UI and UX in all platforms" so I don't think that you need to write native code that much compared to RN. Also, it uses Dart seems to be a better fit for them compared to JS (static typing, better syntax etc.).

Re: React Native at Airbnb

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

Re: React Native at Airbnb

#156

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.

RN is nothing like an Electron app though. Rendering is fully native, no browser engine involved. It does add not-insignificant overhead due to JSC, Yoga and native bridge, but it will depend a lot on the nature of the app.

Re: React Native at Airbnb

#157
post #113
post #82

Earlier quoted context omitted.

Have you tried Flutter? That's looking promising.

Yeah... but... dart.

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.

Re: React Native at Airbnb

#158
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?).

Re: React Native at Airbnb

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

This topic comes up every now and then regarding different start ups. A part of that is required because they're working on some difficult projects, internationalisation is hard, etc, etc.

However, a simple 80kloc system (simple as in no critical safety requirements, very complex algorithms or heavy regulation) is perfectly manageable for a four person team.

A lot of that head count is likely required because they need a large number of employees to attract investment, because scaling start ups are bad at processes (resulting in inefficiencies) and possibly because early employees want to move up the ladder, so they need someone to manage.

Re: React Native at Airbnb

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

So in other words, you think they don't have a spec and they're throwing more bodies at the problem instead of fixing their process? That would be very short-sighted, but it could be possible.
Post reply on HN