Live data from Hacker News

Building all of our new mobile apps using React Native

engineering.shopify.com

301–310 of 588 posts

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

#301
post #81

Earlier quoted context omitted.

It depends pretty much on what the app is all about. CRUD mobile apps can be made pretty fast when not doing an SPA bigger than Quake just for displaying text. SSR, pure CSS3, caching, server workers, mobile first, can go a long way. Naturally there are other kind of apps where native wins hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.

It certainly possible, but there is a lot of arcane knowledge that goes in to the techniques listed. Native apps, generally, has better performance “built in”.

Arcane knowledge? That is pretty basic stuff for anyone doing Web since the HTML 3 days.

Have you ever done native Android, including using the NDK?

It is full of arcane knowledge, scattered about commit comments, medium, G+ and Twitter posts from Android team instead of being on developer.android.com, APIs introduced in one IO are deprecated/replaced by the next IO, OEMs (cough Samsung) that change AOSP behaviours,...

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

#302
post #56

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…

> What's missing until regular websites have parity with mobile apps in functionality? Performance. But we're beginning to approach performance parity - not by the web becoming an faster, mind you, but by apps becoming slower. It used to be only cheap/poor-quality apps that felt like glorified web pages, but now even many high-profile apps are just parts of a web stack embedded into an app.

You make a fair point but it's one about the current state of apps rather than the future of apps. In the future phones will be more powerful and apps will do mostly the same stuff. In theory that should mean the apps will be faster.

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

#303

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…

Native controls can afford to be richer (in principal) because knowledge transfers across apps. Websites do not enable such transfer: there's too much of a culture of customizing everything. On mobile the problem is somewhat less noticeable because rich native interaction models haven't really emerged.

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

#304
post #147

Earlier quoted context omitted.

> Installing software is cringey as hell now? When you know that the features you're interested in can be made easily available by a simple web app.

Perhaps I'm misunderstanding the logic but doesn't that mean using a fancy pen is "cringey as hell" since you can just use a simple ballpoint pen? Sorry, it just seems unnecessarily negative to me.

It's like you ask someone if you can borrow their pen, and they say "Sure, but only if I can rifle through your wallet and attach this GPS tracker to you"

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

#305

I think one of the coolest things that Shopify is doing is this: We’re sponsoring Software Mansion and Krzysztof Magiera (co-founder of React Native for Android) in their open source efforts around React Native. and We are working with Discord to accelerate the open sourcing of FastList for React Native (a library which only renders list items that are in the viewport) and optimizing for Android. Basically RecyclerVi…

Without synchronous view layout, it's not really possible to have a truly recycling view without many warts. We've (Wix) been hacking at this for years, and it's not possible. You either block the UI or view flash for the user if fast enough scrolling is performed. Facebook engineering promised synchronous layout will come at some point, which will open the door to that.

Is Wix moving away from React Native at this point?

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

#306

React Native sounds like a mistimed bet now. Maybe 3-4 years ago, but at this time? There are a number of better alternatives. I spent some time working on a RN project, and even though the whole idea of declarative interface, state update, etc is interesting, it is not exclusive of RN - and there is the whole rest of the story: RN libraries are a mess and usually buggy, there is virtually very little compatibility b…

It's interesting how differently you can look at things. I would consider the best time to start a React Native project to be sometime next year, and after 1.0 ideally.

It's exactly when you jump on the bleeding edge that you end up with cuts and bruises. For every new shiny thing you'll be trading your current known problems for a set of unknowns and the inability to even Google-search for the solution. Let the tinkerers do the bleeding, and only once they've buffed the sharp parts can you as a company like Shopify start to bet on it.

It seems module and library handling was just revamped in React Native (not a user myself yet, perhaps next year), so thank you for your sacrifice. Developers picking up RN today will hopefully have a smoother experience.

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

#307

Shopify is right to use React Native. I build an app with React Native Web and we produce Android/iOS/web from the same code base with 3 developers. No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly native app built by expert platform-specific developers would be better. But I'm able to ship this product with less than half the team size I would need for native development. JavaScript developer…

> No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly native app built by expert platform-specific developers would be better. This can't be understated. You can always tell when you've opened a React-Native (or similar "portable") app. It always feels like shit.

> It always feels like shit.

Yeah, it does, to developers only. They're not the target market.

I used to lobby for my employer to care about the latest iOS feature or fight over what the HIG advises is best practice.

Unfortunately, most business would be perfectly happy if they could have a designer draw a pretty looking app and have it magically pop into existence. Platform features are an afterthought, if a thought at all. I'm not thrilled with the state of the app industry, but it is what it is.

The really elegant solution is to have a passionate team of platform-specific developers pushing the boundaries of what's possible on a mobile device, constantly using the latest features and profiling for battery usage and network usage. Ideally a team that does this would be so proud of the code that it becomes open source to serve as an exemplary model of software engineering actualized.

I know what's "right", but I also know what the market wants. The market wants me to churn out cross-platform CRUD apps as quickly and cheaply as possible.

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

#308

Earlier quoted context omitted.

> they don't need to know any objc/swift/java/kotlin to build the product. I have a hard time believing this, and I've been making apps on both platforms for >10 years. And I love react-native. My latest day job is basically forking popular react-native packages, often rewriting them in Swift, fixing numerous bugs, and adding features specific for our company. And all this experience has taught me that in no way can…

I've only had to dive into the native code a handful of times, but I do basically make an ugly CRUD app. Most apps are ugly CRUD apps though. I haven't used the Shopify app, but it probably falls into that category too. > What do you do when there are native build errors? I periodically do suffer through xcode upgrades, bad RN module linking, gradle issues, etc, but it's a couple of days of work every few months to s…

Having one dev that knows something about the native side makes this very believable now. I haven't had the pleasure to work on a basic CRUD app that didn't also have some A/V or special file IO work. Your project sounds ideal for an exclusive react-native JS team.

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

#309

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.

All this says to me is that they wanted to limit their risk exposure by doing an experiment on Android while maintaining native on iOS. Why is that hard to comprehend? Their move to RN this year should underscore the success of that experiment.

This is how I read it too. They can then run the RN app on iOS too (with some modifications I'm sure). Seems like a smart strategy. And that the jury is still out.

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

#310

> The first is a tooling team that helps with engineering setup, integration and deployment. The second is a foundations team that focuses on SDKs, code reuse and open source. They have a whole team to set up tooling for React Native. I wasted many days trying to do this work on my own. They also have a whole team for evaluating 3rd-party libraries that provide functionality missing from React Native, such as letting…

How has flutter compared?
Post reply on HN