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

171–180 of 238 posts

Re: React Native at Instagram

#171

Post by a-saleh »

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…

I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.

Re: React Native at Instagram

#172

Post by unsoundInput »

zcoyle wrote: post #81
ashark wrote: post #39

Earlier quoted context omitted.

I've definitely included a library and then seen (otherlibrary).(library you included) as an option in autocomplete, fairly often. Happens a lot with utility-level things like okhttp.

I've seen this with okhttp as well.

I can't find the okhttp case you reference, but retrofit has a bunch of extra adapter artifacts that add an external library as a transient dependency to your project.

The code for the binding classes lives in retrofit.adapter.{guava|rxjava|…} [0] but the respective library still lives in its usual package. [1]

If that weren't the case you could A) not manually provide a minor version via your dependencies block in your build script and B) would have interop problems between libraries and between a library and your code as the same interface copied to a different packages is not the same interface for Java.

[0] https://github.com/square/retrofit/tree/master/retrofit-adap...

[1] https://github.com/square/retrofit/blob/master/retrofit-adap...

Re: React Native at Instagram

#173

Post by realharo »

pjmlp wrote: post #169
izacus wrote: post #166

Earlier quoted context omitted.

Samsung already releases phones running Tizen to have a side bet against Android. The quality of software is not very important when your only competitor builds phones that are significantly more expensive.

Tizen is a joke for app developers, it was already rebooted so many times, no one serious would spend a second trying to target the platform. 1 - Meego reborn as Tizen 2 - Tizen gets the Bada C++ SDK, with its Symbian C++ like flavour 3 - Enlightment guys join Tizen 4 - C++ SDK gets kicked out and replaced by Enlightment C libraries 5 - Developers complain that Tizen 2.3 drops C++ and is a C only experience 6 - Samsu…

There was also a period of only allowing "HTML5 apps" (during the jQuery era no less) if I remember it correctly.

Re: React Native at Instagram

#174

Post by pjmlp »

realharo wrote: post #173
pjmlp wrote: post #169

Earlier quoted context omitted.

Tizen is a joke for app developers, it was already rebooted so many times, no one serious would spend a second trying to target the platform. 1 - Meego reborn as Tizen 2 - Tizen gets the Bada C++ SDK, with its Symbian C++ like flavour 3 - Enlightment guys join Tizen 4 - C++ SDK gets kicked out and replaced by Enlightment C libraries 5 - Developers complain that Tizen 2.3 drops C++ and is a C only experience 6 - Samsu…

There was also a period of only allowing "HTML5 apps" (during the jQuery era no less) if I remember it correctly.

It is still the case when targeting Tizen TV devices.

Re: React Native at Instagram

#175

Post by chrisan »

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…

> Think the millions of users would prefer their devices to have better battery life, load faster

I'd love to see some testing here. Are we talking fractions of a percent or something like 20% more battery drain? If its fractions I am willing to bet most people would pick an easier life (assuming JS is their definition of easier).

> have we forgotten the move from native > webtech > native

I doubt many have, especially Facebook themselves. What a large cost that must have been for them. To have failed that and be willing to risk doing it all over again with native > "webtech2.0" must say something.

Re: React Native at Instagram

#176

Post by greyman »

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 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 javascript or node.js framework, because those will also run elsewhere.

Re: React Native at Instagram

#177

Post by danmaz74 »

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.

Re: React Native at Instagram

#178

Post by sidlls »

iLoch wrote: post #51
kumarm wrote: post #42

I don't think ReactNative has a reason to exist other than Facebook wanting to own Platform (Which they might abandon just like Parse). Good Read: https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding...

I think you might be confusing Facebook with Google. Ask any app developer that's used React Native or any web developer that's had to create a native app if it has a reason to exist. Facebook has hundreds or thousands of React developers that - before React Native - could only develop for web. Now they can move their web developers to their native apps almost seamlessly.

And that's a good thing? I'm being serious here. The web ranks among the crappiest user experience I have with software I use today. And when I speak with colleagues who do the web development at the company I work for they seem far from happy with their development environments and process. It's like the presentation, in which MB of JavaScript are required to render a few paragraphs of text with a side bar or drop-down menu, went to the development environment where thousands of dependencies are required to produce "hello world."

The last thing I want is to see yet more traveling down the path of "web app" style development for my phone's apps.

Re: React Native at Instagram

#179

Post by swah »

htormey wrote: post #44
codazoda wrote: post #23

Earlier quoted context omitted.

I'm working on a project where we are recreating a native app using React Native. We've found similar results; about 90% of our code is shared between both platforms. We also build both platforms every time, so both apps match really well. I'm not sold on React yet but this is a major plus to the platform.

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?

Re: React Native at Instagram

#180

Post by kuschku »

shortstuffsushi wrote: post #119
kuschku wrote: post #112

Earlier quoted context omitted.

It's not that easy, and not just one field. DEX uses a method table, listing every method with an ID, and using in the rest of the file only that ID to refer to it. This ID is limited to 2 bytes. Obviously, thats an issue, but short of using varint or straightaway uint32 there's few alternatives. And those use either more CPU or memory.

You make it sound like it is as simple as that, only a method table instead of a header field :) That said, you mention using a varint or uint32 which "use more CPU or memory" -- 16 bits vs 32 bits in applications that use megabytes seems trivial. Can you explain why that's a concern?

It's not a concern anymore, but when Android was created, the average application was less than 20kiB. Back then, resource restrictions were a lot more problematic.
Post reply on HN