12 ms·

Personally, to me, whenever I read these stories about how Amazon is doing this novel use of WebAssembly, or how Uber is doing ludicrous engineering effort to k

Personally, to me, whenever I read these stories about how Amazon is doing this novel use of WebAssembly, or how Uber is doing ludicrous engineering effort to keep their React-based app under 300MB for the App Store, I can't help but think: "Man, that's an awful lot of work to avoid writing a native app."

deleted 5y ago
[deleted]
Kaedon 5y ago
The challenge would be that Prime Video is distributed on many client devices. Here’s a list of a few TV OSes: https://en.m.wikipedia.org/wiki/List_of_smart_TV_platforms https://en.m.wikipedia.org/wiki/List_of_smart_TV_platforms. How would you manage a different native app for each of them? Caveat: previously worked at Prime Video though not in this area, still at Amazon
- gjsman-1000 5y ago
  I could be incorrect, but last time I did some reverse-engineering, Netflix had a Qt application that used native C++ bindings to knock out huge sections of that list. That Qt application was only lightly modified for each platform, IIRC, and it appeared all over the place from those cheap Linux-based Blu-ray players to Smart TV clients. Anywhere that was embedded, generally Linux-based, and unlikely to get frequent updates. As for some of the larger players like Roku or Android, those ones are more obvious where to hire. Java developers and BrightScript developers.
  - mftb 5y ago
    It all kind of undermines your original comment tho that they're trying to avoid native. It seems more likely that they're goal is to reach as many devices as they can and be able to do updates frequently. In the first paragraph of the linked article the guy says the trade-off is between "updatability and performance".
    - nofunsir 5y ago
      I am really sick of fast-churn and forced updates. Guys. Settle. Write a native app or three. It’ll be ok.
      - remus 5y ago
        I think it's important not to conflate churn with fast updates. In it's essence the ability to deliver updates quickly (in this case by downloading a blob of wasm+js each time the app is started) is a great thing imo, as you eliminate a huge chunk of problems around delivering updates and clients on old versions. For 99% of users this is a huge win. You can obviously abuse this by redesigning the UI every 6 weeks but let's not throw the baby out with the bath water.
        nofunsir 5y ago
        I'm of the strong opinion that there simply does not exist, as you say, 'a huge chunk of problems around delivering updates and clients on old versions.' It's certainly not a win for users, but for lazy developers. Good software engineers are much more than fast-churn developers. In fact, they are different people.
        progmetaldev 5y ago
        I'm 100% with you on this, but good software engineers are also much more expensive than fast-churn developers, and it seems to come down to how much spend these companies want to invest in their technology. There is just an overabundance of web developers out there, and the tech companies are taking advantage of that.
        remus 5y ago
        I guess we'll have to agree to disagree. I just don't see barriers in getting updates out to people as a good thing. It seems your argument is that it encourages developers to be sloppy, but in practice I think it just ends up as a net loss for users as the average user just isn't interested in updating software, however critical the bugs in their current version. Maybe I'm different from the average user, but for me the fact that chrome has gone through 90+ versions over 10+ years without me having to think about it is great (and, I suspect, strongly correlated to the relative lack of security issues over the years despite it having a huge surface area).
hashimotonomora 5y ago
It’s all about deployability.
systemvoltage 5y ago
I love native apps. But on the scale of Amazon (and having to compete with Netflix), slightest bit of friction, in this case downloading and installing an app, accepting permissions, etc takes a minute or two. It would be absolutely catastrophic to their competitiveness. You need to think more broadly on scale.
- gjsman-1000 5y ago
  If you read the original article, the use of WebAssembly is mainly across a broad array of device types where it will be packaged into an app. That app will require installation, accepting permissions, and all of that just like a native app. The point is moot except for anyone watching Prime Video in the web browser.
  - vp8989 5y ago
    The WebAssembly component gets pulled on app startup. That means you make a bug fix, deploy a new build to an S3 bucket and every single user is running the fix inside of ~24 hours.
nikki93 5y ago
You can render OpenGL with C++ and compile it to Wasm but alsk have it build and run natively (Emscripten or your own bindings or whatever). So this can be a way to do both, while keeping the reach of web. Depends on what kind of application you're building and whether this makes sense for that, for sure.
twelvechairs 5y ago
Writing a native app for every conceivable platform someone might want to watch Prime Video on seems an awful lot of work
- titzer 5y ago
  "But why, though?" I keep asking myself, from a "how many darn buttons and doodads does it really need to have?" perspective. I suspect the issue is that people write entirely too much dang code to solve what is, after all, a fairly simple UI problem [1]. I mean, seriously. The Alto had less than a megabyte of RAM and managed to invent the GUI--menus, mouse, all. How have we managed to make this harder in 40 years? [1]...until Branding(tm) enters the chat.
  - bastawhiz 5y ago
    Because it's not just buttons and doodads, it's all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good. Title too long? Does it get truncated or shrunk? Does the UI reverse itself for RTL languages? Does the focus ring move in a sensible order? This is front end engineering. It's a whole profession, and when it's done poorly, folks think your software is garbage. Forty years ago half of the software was in English and required a specific screen resolution. Of COURSE it's going to be harder.
    - titzer 5y ago
      Frontend engineering is a thing because of the accidental complexity of a massive software stack that's evolved by accretion and gone through fad after fad after fad. I'm not looking down on frontend engineers, but I don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries.
      - nexuist 5y ago
        > don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. The work our shitty React apps sit on top of is unimaginably complex. It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app. It's not simple, at all. Especially not for a video streaming service! I mean, my God, just being able to understand the codecs and licensing issues would take you months, let alone writing decoders that run natively on every platform. Let alone dealing with monitors and color schemes and HDMI and Chromecast streaming and window resizing and bandwidth limits and buffering and.... It's not simple. EDIT: For reference, vim, a Hacker News favorite and widely considered one of the most popular TUIs ever built, is currently sitting at about 1.2 million lines of code. All it does is edit text files. Imagine if it had to play video.
lukasb 5y ago
Native apps are harder to update: https://news.ycombinator.com/item?id=30110265 https://news.ycombinator.com/item?id=30110265
ihuman 5y ago
The Uber app is naive, not React https://eng.uber.com/how-uber-deals-with-large-ios-app-size/ https://eng.uber.com/how-uber-deals-with-large-ios-app-size/
staticassertion 5y ago
I hope native apps die. Most companies won't put in the level of effort into their engineering that the Chrome/Firefox teams do - specifically, they're not going to take security as seriously.
- imwillofficial 5y ago
  That… escalated quickly
- ad-astra 5y ago
  Agreed! Why write a native app when you can just use Babel to transpile to Google Sheets formulas? Sure it doesn’t support threading but modern devices are so fast nowadays it doesn’t even matter.
madrox 5y ago
Between electron, webassembly, and other technologies, I don't think the line between web app and native app is as clear as it used to be, especially relative lift and performance. In the end, the only difference may be "one is launched in a browser and one is launched from the start menu"
- blacklion 5y ago
  It is very clear: are ALL controls which could be standard (provided by native OS toolkit) really standard (and respect system theming, customization, etc) and are ALL keyboard shortucts and other behaviors of OS standard toolkit supported? I don't care are code is native (as in compiled ahead of time / just in time / interpreted), but I'm care for behaviors and it consistency, both across one app and whole system. I'm forced to use Slack at $job, and it is awful, for example. Some text fields looks as text fields and are used as text fields, but don't respect "Shift+End/Home/Arrows" keyboard commands. Other does. It is annoying as hell. It is Electron. Even more «native» toolkits, like GTK and QT are have small discrepancies. Simple example: my Windows has English MUI (interface language) but Russian locale (time and date format, etc). In POSIX terms it is something like LC_MESSAGES=en_GB & LC_ALL=ru_RU (according to POSIX more specific categories have priority over LC_ALL). 95% of both QT-based and GTK-based software with translation to Russian speak Russian to me (and if I'm lucky has setting somewhere to enforce English). They think that «(system language)» is Russian. But it is not! It is not very «native», IMHO. Ok, GTK-based software is typicality build via cygwin/mingw, so it is really not very native and is «hacked» to run on Windows, but most of QT-based software IS build for Windows, as Windows is fully supported, tier 1 platform for QT. But still. If I start to write down all small nitpicks about cross-platform software, which shows that it it not native, I could find many in any cross-platform software. Corner cases in keyboard shortcuts, non-copyable messageboxes, strange tab behaviors, non-standard open/save/print dialogs, etc, etc, etc. If you use platform for 25+ years (yes, Windows changed a lot from 3.11 for Workgroups which was my first version, but these changes were small ones, step-by-step, and A LOT of things in UX didn't change still!), you have a shitton of muscle memory and all these nitpicks throw you off. Yes, I know, that there is no "native" toolkit for Linux. IMHO, it is a big problem, much bigger, that all problems of X11 which Wayland want to solve.
kmeisthax 5y ago
Uber is a bad example because they need to have support for literally every payment method on the planet. And all of that needs to be preloaded ahead of time just in case the user decides they're going to fly to Mumbai tomorrow. Their app absolutely needs to be bloated or it won't work at all. Likewise, Amazon needs to run on all sorts of different smart TV platforms, not just iOS and Android. All of those apps need to be consistent to each other, rather than to their host platforms. That's almost the textbook case for using a cross-platform framework.
- ksec 5y ago
  >And all of that needs to be preloaded ahead of time just in case the user decides they're going to fly to Mumbai tomorrow. This is Interesting. So essentially Uber is a "Global" App by default?
  - sofixa 5y ago
    Yes, that's why it works everywhere* with local specifics ( e.g. proposing tuk-tuks where available, or bike rentals where Uber have the service or a partner, etc.) directly without new downloads or anything. * of course where Uber are on the local market, i doubt it works in North Korea
- littlestymaar 5y ago
  > Uber is a bad example because they need to have support for literally every payment method on the planet. How is the breadth of their payment back-end and excuse for a bloated client?
- saagarjha 5y ago
  > Their app absolutely needs to be bloated or it won't work at all. It really doesn’t. I remember this being brought up back when the Uber engineer crying about how their compiler couldn’t match their scale was making the rounds, and in the end the numbers just did not add up to support the app size they have right now. > All of those apps need to be consistent to each other, rather than to their host platforms. Why? Platform-specific apps, for the most part, should feel at home on their platforms. Not doing this is how you get YouTube for Apple TV and similarly bad apps.
deleted 5y ago
[deleted]
shroompasta 5y ago
I disagree with this perspective. From a startup pov, going with native apps will require multiple teams (Usually just Android + iOS, but occasionally Windows as well) React Native will only require one team, or just one engineer depending on the size of the project Better yet, If your front end developer is fluent in React(web), then that developer is already fluent in React Native. I completely disagree on the "awful lot of work", when you could literally get your FE developer to work on your "native" apps. Sure, where performance must be squeezed, it's probably optimal to go native, but that bar is set a lot lower than where it actually should be. If React Native is good enough for Discord, it's good for 3 quarters of all apps out there.
- ad-astra 5y ago
  Former Dev that did Web -> Ionic -> RN -> Native iOS over the course of 6 years speaking here. - Web devs typically don’t have strong instincts for mobile apps, they require more mentorship & onboarding time. - Animation and interactivity is strongly limited in RN - You’re always so many levels removed from the actual APIs being used. For example, using UIKit and CoreAnimation are absolutely amazing and super lightweight on CPU/GPU in comparison. UICollectionView is a modern miracle that offers so much more control than FlatList. - JS/Babel/node_modules is hell, no I won’t elaborate. - Multi-threading, priority/concurrent queues etc for maintaining good all-around perf while doing intense operations is very strong with native platforms. RN just has sophisticated band-aids. Honestly it mostly depends on the type of work the app will be doing, the dev resources available to you, and the level of quality you want to attain. I strive to create the best of the best user experience, and native is the best way to attain that. The app I work on still uses RN for some features, but the results historically have been disappointing on average. Happy coding!
  - shroompasta 5y ago
    > Web devs typically don’t have strong instincts for mobile apps, they require more mentorship & onboarding time. I don't agree entirely. I do understand that there are differences in concerns regarding web and mobile, but the similarities overrun that of the differences, ESPECIALLY if they're working with react + rn. mentorship + onboarding time aren't words I would choose if a developer wanted to move from React to React Native - you make it sounds like a dev is joining a new company. > Animation and interactivity is strongly limited in RN - You’re always so many levels removed from the actual APIs being used. For example, using UIKit and CoreAnimation are absolutely amazing and super lightweight on CPU/GPU in comparison. UICollectionView is a modern miracle that offers so much more control than FlatList. Again performance is not something I will ever disagree with, the only part I disagree with is where people typically put that bar of "we need native because of performance" - It's a lot higher than most people think. Furthermore, your example of Flatlist in animations is confusing. A better example would probably be React Spring. Granted, RN animation is levels above, obviously, but it doesn't mean RN can't implement the same style of animations as native can https://twitter.com/VilacaRodolfo/status/1178351034051284993 https://twitter.com/VilacaRodolfo/status/1178351034051284993 > JS/Babel/node_modules is hell, no I won’t elaborate. ok > Multi-threading, priority/concurrent queues etc for maintaining good all-around perf while doing intense operations is very strong with native platforms. RN just has sophisticated band-aids. not arguing performance. that is always a given. Again, I will reiterate. If React Native is good enough for Discord, it's good enough for 3 quarters of mobile apps out there. Happy coding!
mrtksn 5y ago
HTML+JS+CSS is a very refined toolset for building UI that provides you with a content to consume. Sometimes, especially when the content is text, video and images, it’s actually easier to build high quality experience that works very well on all the platforms because it provides interaction modes out of the box that are the same everywhere. Native apps shine when you do something novel, something that’s beyond text, images and video consumption or you leverage platform specific functions. IMHO, sticking to Web technologies is a better option for things like Netflix or Amazon Prime but not good for Uber and alike.
Cthulhu_ 5y ago
For web & phones, I'm inclined to agree; a native app outperforms a web or hybrid app any day of the week. I do believe Facebook and Google are companies who ran into limitations though, binary size, number of classes / identifiers, build times, for which using web technology was a solution. But for TVs, ehh. There's a lot more fragmentation on the TV market. And if things were slightly different, we'd have a lot more fragmentation on the mobile market as well. Actually there are plenty of mobile alternatives, but developers don't really want to support all operating systems - and these cross-platform tools often have substandard support for mobile operating systems that aren't iOS or Android.

deleted 5y ago

[deleted]

Kaedon 5y ago

The challenge would be that Prime Video is distributed on many client devices. Here’s a list of a few TV OSes: https://en.m.wikipedia.org/wiki/List_of_smart_TV_platforms https://en.m.wikipedia.org/wiki/List_of_smart_TV_platforms. How would you manage a different native app for each of them? Caveat: previously worked at Prime Video though not in this area, still at Amazon

gjsman-1000 5y ago
I could be incorrect, but last time I did some reverse-engineering, Netflix had a Qt application that used native C++ bindings to knock out huge sections of that list. That Qt application was only lightly modified for each platform, IIRC, and it appeared all over the place from those cheap Linux-based Blu-ray players to Smart TV clients. Anywhere that was embedded, generally Linux-based, and unlikely to get frequent updates. As for some of the larger players like Roku or Android, those ones are more obvious where to hire. Java developers and BrightScript developers.
- mftb 5y ago
  It all kind of undermines your original comment tho that they're trying to avoid native. It seems more likely that they're goal is to reach as many devices as they can and be able to do updates frequently. In the first paragraph of the linked article the guy says the trade-off is between "updatability and performance".
  - nofunsir 5y ago
    I am really sick of fast-churn and forced updates. Guys. Settle. Write a native app or three. It’ll be ok.
    - remus 5y ago
      I think it's important not to conflate churn with fast updates. In it's essence the ability to deliver updates quickly (in this case by downloading a blob of wasm+js each time the app is started) is a great thing imo, as you eliminate a huge chunk of problems around delivering updates and clients on old versions. For 99% of users this is a huge win. You can obviously abuse this by redesigning the UI every 6 weeks but let's not throw the baby out with the bath water.
      - nofunsir 5y ago
        I'm of the strong opinion that there simply does not exist, as you say, 'a huge chunk of problems around delivering updates and clients on old versions.' It's certainly not a win for users, but for lazy developers. Good software engineers are much more than fast-churn developers. In fact, they are different people.
        progmetaldev 5y ago
        I'm 100% with you on this, but good software engineers are also much more expensive than fast-churn developers, and it seems to come down to how much spend these companies want to invest in their technology. There is just an overabundance of web developers out there, and the tech companies are taking advantage of that.
        remus 5y ago
        I guess we'll have to agree to disagree. I just don't see barriers in getting updates out to people as a good thing. It seems your argument is that it encourages developers to be sloppy, but in practice I think it just ends up as a net loss for users as the average user just isn't interested in updating software, however critical the bugs in their current version. Maybe I'm different from the average user, but for me the fact that chrome has gone through 90+ versions over 10+ years without me having to think about it is great (and, I suspect, strongly correlated to the relative lack of security issues over the years despite it having a huge surface area).

hashimotonomora 5y ago

It’s all about deployability.

systemvoltage 5y ago

I love native apps. But on the scale of Amazon (and having to compete with Netflix), slightest bit of friction, in this case downloading and installing an app, accepting permissions, etc takes a minute or two. It would be absolutely catastrophic to their competitiveness. You need to think more broadly on scale.

gjsman-1000 5y ago
If you read the original article, the use of WebAssembly is mainly across a broad array of device types where it will be packaged into an app. That app will require installation, accepting permissions, and all of that just like a native app. The point is moot except for anyone watching Prime Video in the web browser.
- vp8989 5y ago
  The WebAssembly component gets pulled on app startup. That means you make a bug fix, deploy a new build to an S3 bucket and every single user is running the fix inside of ~24 hours.

nikki93 5y ago

You can render OpenGL with C++ and compile it to Wasm but alsk have it build and run natively (Emscripten or your own bindings or whatever). So this can be a way to do both, while keeping the reach of web. Depends on what kind of application you're building and whether this makes sense for that, for sure.

twelvechairs 5y ago

Writing a native app for every conceivable platform someone might want to watch Prime Video on seems an awful lot of work

titzer 5y ago
"But why, though?" I keep asking myself, from a "how many darn buttons and doodads does it really need to have?" perspective. I suspect the issue is that people write entirely too much dang code to solve what is, after all, a fairly simple UI problem [1]. I mean, seriously. The Alto had less than a megabyte of RAM and managed to invent the GUI--menus, mouse, all. How have we managed to make this harder in 40 years? [1]...until Branding(tm) enters the chat.
- bastawhiz 5y ago
  Because it's not just buttons and doodads, it's all the error handling and loading indicators and UI edge cases that are needed to make it seamless and good. Title too long? Does it get truncated or shrunk? Does the UI reverse itself for RTL languages? Does the focus ring move in a sensible order? This is front end engineering. It's a whole profession, and when it's done poorly, folks think your software is garbage. Forty years ago half of the software was in English and required a specific screen resolution. Of COURSE it's going to be harder.
  - titzer 5y ago
    Frontend engineering is a thing because of the accidental complexity of a massive software stack that's evolved by accretion and gone through fad after fad after fad. I'm not looking down on frontend engineers, but I don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries.
    - nexuist 5y ago
      > don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. The work our shitty React apps sit on top of is unimaginably complex. It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app. It's not simple, at all. Especially not for a video streaming service! I mean, my God, just being able to understand the codecs and licensing issues would take you months, let alone writing decoders that run natively on every platform. Let alone dealing with monitors and color schemes and HDMI and Chromecast streaming and window resizing and bandwidth limits and buffering and.... It's not simple. EDIT: For reference, vim, a Hacker News favorite and widely considered one of the most popular TUIs ever built, is currently sitting at about 1.2 million lines of code. All it does is edit text files. Imagine if it had to play video.

lukasb 5y ago

Native apps are harder to update: https://news.ycombinator.com/item?id=30110265 https://news.ycombinator.com/item?id=30110265

ihuman 5y ago

The Uber app is naive, not React https://eng.uber.com/how-uber-deals-with-large-ios-app-size/ https://eng.uber.com/how-uber-deals-with-large-ios-app-size/

staticassertion 5y ago

I hope native apps die. Most companies won't put in the level of effort into their engineering that the Chrome/Firefox teams do - specifically, they're not going to take security as seriously.

imwillofficial 5y ago
That… escalated quickly
ad-astra 5y ago
Agreed! Why write a native app when you can just use Babel to transpile to Google Sheets formulas? Sure it doesn’t support threading but modern devices are so fast nowadays it doesn’t even matter.

madrox 5y ago

Between electron, webassembly, and other technologies, I don't think the line between web app and native app is as clear as it used to be, especially relative lift and performance. In the end, the only difference may be "one is launched in a browser and one is launched from the start menu"

blacklion 5y ago
It is very clear: are ALL controls which could be standard (provided by native OS toolkit) really standard (and respect system theming, customization, etc) and are ALL keyboard shortucts and other behaviors of OS standard toolkit supported? I don't care are code is native (as in compiled ahead of time / just in time / interpreted), but I'm care for behaviors and it consistency, both across one app and whole system. I'm forced to use Slack at $job, and it is awful, for example. Some text fields looks as text fields and are used as text fields, but don't respect "Shift+End/Home/Arrows" keyboard commands. Other does. It is annoying as hell. It is Electron. Even more «native» toolkits, like GTK and QT are have small discrepancies. Simple example: my Windows has English MUI (interface language) but Russian locale (time and date format, etc). In POSIX terms it is something like LC_MESSAGES=en_GB & LC_ALL=ru_RU (according to POSIX more specific categories have priority over LC_ALL). 95% of both QT-based and GTK-based software with translation to Russian speak Russian to me (and if I'm lucky has setting somewhere to enforce English). They think that «(system language)» is Russian. But it is not! It is not very «native», IMHO. Ok, GTK-based software is typicality build via cygwin/mingw, so it is really not very native and is «hacked» to run on Windows, but most of QT-based software IS build for Windows, as Windows is fully supported, tier 1 platform for QT. But still. If I start to write down all small nitpicks about cross-platform software, which shows that it it not native, I could find many in any cross-platform software. Corner cases in keyboard shortcuts, non-copyable messageboxes, strange tab behaviors, non-standard open/save/print dialogs, etc, etc, etc. If you use platform for 25+ years (yes, Windows changed a lot from 3.11 for Workgroups which was my first version, but these changes were small ones, step-by-step, and A LOT of things in UX didn't change still!), you have a shitton of muscle memory and all these nitpicks throw you off. Yes, I know, that there is no "native" toolkit for Linux. IMHO, it is a big problem, much bigger, that all problems of X11 which Wayland want to solve.

kmeisthax 5y ago

Uber is a bad example because they need to have support for literally every payment method on the planet. And all of that needs to be preloaded ahead of time just in case the user decides they're going to fly to Mumbai tomorrow. Their app absolutely needs to be bloated or it won't work at all. Likewise, Amazon needs to run on all sorts of different smart TV platforms, not just iOS and Android. All of those apps need to be consistent to each other, rather than to their host platforms. That's almost the textbook case for using a cross-platform framework.

ksec 5y ago
>And all of that needs to be preloaded ahead of time just in case the user decides they're going to fly to Mumbai tomorrow. This is Interesting. So essentially Uber is a "Global" App by default?
- sofixa 5y ago
  Yes, that's why it works everywhere* with local specifics ( e.g. proposing tuk-tuks where available, or bike rentals where Uber have the service or a partner, etc.) directly without new downloads or anything. * of course where Uber are on the local market, i doubt it works in North Korea
littlestymaar 5y ago
> Uber is a bad example because they need to have support for literally every payment method on the planet. How is the breadth of their payment back-end and excuse for a bloated client?
saagarjha 5y ago
> Their app absolutely needs to be bloated or it won't work at all. It really doesn’t. I remember this being brought up back when the Uber engineer crying about how their compiler couldn’t match their scale was making the rounds, and in the end the numbers just did not add up to support the app size they have right now. > All of those apps need to be consistent to each other, rather than to their host platforms. Why? Platform-specific apps, for the most part, should feel at home on their platforms. Not doing this is how you get YouTube for Apple TV and similarly bad apps.

deleted 5y ago

[deleted]

shroompasta 5y ago

I disagree with this perspective. From a startup pov, going with native apps will require multiple teams (Usually just Android + iOS, but occasionally Windows as well) React Native will only require one team, or just one engineer depending on the size of the project Better yet, If your front end developer is fluent in React(web), then that developer is already fluent in React Native. I completely disagree on the "awful lot of work", when you could literally get your FE developer to work on your "native" apps. Sure, where performance must be squeezed, it's probably optimal to go native, but that bar is set a lot lower than where it actually should be. If React Native is good enough for Discord, it's good for 3 quarters of all apps out there.

ad-astra 5y ago
Former Dev that did Web -> Ionic -> RN -> Native iOS over the course of 6 years speaking here. - Web devs typically don’t have strong instincts for mobile apps, they require more mentorship & onboarding time. - Animation and interactivity is strongly limited in RN - You’re always so many levels removed from the actual APIs being used. For example, using UIKit and CoreAnimation are absolutely amazing and super lightweight on CPU/GPU in comparison. UICollectionView is a modern miracle that offers so much more control than FlatList. - JS/Babel/node_modules is hell, no I won’t elaborate. - Multi-threading, priority/concurrent queues etc for maintaining good all-around perf while doing intense operations is very strong with native platforms. RN just has sophisticated band-aids. Honestly it mostly depends on the type of work the app will be doing, the dev resources available to you, and the level of quality you want to attain. I strive to create the best of the best user experience, and native is the best way to attain that. The app I work on still uses RN for some features, but the results historically have been disappointing on average. Happy coding!
- shroompasta 5y ago
  > Web devs typically don’t have strong instincts for mobile apps, they require more mentorship & onboarding time. I don't agree entirely. I do understand that there are differences in concerns regarding web and mobile, but the similarities overrun that of the differences, ESPECIALLY if they're working with react + rn. mentorship + onboarding time aren't words I would choose if a developer wanted to move from React to React Native - you make it sounds like a dev is joining a new company. > Animation and interactivity is strongly limited in RN - You’re always so many levels removed from the actual APIs being used. For example, using UIKit and CoreAnimation are absolutely amazing and super lightweight on CPU/GPU in comparison. UICollectionView is a modern miracle that offers so much more control than FlatList. Again performance is not something I will ever disagree with, the only part I disagree with is where people typically put that bar of "we need native because of performance" - It's a lot higher than most people think. Furthermore, your example of Flatlist in animations is confusing. A better example would probably be React Spring. Granted, RN animation is levels above, obviously, but it doesn't mean RN can't implement the same style of animations as native can https://twitter.com/VilacaRodolfo/status/1178351034051284993 https://twitter.com/VilacaRodolfo/status/1178351034051284993 > JS/Babel/node_modules is hell, no I won’t elaborate. ok > Multi-threading, priority/concurrent queues etc for maintaining good all-around perf while doing intense operations is very strong with native platforms. RN just has sophisticated band-aids. not arguing performance. that is always a given. Again, I will reiterate. If React Native is good enough for Discord, it's good enough for 3 quarters of mobile apps out there. Happy coding!

mrtksn 5y ago

HTML+JS+CSS is a very refined toolset for building UI that provides you with a content to consume. Sometimes, especially when the content is text, video and images, it’s actually easier to build high quality experience that works very well on all the platforms because it provides interaction modes out of the box that are the same everywhere. Native apps shine when you do something novel, something that’s beyond text, images and video consumption or you leverage platform specific functions. IMHO, sticking to Web technologies is a better option for things like Netflix or Amazon Prime but not good for Uber and alike.

Cthulhu_ 5y ago

For web & phones, I'm inclined to agree; a native app outperforms a web or hybrid app any day of the week. I do believe Facebook and Google are companies who ran into limitations though, binary size, number of classes / identifiers, build times, for which using web technology was a solution. But for TVs, ehh. There's a lot more fragmentation on the TV market. And if things were slightly different, we'd have a lot more fragmentation on the mobile market as well. Actually there are plenty of mobile alternatives, but developers don't really want to support all operating systems - and these cross-platform tools often have substandard support for mobile operating systems that aren't iOS or Android.