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

51–60 of 259 posts

Re: React Native at Airbnb

#51

Post by rawrmaan »

acemarke wrote: post #49
rawrmaan wrote: post #47

Earlier quoted context omitted.

Yeah, MobX is significantly easier to reason about, even if it may have a few idiosyncrasies that make debugging more challenging. Also, performance optimization of React components is a cinch with MobX and a nightmare with Redux.

Can you explain what you mean by "perf optimization is a nightmare with Redux" ? Generally, Redux helps improve performance in a React app, especially as you connect more components.

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 shouldComponentUpdate functions and therefore making lots of mistakes with Redux. I've found MobX much more suited to building complex UIs with deep hierarchies and tens to hundreds of total elements on the screen at once, where updating only exactly when necessary is critical.

I use MobX for my game Falcross, which I wrote about in the State of React Native 2018 thread from a few days ago: https://news.ycombinator.com/item?id=17316877

I initially used Redux, and I found it actually technically impossible to get the game to perform well using Redux. I tried everything.

Re: React Native at Airbnb

#52

Post by smt88 »

SneakerXZ wrote: post #40
woolvalley wrote: post #37

Earlier quoted context omitted.

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.

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…

I think F# and .NET Core may become popular among certain kinds of startups (FinTech, logistics, etc.). It's a good compromise between Java and something like Haskell, in my opinion.

Re: React Native at Airbnb

#53

Post by danenania »

tomc1985 wrote: post #42
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

Having never worked with Redux, what is its point? Is it really so hard to stick app state in a JS object and databind off that?

In a simple app, no. In a really big app with tons of interdependent, asynchronously loaded state? Have fun.

Redux definitely has too much boilerplate, but it does an excellent job of keeping functionality decoupled, and on a big project this ends up being way more important. When you do it right, you rarely introduce regressions when working on new features, because almost everything you do is additive: you're adding new state, new actions, new selectors, new sagas, etc., without touching any pre-existing functionality or anything that pre-existing functionality depends on.

The alternative is playing an endless game of whack-a-mole as an app gets too large for anyone to keep track of what depends on what.

Re: React Native at Airbnb

#54

Post by philipwhiuk »

eysquared wrote: post #35
danabramov wrote: post #33

Earlier quoted context omitted.

>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... It's a shame we weren't fast enough to help Airbnb in…

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…

Couldn't agree more - AirBnB were already saying upgrading is a pain and this sounds like it'll be substantial.

I hope RN is going to stop relying on beta code for releases too.

Re: React Native at Airbnb

#55

Post by philipwhiuk »

faitswulff wrote: post #9
msoad wrote: post #2

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.

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.

Re: React Native at Airbnb

#56

Post by acemarke »

rawrmaan wrote: post #51
acemarke wrote: post #49

Earlier quoted context omitted.

Can you explain what you mean by "perf optimization is a nightmare with Redux" ? Generally, Redux helps improve performance in a React app, especially as you connect more components.

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 relative strengths and weaknesses of Redux and MobX in regards to performance a while back [2].

[0] https://blog.isquaredsoftware.com/2017/01/practical-redux-pa...

[1] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...

[2] https://www.reddit.com/r/reactjs/comments/5hf4d4/an_artifici... (see the linked article, the Reddit comments, and the links in the comments).

Re: React Native at Airbnb

#57

Post by RussianCow »

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.

Re: React Native at Airbnb

#58

Post by danabramov »

eysquared wrote: post #35
danabramov wrote: post #33

Earlier quoted context omitted.

>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... It's a shame we weren't fast enough to help Airbnb in…

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

Re: React Native at Airbnb

#59

Post by [deleted] »

SneakerXZ wrote: post #40
woolvalley wrote: post #37

Earlier quoted context omitted.

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.

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…

[deleted]

Re: React Native at Airbnb

#60

Post by Reedx »

woolvalley wrote: post #37
SneakerXZ wrote: post #23

Earlier quoted context omitted.

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

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.

On the web side, yeah, though on the game side C# is very popular (largely thanks to Unity).
Post reply on HN