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

171–180 of 259 posts

Re: React Native at Airbnb

#171

Post by pjmlp »

vbezhenar wrote: post #167
pjmlp wrote: post #10

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.

I'm not an expert in iOS or Android, but I shipped few React Native apps. Most of my debugging efforts were in webapp. In fact I don't even remember anything about debugging native layer. And I actually built few native components including integration with compass and yandex maps. Sure, it's not Ferrari, nobody outside of US has money for that kind of apps, it was just few hundred bucks for few weeks of my time, but…

C++ for business logic, with native views for the UI.

Works across both platforms, does not require additional SDKs and has all the debugging tools and API available without any additional FFI work.

Re: React Native at Airbnb

#172

Post by mpweiher »

faitswulff wrote: post #29
akmarinov wrote: post #26

Earlier quoted context omitted.

Server side rendered native screens just seem like fancy words for browser to me… I get that it’ll have native performance and responsiveness, but still maybe just touch up your website and call it a day?

Ah, my mistake, it should say "server-driven," which is more accurate. The view isn't actually rendered on the server, it just seems to be sent over in a declarative format, which the client then renders into a native view.

> sent over in a declarative format

like HTML?

> which the client then renders into a native view.

A WebView?

Re: React Native at Airbnb

#173

Post by danabramov »

ascorbic wrote: post #121
danabramov wrote: post #58

Earlier quoted context omitted.

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?

If you have very good integration tests, sure you can try.

Re: React Native at Airbnb

#174

Post by danabramov »

guelo wrote: post #72
danabramov wrote: post #58

Earlier quoted context omitted.

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…

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.

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.

Re: React Native at Airbnb

#175

Post by skocznymroczny »

filleduchaos wrote: post #28
MBCook wrote: post #24

Earlier quoted context omitted.

I had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared. Close debugging? It broke again. Maddening.

> native web dev That has to be the strangest combination of terms I've seen this month.

I've seen people refer to bare metal Javascript, which sounds even weirder.

Re: React Native at Airbnb

#176

Post by kroltan »

filleduchaos wrote: post #28
MBCook wrote: post #24

Earlier quoted context omitted.

I had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared. Close debugging? It broke again. Maddening.

> native web dev That has to be the strangest combination of terms I've seen this month.

Ever heard of PhoneGap or Electron?

Re: React Native at Airbnb

#177

Post by htormey »

blub wrote: post #160
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.

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.

Large consumer apps generally are iterative affairs where the engineers & designers have a big say in the final product. At any given time Airbnb probably has multiple cross functional teams building different features.

These teams are probably constantly testing and iterating the final design based on user research and testing.

At least that was my experience working at Facebook on their iOS app.

Re: React Native at Airbnb

#178

Post by atomicnumber1 »

kbyatnal wrote: post #16

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

It's really fascinating to read about these in hindsight. But yeah, it must have been a nightmare for them.

Re: React Native at Airbnb

#179

Post by bpicolo »

acemarke wrote: post #56
rawrmaan wrote: post #51

Earlier quoted context omitted.

Let's say you have a component deep in the hierarchy that needs to update based on a small but frequent change in a large object (thousands of keys). With Redux, you have to figure out how to diff the old and new copies of that object to figure out what changed. With MobX, you just observe the value of the exact key you're interested in. That's just one example, but I generally spent a ton of time writing complex sho…

I'd agree that MobX generally gives you good performance out of the box, but I'd definitely disagree that Redux's performance situation is a "nightmare". One of the keys to good Redux performance is to connect more components, and have each component only extract a small piece of the state [0]. Using memoized selector functions also helps in most situations [1]. FWIW, there was a really good discussion on the relativ…

I really like that mobx + vuex have their version of "memoized selectors" (computed getters) straight out of the box, fully integrated. They're so insanely useful.

Re: React Native at Airbnb

#180

Post by hokkos »

Tade0 wrote: post #166
apahwa wrote: post #115

Earlier quoted context omitted.

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

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…

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.
Post reply on HN