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

231–240 of 259 posts

Re: React Native at Airbnb

#231

Post by chengyinliu »

kbyatnal wrote: post #204
chengyinliu wrote: post #114

Earlier quoted context omitted.

Thanks for pointing this out. This part was my experience and as you said, it was quite frustrating. Overall the RN experience made me more skeptical about thing I usually take for granted. It really shows how hard it is for RN to work cross platform. Each abstraction layer can bring in some new problems.

You were the one who had to find this bug? That's pretty neat! How long did it take for the Aha! moment?

IIRC the whole debugging took half a day. There wasn't exactly an Aha moment either. Enough trying different accounts/platforms/devices/environments made me realize that debugger might have changed the result. Once it was confirmed I actually felt defeated. Hard to feel good when you are hit by observer effect and at the same time realize that the a native JS API could be problematic.

Re: React Native at Airbnb

#232

Post by eugeniub »

dawhizkid wrote: post #228

I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18 months testing a new font. A 5 part series on React Native is again next-level indulgent. Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?

Yeah nothing weirder than engineers writing about their experiences with different technologies.

Re: React Native at Airbnb

#233

Post by kaixi »

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…

Programming doesn't change that much after all.

gRPC is just a modern SOAP. There, I said it.

Re: React Native at Airbnb

#234

Post by Matthias247 »

Reedx wrote: post #60
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.

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

Also on the industrial and automative world. Lots of tools will be written in C# there. Often with WPF visualization.

Re: React Native at Airbnb

#235

Post by rpeden »

kaixi wrote: post #233
rpeden wrote: post #70

Earlier quoted context omitted.

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…

Programming doesn't change that much after all. gRPC is just a modern SOAP. There, I said it.

Modern SOAP doesn't sound too bad to me! But then again, I never found SOAP to be all that bad.

I might have been lucky, though. Every time I had to use SOAP, it was just a matter of auto generating a client interface in whatever language I happened to be working in and then proceeding from there. I suppose not everyone was so fortunate.

Re: React Native at Airbnb

#236

Post by dawhizkid »

eugeniub wrote: post #232
dawhizkid wrote: post #228

I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18 months testing a new font. A 5 part series on React Native is again next-level indulgent. Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?

Yeah nothing weirder than engineers writing about their experiences with different technologies.

A 5 part series. 5!!

Re: React Native at Airbnb

#237

Post by maga_2020 »

bpicolo wrote: post #14
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

The cognitive overhead of redux ends up being pretty high due to the boilerplate in my opinion. It feels like complexity increases very linearly as project size goes. I've found that MobX translates to a much simpler mental model, though it does have a variety of quirks to deal with that Redux doesn't face (like converting objects to non-observable for test case assertions)

I strongly agree with the 'cognitive overhead' comment.

I think, a number of challenges that Redux and MobX are intended to address, can potentially be resolved in more elegant and easy manner with the new (16.3.1 and above) Context APIs. ReactNative 55.+ works with 16.3.x and 16.4.0 so these APIs are available to your react native apps now.

For example making available global stores to all the components that need them, being able to invoke 'render' on the interested components, when a particular store is being updated -- all of that is being supported. All that without passing the store as property through the hierarchy depth.

for the cases where your component relation is 'horizontal', rather than hierarchical. I recommend simply to use pubsub.js. It is a library that has 0 dependencies (rarity in JavaScript ecosystem :-) ). and has both Sync and Async publishing via channels. So that you can pause your publishing to the horizontally-connected components, if you need to, and then resume -- when the publishing is done.

Re: React Native at Airbnb

#238

Post by maga_2020 »

bengotow wrote: post #190
xenadu02 wrote: post #143

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.

Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.

I agree with you, that for the same 'business logic', having it JavaScript vs native, unless you do lots of sorting/copying of data -- will not have battery impact difference.

However, React itself (not the javascript engine) brings in additional dimensions, that are somewhat unique to react.

For example, React's (and therefore ReactNative) TextInput control, essentially (in my understanding) encourages you to update a state variable, every single time type a letter into that control

(because the values displayed in the control are coming from the state, so the only way to display the character you typed, is via updating the state).

So that round trip of the character update, to updating the object with state variable, calling .setState, forcing the re-rendering, will consume more battery power. In my view

(I know textinput in particular has the 'uncontrolled model').

My point, that the constant 'create new object', update the state with it, and Re-render -- could be slower (and less battery efficient), than doing may be something similar (or more efficient) in Native Code.

Re: React Native at Airbnb

#239

Post by sebazzz »

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…

I had a bug that was even worse, and I never found a workaround for IE11.

In this case I had some kind of progress bar that was updated while a report is being generated. When the report is completely generated, the progress bar is replaced by a button.

Except in IE11. At some point the progress bar stopped updating and it never turned into a button. Until you opened the developer tools and IE11 "flushes" the DOM and paints the new situation. So, never having found the cause, we recommended that (internal) customer to use F12 regularly on that page.

Re: React Native at Airbnb

#240

Post by damoebius »

smt88 wrote: post #5

None of the recent articles or HN comment threads about React Native spend much time evaluating Haxe. I guess it's not that widely used for CRUD apps and is more popular for games? Anyway, I'd love to know how it would work for an Airbnb-like org.

Well, you can use Haxe with React Native instead of plain Javascript. If you are looking for a way to build mobile apps, you can try HaxeUI v2, based on OpenFL. http://haxeui.org/
Post reply on HN