Building all of our new mobile apps using React Native • Hacker News Board

Re: Building all of our new mobile apps using React Native

#211

Post by trevyn » Wed, Jan 29, 2020, 7:23 PM UTC

hugey010 wrote: post #101

I thought the cool thing to do was declare React Native dead for your org, not the new hotness?!? I try to re-evaluate my opinion of the mobile ecosystem monthly, and would love to know how people agree / disagree with my rankings: 1. Just make a web page 2. Native iOS & Android 3. Flutter 4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium…

Really depends on what you’re making.

Personally, I find RN much more productive than native iOS, for the areas where it is applicable. The hot reload is quite magical.

Also, you can push JS updates without needing to update the app in the store, which is a huge plus.

Re: Building all of our new mobile apps using React Native

#212

Post by wvenable » Wed, Jan 29, 2020, 7:24 PM UTC

Androider wrote: post #194

wvenable wrote: post #177

Earlier quoted context omitted.

But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that ri…

But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if y…

Yes, many large companies seek technological solutions to political problems. I've worked for dysfunctional organizations; they want technology to provide the decisions bottom-up because, for whatever reason, nobody wants to make any hard calls. These projects fail because you simply can't have success that way.

If this is a political and organizational problem, then this choice of technology is entirely not about the pros and cons that have probably been debated to death in this topic. I agree. I think you've added some really good insight in this conversation. But I think that solution is dumb.

It's especially dumb for a software company because software is their core competency. That's where they should be spending their resources on. They should be minimizing costs but not at the cost of their core product.

Re: Building all of our new mobile apps using React Native

#213

Post by throw_m239339 » Wed, Jan 29, 2020, 7:27 PM UTC

hugey010 wrote: post #101

I thought the cool thing to do was declare React Native dead for your org, not the new hotness?!? I try to re-evaluate my opinion of the mobile ecosystem monthly, and would love to know how people agree / disagree with my rankings: 1. Just make a web page 2. Native iOS & Android 3. Flutter 4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium…

> 1. Just make a web page

This is 100% reasonable for a lot of apps. I for instance uses the web version of Gmail on my phone without any issue, and Gmail is a complicated app.

Trade-off: not easily discoverable in the store of the platform, harder to test because of browser differences, might not be as fast as a native app from a UI perspective.

> 2. If your app involves persistant storage and functions that are not supported by web browsers, or you need optimal performance like games.

Great performances, easy to stick to UI styles for each platform, access to good quality tools for testing, no, leaky abstraction.

trade-off: unless you are using a language supported by all platforms (C/C++), duplicate codebase for business logic.

> 3. Flutter

I don't know flutter because I don't know Dart.

> 4. Some ordering of remaining cross-platform tools depending on requirements. (React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)

Phonegap and Ionic apps are essentially webapps.

trade-off: for React Native likes: leaky abstractions which leads to issues when not knowing the underlying platform, the need to write "plugins" in the native language…

Re: Building all of our new mobile apps using React Native

#214

Post by api » Wed, Jan 29, 2020, 7:27 PM UTC

goatlover wrote: post #208

api wrote: post #187

Earlier quoted context omitted.

I'm convinced that the long-term future of all UI development is web based, at least at the rendering layer. WASM may free us from JavaScript.

IS WASM canvas-based or HTML/CSS? Because canvas is not what comes to mind when thinking in terms of Web UI.

WASM can access the DOM. Check out this:

https://github.com/gopherjs/vecty

Like React but in Go. Not quite mature yet but getting there.

Re: Building all of our new mobile apps using React Native

#215

Post by Hates_ » Wed, Jan 29, 2020, 7:28 PM UTC

OzzyB wrote: post #157

Shopify should stick to making ecommerce sites and leave the mobile engineering evangelical space to those who's businesses are dependent on mobile and have the necessary experience. In short, the future isn't React Native, unless you have a time machine that will allow you to go back and rewrite it.

So even though they develop apps that have millions of downloads or that businesses rely on for their in-store point of sales, you don't consider Shopify qualified to speak on mobile development?

Re: Building all of our new mobile apps using React Native

#216

Post by sandofsky » Wed, Jan 29, 2020, 7:29 PM UTC

apl002 wrote: post #202

Despegar wrote: post #198

Earlier quoted context omitted.

That really just says it all doesn't it? It's basically an admission that the use of cross-platform frameworks is worse for customers/users, but they're going to ignore that to optimize for their own software engineering org.

you act like whatever something is right now is the same in the future. It's quite possible they see RN as the future for all products and easing there way into things. Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs. So no, that does not really just say it all.

> Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs.

Based on AirBnB's experience, now you need to find React Native devs in addition to Java devs.

Re: Building all of our new mobile apps using React Native

#217

Post by thespace12 » Wed, Jan 29, 2020, 7:29 PM UTC

newfeatureok wrote: post #7

Honestly I think the future of mobile will just be... mobile websites. What's missing until regular websites have parity with mobile apps in functionality? - Accelerometer and all sensor support (some of these are already supported on various browsers on various OSes) - Background support - Bluetooth - WiFi - Better notifications - etc. Sure there will always be a need for native, but 99% of apps don't need any of th…

Actually the future of the application UI is React.

Re: Building all of our new mobile apps using React Native

#218

Post by horsawlarway » Wed, Jan 29, 2020, 7:30 PM UTC

wvenable wrote: post #177

Androider wrote: post #156

Earlier quoted context omitted.

Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS development team, large companies have massive iOS development teams. Massive team * number of platforms = serious money. You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're…

But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that ri…

As someone leading a team that does releases to clients, this is a pretty naive take.

As you scale you get quite a few constraints that require additional manpower

1. Scaling generally means revenue, which means more internal teams pumping out more business products/features.

Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on.

The larger the company, the more requests like this you get. Feature velocity MATTERS.

2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling.

3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product.

Those are just a few of the differences that happen at scale.

----

Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale.

You're just glossing over the politics of working in an org that's successfully scaling.

It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.

Re: Building all of our new mobile apps using React Native

#219

Post by The_rationalist » Wed, Jan 29, 2020, 7:33 PM UTC

aikah wrote: post #188

The_rationalist wrote: post #144

Why not ionic react? https://ionicframework.com/blog/announcing-ionic-react/

> Why not ionic react? https://ionicframework.com/blog/announcing-ionic-react/ React Native uses the Native Components of the platform for UI. Thus Native. Ionic React is basically a web app, this is Ionic with React instead of Angular. So basically React Native == use native GUI components. Ionic React = uses HTML/CSS in a webview embedded in a Native App, just like Phone Gap/ Cordova, Ionic is just a framework on t…

Most react native apps have a custom UX but needs native plugin access. This is the point of ionic react.

Re: Building all of our new mobile apps using React Native

#220

Post by wvenable » Wed, Jan 29, 2020, 7:33 PM UTC

Androider wrote: post #194

wvenable wrote: post #177

Earlier quoted context omitted.

But developer headcount doesn't scale to the size of the installed base. Whether you have hundred-thousand users or a million users, you don't need a larger development team. Once you have a reasonable-sized team that can make the app, you don't need any more developers, no matter how successful your app is. Having different teams for different platforms might result in a slightly larger headcount my point is that ri…

But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons. The large companies are what they are, and you cannot apply the same type of thinking to their problems as if y…

> Because they have massive platform specific teams, and they would like not to.

I'm somewhat shocked at the size of some of the mobile app development teams at some of these companies. There's no way they need that many developers. What are 100's of developers doing on a single app for a single platform? How is there enough work for that many people? The overhead must be unbelievable.

I can't imagine that adding a platform abstraction is going to fundamentally change the headcount if your headcount is already ridiculous. It just doesn't remove that much effort.