Live data from Hacker News

React Native at Instagram

engineering.instagram.com

211–220 of 238 posts

Re: React Native at Instagram

#211
post #40
post #32

I really want to look at React Native, but every time I pull up my Facebook app on my iPhone 6, it can take upwards of 30 seconds before the interface is useable. That's on a very fast connection. So to me the FB app is so slow, it makes me hesitant to give React Native much more thought as you'd figure the FB app would be THE showcase app for it. Maybe I'm the only one?

Someone correct me if I'm wrong but AFAIK the Facebook app isn't really using react native yet, just in very small parts (event dashboard). The rest is still plain old swift and objc.

It's listed in the React Native showcase:

https://facebook.github.io/react-native/showcase.html

Re: React Native at Instagram

#212

Earlier quoted context omitted.

> devs have an easier life using JS I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively. This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time fr…

So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don'…

The core Facebook iOS team built the news feed in ComponentKit. ComponentKit (Objective C++) was inspired by React:

http://componentkit.org/

" Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex,"

React Native is not based on WebViews/HTML. It uses a virtual DOM on top of native views:

https://facebook.github.io/react/docs/optimizing-performance...

"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."

This is quite different from similar Javascript based efforts such as Cordova.

Re: React Native at Instagram

#213
post #38
post #32

I really want to look at React Native, but every time I pull up my Facebook app on my iPhone 6, it can take upwards of 30 seconds before the interface is useable. That's on a very fast connection. So to me the FB app is so slow, it makes me hesitant to give React Native much more thought as you'd figure the FB app would be THE showcase app for it. Maybe I'm the only one?

I wouldn't say you are the only one, but upwards of 30 seconds is very slow - I don't know anyone seeing that kind of performance. Perhaps try reinstalling?

I think I'll try that. Every time the lag happens I'm surprised by just how slow the app feels.

Re: React Native at Instagram

#214
post #209

Earlier quoted context omitted.

So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don'…

Google might have the thing for you... https://flutter.io/

Too bad Dart has fallen so far out of fashion.

Re: React Native at Instagram

#215

This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been. Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance? Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft jus…

Unless you are making a video game, or doing high throughput data processing, the JavaScript language is probably not your performance bottleneck.

For the most part performance problems in consumer apps are things like pagination, poor re-use of data structures, over pre-caching, etc.

Instagram never has more than what... 10, 20 elements on the screen? And it's all pretty much text or at most a 10 second video clip. There's no reason even a crappy mobile processor can't handle those elements. It's all a matter of being intelligent about what you put on the screen and when.

There's no need for high performance rich data structures. There's no big data.

Re: React Native at Instagram

#216

Earlier quoted context omitted.

> devs having a slightly easier day I think the goal here is to target both iOS and Android with just one codebase. But I also happen to hate this trend, and I see it on Windows too. It seems like companies stopped creating native, good-looking and performant GUI applications built on .NET (or on Win32 which I still would find acceptable), and instead opted for uglier and less performant applications running on some…

Could you give an example or two of a beautiful 3rd part .NET or Win32 app on windows? In my mind many of the standard win-forms-esque looking apps are really ugly or have issues scaling on hi-dpi screens.

BeyondCompare springs to mind. Holy crap, I love that tool.

Re: React Native at Instagram

#217

This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been. Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance? Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft jus…

> devs have an easier life using JS I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively. This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time fr…

> > devs have an easier life using JS

> I think that is willfully missing the point.

How is GP missing the point, when you go on to illustrate the point? Or, is your counter-point to GP that "design is special, so cut us some slack"?

Re: React Native at Instagram

#218
post #217

Earlier quoted context omitted.

> devs have an easier life using JS I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively. This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time fr…

> > devs have an easier life using JS > I think that is willfully missing the point. How is GP missing the point, when you go on to illustrate the point? Or, is your counter-point to GP that "design is special, so cut us some slack"?

The GP implies that the only reason a company would go with React Native is to make life easier for it's dev's at the expense of performance. That's clearly not true and I believe the GP knows it.

If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement, growth and advertisement numbers every quarter. Choosing a technology that hurts those numbers would be a poor decision.

Performance doesn't come for free it often comes at the cost of stability and slower time to market. In the case of React Native versus having separate Native teams it also comes at the cost of synchronizing different product teams and dealing with the bugs that come out of that.

To sum up, if React Native was a poor choice it would reflect in the user engagement/growth numbers and wouldn't last long within a metrics driven public company like Facebook.

Re: React Native at Instagram

#219
Thanks for sharing!

I'm currently leading the (soft) transition of a two-platform, not-so-much-shared-code code base (ObjC, Java, Swift, C++) to React Native.

We hit some snags early on (mostly wrt tooling; also prepare to alter your mind set) but as the article states RN yields an astonishing amount of code reuse between platforms as well as heavily reduced turnaround times.

It’s way too early for conclusions/doing a post mortem for our project at this time.

Nonetheless I’d say we’re able to iterate faster by an order of magnitude and the added value of discussing features and domain logic/behavior for both platforms at the same time while enabling UX/UI to get results/feedback faster is a huge win.

That said, I’m really looking forward to the challenges that lie ahead (i18n, RTL quirks, proper unit/feature/integration testing scenarios, non-trivial native bridging, …)

Re: React Native at Instagram

#220
post #179
post #44

Earlier quoted context omitted.

Yep, I can confirm the same. I've shipped two reasonably complex react native apps, both were about 80-90% shared code. Areas where we diverged were things like permissions on Android versus iOS, code that has to run in the background while the app is not foregrounded, material design stuff.

How did you do the Material stuff on React Native?

We used this and special cased for Android:

https://github.com/xinthink/react-native-material-kit

Post reply on HN