Live data from Hacker News

Building all of our new mobile apps using React Native

engineering.shopify.com

561–570 of 588 posts

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

#561
post #165

Earlier quoted context omitted.

Sure. But what if the entire world doesn’t want to learn JavaScript? What if you don’t already know HTML, CSS, and JS? RN makes ZERO sense at that point. As a C developer, man, Flutter looks pretty damn logical!

https://mobile.twitter.com/LinguaBrowse/status/1220695261246...

I don't know if you read your own link or not, but he's first off complaining about a community plugin and not an official one.

There is some truth that overlapping isn't well supported in Flutter CURRENTLY, but I can think of things that were well supported in RN 4 years ago either.

I can't think of a single reason I would want an overlay EXCEPT an alert, and even then, I don't think he's right.

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

#562

Earlier quoted context omitted.

How has flutter compared?

It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1. RN on the other hand bridges the native UI w/ your code via a JS bridge. The downside is the bridge can be a bottleneck so you have to be careful how much you congest it. The result is being able to expose every native functionality and abstract it anyway you want using React extensions. Flutter plans to target deskto…

> It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1.

I don't think 'emulate' is the right word. It renders it's UI. I don't get 'how the fake is noticeable'. It might be a little bit different, but the average person won't pick it up.

To me, this is one of it's big upsides. It doesn't have to do all the translation to native. The performance is good. It's easy to write. No quirks of either OS. Though you do have to worry about the individual OS's if you're doing something lower level, but you have the power to do so, so that's still a plus.

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

#563
post #481

Earlier quoted context omitted.

> In the future phones will be more powerful Single-core performance is largely topping out. The gains are incremental at best. Mobile SoCs have gone incredibly multi-core incredibly quickly (6-8 cores are common!). Meanwhile the web is incredibly bad at handling that. JavaScript code still has to fight with the GC for CPU time on the single thread they both occupy. WebWorkers are incredibly heavy & limited. WebAssem…

> Meanwhile CSS & DOM performance continues to be poor The DOM is not slow, that is brain washing from React developpers to justify your VDOM. Most Reactive app performance issue nowadays comes from library bloat loading, network saturation or data dependencies. The main problem with the DOM is not the performance but the API. The DOM API is not appropriate anymore for a reactive usage with transactional reflows. And…

> The DOM is not slow, that is brain washing from React developpers to justify your VDOM.

I'm comparing against native apps, not React VDOM vs. DOM. Direct fiddling of widget properties is common & perfectly fast in native apps, even when done naively. The same is not true of the DOM, especially with all its synchronous layout & style resolution foot-guns.

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

#564

Earlier quoted context omitted.

> acceptable performance Until your competitor shows up. I think you are honestly right for the most cases, but the expectation on mobile, (esp. since the OS is written in native and 120Hz screens are coming) is so freaking high. The touch response rate expected is just going to make hybrid and web apps just seem like trash to the average consumer when compared directly with native apps. They just don't do it and jus…

> esp. since the OS is written in native and 120Hz screens are coming High-refresh rate mobile displays already happened. There's more 90Hz than 120Hz on the market at the moment. Typically gamer-focused phones like the Asus ROG Phone or the Razer Phone, but non-gamer-focused flagships are also now 90Hz like the Pixel 4. And of course on the iOS side of the ecosystem some iPad models already have 120hz displays, too.

Of course there are current examples, but in general the scale is not large at all on phones. Less than 1% of sales. Being first doesn't mean anything if it doesn't sell, being the majority of sales is a much different world.

I'm referring to the 2020 iPhone Pro and the Galaxy S20 both being rumored to have 120Hz displays, massive changes in the market.

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

#565

Earlier quoted context omitted.

It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1. RN on the other hand bridges the native UI w/ your code via a JS bridge. The downside is the bridge can be a bottleneck so you have to be careful how much you congest it. The result is being able to expose every native functionality and abstract it anyway you want using React extensions. Flutter plans to target deskto…

> It emulates the UI, so the fake is noticeable, and it will be hard for them to maintain perfect 1:1. I don't think 'emulate' is the right word. It renders it's UI. I don't get 'how the fake is noticeable'. It might be a little bit different, but the average person won't pick it up. To me, this is one of it's big upsides. It doesn't have to do all the translation to native. The performance is good. It's easy to writ…

It renders a UI similar to the native UI by mimicking it, it emulates it. It meets every meaning of the word.

It's a different approach than RN, but in my opinion, it's flawed.

This isn't anything new in the desktop realm at least. QT vs wxWidgets. QT renders it's own UI, which is great if you are going for your own look, same with Flutter. wxWidgets and RN both shine by being able to wrap the native platform and bridge it.

Eventually your "good enough for the average person" implementation will be out-of-date, and you will always be worse than native, because it's "good enough". That's when you start getting into flaws of cross-platform.

With React Native, it's the exact same, not "good enough". You can wrap any native functionality, and you don't have to maintain copies of visuals and physics for each platform you want to fake.

Yes there are some compatibility issues that you have to address when you try to abstract them, but that will come up regardless of which framework you use.

Currently I'm working on a solution that resolves all of these RN issues across platforms.

P.S. users can tell, they just may not be able to point it out.

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

#566
post #344

Earlier quoted context omitted.

Users hate web apps, especially on mobile, and it has nothing to do with functionality. Web apps on the App Store invariably provoke angry screeds about how the look and feel is not right. Native apps are even more essential on mobile. On the desktop, web apps just look weird and waste battery life. On mobile, they feel wrong. That difference in feel provokes visceral hatred.

No. Designers and some devs hate web apps for minuscule reasons your average user doesn’t care about and doesn’t notice at all. If an app helps them to get a task done, it simply doesn’t matter if the thing is native or not. At least, if you use a somewhat reasonable UI approach like Ionic.

Users absolutely want their apps to be as fast and fluid as possible. This is why they buy the newest Apple and Android phones every year, because their web apps are getting slower and slower.

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

#567
I’m a bit bullish on ReactNative. Well on UI controlled by JavaScript that work a consistently across different platforms.

I acknowledge Flutter from Google is making rounds but Dart simply doesn’t have the ecosystem and reach that Javascript does.

Standard web html always seems to be quite laggy in mobile browsers. Basic things are quirky like the location bar is conditionally visible when scrolling up but not scrolling down. This changes the viewport.

Web rendering doesn’t seem to be as efficient and rich as native UI.

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

#568
post #452
post #430

Earlier quoted context omitted.

This overstates the gains by a lot. 1) Each platform still requires a good amount of special attention. 2) The React Native project introduces breaking changes far more frequently than the underlying platforms 3) Being an abstraction layer, eventually something will break, and you’ll still need someone who understands cryptic linker errors and platform specific quirks. There are cases where it definitely makes sense,…

I would argue to the contrary that it’s such a large optimization that even accounting for all of that it’s still a big net win from a staffing perspective. It’s far easier to maintain a few Android experts on staff than an entire department of them.

I understand that argument, and it's seductive, and in many cases probably true. But it's advertised as a 2-3x productivity gain and that is simply not the case.

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

#569
post #554

Earlier quoted context omitted.

Understood. But do you know how many businesses would die to be able to sell products that had a 70% gross profit margin?

I'm not sure about your calculation. A business with only 29% gross profit margin wouldn't be able to survive on the app store because they'd have to give 30% to apple.

Where did you get 29% from? I’m assuming that you are the only developer working on this (you didn’t say otherwise), for every $1 that someone spends, you get .70 cents.

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

#570

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…

Ten years ago Facebook fought this battle and lost. [1] [2] [3] [1]: https://www.facebook.com/notes/facebook-engineering/using-ht... "Using HTML5 Today" [2]: https://appleinsider.com/articles/12/09/11/facebook_admits_h... "Facebook admits HTML5 not competitive with Cocoa Touch" [3]: https://techcrunch.com/2012/12/13/facebook-android-faster/ "Facebook Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively…

I always thought Sencha debunked that: https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...
Post reply on HN