Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Native at Instagram

engineering.instagram.com

Post reply on HN
Print view View original

201–210 of 238 posts

Re: React Native at Instagram

#201

Post by realharo »

erichocean wrote: post #198
ryandrake wrote: post #99

Call me old-fashioned, but I thought the Android/iOS code sharing nut was cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java (Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as well.

That's how we do it as well. Bonus: you can test your business logic without having to run it on a phone. I'm shocked more people don't do this—I guess they don't know C++?

>Bonus: you can test your business logic without having to run it on a phone.

You can do that with JS (or TypeScript etc.) as well. Even Java (or Kotlin) and Swift, or anything really, if you care enough to separate it from the UI parts.

Re: React Native at Instagram

#202

Post by reggieband »

intoverflow2 wrote: post #168

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 from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly.

As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough.

I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.

Re: React Native at Instagram

#203

Post by realharo »

ashark wrote: post #194
ryandrake wrote: post #99

Call me old-fashioned, but I thought the Android/iOS code sharing nut was cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java (Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as well.

Lots of apps (that get made, not that necessarily get used much) are basically CRUD web apps with a smattering of native features being used in a very vanilla way (maybe a little geolocation/gps, maybe you can snap a profile pic with the camera, whatever). Your "shared logic" is HTTP requests, JSON-parsing code, and validating text fields. It would not improve productivity to do that in c/c++ instead of just doing it…

>at the cost of safety

Are you talking about type safety? Because you can use TypeScript with React Native too, and it's probably a nicer dev experience than plain JS as well.

Re: React Native at Instagram

#204

Post by nonsince »

reggieband wrote: post #202
intoverflow2 wrote: post #168

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…

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't have control there).

Re: React Native at Instagram

#205

Post by jetter »

nonsince wrote: post #204
reggieband wrote: post #202

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'…

React Native does not generate any HTML. It generates native controls.

Re: React Native at Instagram

#206

Post by reggieband »

nonsince wrote: post #204
reggieband wrote: post #202

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'…

> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack

I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical.

As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster.

In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native.

[0] https://en.wikipedia.org/wiki/Marmalade_(software)

Re: React Native at Instagram

#207

Post by creyes »

danmaz74 wrote: post #177
intoverflow2 wrote: post #168

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…

OTOH, this kind of tech is a godsend for smaller shops and solo developers, where having two completely separate codbases (or three if you also do a web version) can be impossible.

Or smaller startups who need to support both platforms at launch. We're going through that right now and we definitely can't afford to pay for a java dev and a swift dev and a js engineer (me). We also can't afford the Dev Shop costs of both iOS and Android. and our customer base is split 65-35. React-Native is literally a gift sent from God to save us

Re: React Native at Instagram

#208

Post by wasyl »

hota_mazi wrote: post #127
bitmapbrother wrote: post #107

Earlier quoted context omitted.

This is one of those Android design decisions that Google probably wishes they could get to do over again. The DEX header file format allocates only 2 bytes to hold the number of methods the app can reference. This was a very short sighted decision that has come back to bite them repeatedly. It would be interesting to know why they only allocated 2 bytes instead of 4 which would have given them the ability to referen…

> This is one of those Android design decisions that Google probably wishes they could get to do over again. Doubtful. This decision is what allowed Android to perform reasonably even in the early days circa 2008. Without such a restriction, it's possible that Android couldn't have competed with iOS on performance and die as a consequence. It's easy to make fun of technical decisions made ten years ago, try to put th…

> this 65k limit is barely a minor annoyance that only a very tiny percentage of Android apps ever hit

This is not true, you can easily hit this limit because of a dependency that you _need_ that pulls e.g. Gauva, of when you use 2 or 3 libraries from Play Services, which are huge

> (and there are easy workarounds)

Easy maybe, but the issue is still more than _a minor annoyance_ imo

Re: React Native at Instagram

#209

Post by hajile »

nonsince wrote: post #204
reggieband wrote: post #202

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'…

Google might have the thing for you...

https://flutter.io/

Re: React Native at Instagram

#210

Post by htormey »

reggieband wrote: post #202
intoverflow2 wrote: post #168

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…

Just in case some folks read this comment the wrong way, React Native is not based on webviews like say Cordova:

http://stackoverflow.com/questions/33479180/what-does-react-...

"React Native uses a JavaScript runtime, but the UI is not HTML and it doesn't use a WebView. You use JSX and React Native specific components to define the UI."

Some notes on React's virtual DOM concept:

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 an important point to note as a lot of the problems associated with hybrid apps in the past come down to them being based on WebViews.

Post reply on HN