React Native at Instagram • Hacker News Board

Re: React Native at Instagram

#191

Post by oakesm9 » Tue, Feb 07, 2017, 3:09 PM UTC

crispytx wrote: post #151

iamleppert wrote: post #53

They probably traded a really nice iOS codebase that had been maintained and improved upon for something that is going to end up with tons of special cases for when the UI is running on iOS/Android etc and make it incredibly difficult to test, reason about. Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smu…

I've never used React Native, but I have done a lot of messing around with Apache Cordova / PhoneGap. From my experience, you're probably better off just developing your apps the "standard way" with Android Studio or xcode. I'm sure React Native doesn't have the exact same problems as PhoneGap, but I bet there are some problems. If there weren't any problems, the iOS and Android codebases would be nearly identical. B…

I worked on a medium sized RN app for both Android and iOS which dealt with the camera, photos and the file system. It was 99.98% the same with only 50 lines of _my_ code difference between then (this obviously excludes framework and library differences).

Re: React Native at Instagram

#192

Post by whatever_dude » Tue, Feb 07, 2017, 3:16 PM UTC

40acres wrote: post #6

I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and metho…

> Do Android apps regularly encompass over 65.3k methods?

No. I've built huge applications that didn't come nowhere near that. I don't dispute some apps might run into that, but it's not a regular occurrence at all.

The real problem here is that it depends on what kind of libraries you're using. If you're liberal with adding a lot of all-purpose libraries when you only need a feature or two, you can run into that limit fast.

For example, look at the comparison table ("Replacing existing libraries") here:

http://jeroenmols.com/blog/2016/05/06/methodcount/

If you just need to load an image, do you want a library with 12k methods (!) or 800?

Re: React Native at Instagram

#193

Post by whatever_dude » Tue, Feb 07, 2017, 3:19 PM UTC

crispytx wrote: post #151

iamleppert wrote: post #53

They probably traded a really nice iOS codebase that had been maintained and improved upon for something that is going to end up with tons of special cases for when the UI is running on iOS/Android etc and make it incredibly difficult to test, reason about. Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smu…

I've never used React Native, but I have done a lot of messing around with Apache Cordova / PhoneGap. From my experience, you're probably better off just developing your apps the "standard way" with Android Studio or xcode. I'm sure React Native doesn't have the exact same problems as PhoneGap, but I bet there are some problems. If there weren't any problems, the iOS and Android codebases would be nearly identical. B…

The problems are different. RN is not using a web view. It's not comparable at all to Cordova/Phonegap.

It's really more like Xamarin with code running in a JS engine and with somewhat easier native code integration.

Re: React Native at Instagram

#194

Post by ashark » Tue, Feb 07, 2017, 3:45 PM UTC

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 once each in Swift and Java.

Javascript/RN, yes (at the cost of safety). Plus you can't throw a rock without hitting two JS devs, even in my non-tech-hub city.

Go, as mentioned elsewhere in this thread, would also be appropriate for the task (Google, for the love of god, make it a first class citizen on Android and use that as an excuse to refactor your SDK into something that doesn't seem like it was loosely designed by a committee then handed to the Summer interns to implement with no supervision or clear specs).

Re: React Native at Instagram

#195

Post by antoniuschan99 » Tue, Feb 07, 2017, 3:49 PM UTC

My project (the weather sensor) is using React Native for the Mobile end. I would still like to work on a professional project to really see how well or bad RN is in an enterprise type project. Having used Titanium Appcelerator on a personal project, I find RN much better than Titanium. I assume it's much better than Xamarin as well.

I think learning RN is a good bet because, it is coming from Facebook. I'm not sure if people remember, but FB on mobile was originally built using Webviews and had notoriously bad reviews because it was slow and laggy. It's because of this lesson that they are in a good position to create a competent platform.

I also think as web developers, we should try to understand more of the tooling/language in one of the mobile platforms of our choice.

Re: React Native at Instagram

#196

Post by bennyg » Tue, Feb 07, 2017, 4:29 PM UTC

kayoone wrote: post #146

bennyg wrote: post #105

Earlier quoted context omitted.

Thanks for pointing that out, forgot my old site was still in the profile. What do you mean by feds? That's still a very confusing statement. Switched off of Xamarin about 8 months ago and haven't looked back. My organization had a ton of problems with Xamarin, without honestly that much gain at all. We still needed specific devs for Android and iOS. Sharing component and state code has been an absolute boon in produ…

We are using Xamarin for our mobile apps and around 90% of .NET code is shared between both platforms. The platform specific code is basically just UI related, which makes sense given the different approaches to some UI mechanics in iOS vs Android. Also leveraging the huge .NET Ecosystem which in general has quite high quality and superb tools for development and debugging is a big plus. We are also starting to use .…

Different strokes, I think.

In our organization, it ended up being UI code that was the 90% number. The actual business logic code wasn't extremely extensive in the same way that we had to know Android and iOS, and then basically transpile mentally what we know into C#. Though almost all of the core SDK methods are named the same, so it wasn't too huge of a mental switch.

At this point with react-native, almost everything is shared. UI code, business logic, app state, etc. I think the node ecosystem opens our organization up to a lot more possibilities as well.

I've found that 3rd party react-native libraries are about the same quality as Xamarin Nuget packages. Some are good, most are meh.

Also, I upvoted you. Thanks for sharing your experiences.

Re: React Native at Instagram

#197

Post by bennyg » Tue, Feb 07, 2017, 4:35 PM UTC

LeoNatan25 wrote: post #115

bennyg wrote: post #105

Earlier quoted context omitted.

Thanks for pointing that out, forgot my old site was still in the profile. What do you mean by feds? That's still a very confusing statement. Switched off of Xamarin about 8 months ago and haven't looked back. My organization had a ton of problems with Xamarin, without honestly that much gain at all. We still needed specific devs for Android and iOS. Sharing component and state code has been an absolute boon in produ…

Let me explain the "fed" thing. React Native's number one "feature" is that web developers are able to join in development, or even start a "native" app where it would not have been possible before due to no native development teams. In the web dev world, "fed" /front end developer/ is usually the term for the front end web developers - this is what I meant. (While iOS and Android is also front end, it seems "fed" is…

I think you're conflating a BS web dev culture (which is amplified extensively through the internet and feedback-loopy sites like HN) and actual development technologies.

There's always articles like you're mentioning. I mean, go look at articles when Swift was first announced - or even iOS tutorials and forums ca. 2011.

Sharing business logic is a good thing. But it's hardly the number one feature of react-native. We share almost everything, and have almost no problems doing so. It's been a very good thing for our org, while Xamarin was the opposite.

It's also worth noting that we ramped everyone up from being C# front-end to React/React-Native front-end. So nobody really came in as cutting-edge web dev experts, but our developer velocity now is insane. I think React/RN are good things.

Re: React Native at Instagram

#198

Post by erichocean » Tue, Feb 07, 2017, 5:03 PM UTC

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++?

Re: React Native at Instagram

#199

Post by ronocod » Tue, Feb 07, 2017, 5:16 PM UTC

whatever_dude wrote: post #192

40acres wrote: post #6

I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and metho…

> Do Android apps regularly encompass over 65.3k methods? No. I've built huge applications that didn't come nowhere near that. I don't dispute some apps might run into that, but it's not a regular occurrence at all. The real problem here is that it depends on what kind of libraries you're using. If you're liberal with adding a lot of all-purpose libraries when you only need a feature or two, you can run into that lim…

It depends, Picasso is smallest but doesn't support GIFs. Glid is larger and does support GIFs. Fresco is larger again but has more advanced memory management and better transition handling.

Re: React Native at Instagram

#200

Post by charrondev » Tue, Feb 07, 2017, 5:33 PM UTC

greyman wrote: post #176

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…

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.