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

71–80 of 259 posts

Re: React Native at Airbnb

#71

Post by aplummer »

pbreit wrote: post #63
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.

“business always wants the Ferrari solution at the cost of a Fiat panda“ Isn’t that the promise of computers and technology? What would you suggest that business want?

> Isn’t that the promise of computers and technology? What would you suggest that business want?

The plot twist with software is that the overall cost (including running costs) of buying the ferarri is often lower than the cost of the Fiat panda.

Re: React Native at Airbnb

#72

Post by guelo »

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…

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.

Re: React Native at Airbnb

#73

Post by jgalentine007 »

Apocryphon wrote: post #41

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

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.

Re: React Native at Airbnb

#74

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

Re: React Native at Airbnb

#75

Post by matwood »

philipwhiuk wrote: post #55
faitswulff wrote: post #9

Earlier quoted context omitted.

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…

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

For me, in order of enjoyable front end developer experience it would go iOS > web/js/react > Android.

Re: React Native at Airbnb

#76

Post by spiritcat »

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…

fun one was when sort was stable with debugging turned on but not without :P

(or vice versa? i forget)

Re: React Native at Airbnb

#77

Post by andrewstuart »

acemarke wrote: post #15
benawad wrote: 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

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

Re: React Native at Airbnb

#78

Post by gm-conspiracy »

rpeden wrote: post #70
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…

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…

Been bitten by the console bug as well.

Re: React Native at Airbnb

#79

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

Re: React Native at Airbnb

#80

Post by chii »

RussianCow wrote: post #57
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.

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.

But the draw of cross platform is that you don't need to be an expert in them! Or at least, that's the advertised advantage.
Post reply on HN