6 ms·

> The implication is clear: browsers unchained can do to mobile what the web did to desktop, where more than 70% of daily "jobs to be done" happen on the web.

> The implication is clear: browsers unchained can do to mobile what the web did to desktop, where more than 70% of daily "jobs to be done" happen on the web. This was an actual debate in the early days of app stores. Facebook was the most prominent company that decided to go with an HTML5 app instead of a native one. Doing so was one of the biggest strategic mistakes they've ever made. Zuck's words, not mine. (https://www.engadget.com/2012-09-11-zuckerberg-html-5-facebook-mobile-app-mistake.html https://www.engadget.com/2012-09-11-zuckerberg-html-5-facebo...). Web apps were slower, had issues dealing with the various browsers and saw less use. It doesn't seem like the author has done any real research here.

qgin 3y ago
There's no technical reason this needs to be true though. It's wild that I can use a full-featured spreadsheet instantly on the web on my laptop, but on my phone someone wants me to download a 100mb binary to order a pizza.
- EA-3167 3y ago
  I've always assumed it was by design, because you can't use ad blockers or privacy addons in an app.
- outworlder 3y ago
  These days they will ask you to download 100MB of JS, CSS, HTML and assets to order the same pizza.
  - rezmason 3y ago
    That is a real problem. But if that problem manifests in web and native software alike, then neither the web nor the app stores directly cause it, right?
- Eridrus 3y ago
  "My highly abstract cross-platform framework must be as fast as native code" is not a sane view on this. A tonne of effort has gone into making spreadsheets work on the web; both in the browsers as well as the spreadsheet apps themselves. The fact that the web works as well as it does is a huge feat of engineering, but in no way indicative of there being no technical reason that native apps can be better.
  - qgin 3y ago
    The vast majority of apps are just text, images, and buttons. Maybe a video player if you're getting wild. Not really anything that requires processing speed except to just render stuff on a screen and wait for touches. They don't need feats of engineering to run well.
    - Eridrus 3y ago
      "Many apps are fine as PWAs" and "there is no technical reason for an app" are very different statements. Many apps are fine as web apps without any OS support at all.
      - qgin 3y ago
        I should have been more specific. There's no technical reason for binary apps to be the dominant form of apps on phones, given that most apps are pretty simple experiences.
        skydhash 3y ago
        No technical reason, but I don't see iOS and Android settling on a standard framework for doing native applications and setting a specification for frameworks (localization, camera capture, audio playbacks, and other apis). The web is great, but only when you treat each page as a documents (interactive). Anytime you break out of this, you find yourself in a whole suit of problems as there is no easy way to fit both experiences in the same application (responsive design is not the solution).
- KaiserPro 3y ago
  > There's no technical reason this needs to be true though. yes, yes there is. HTML/JS is a bastard to parse. it takes a fucktonne of resources to actually figure out how to render a box. Go and fire up a windows 95 box, with 133mhx of pentium III goodness. THen make a VB6 app that animates boxes/shows images. Look how fucking fast it can do it (and vb6 wasn't a fast language) Or, more easily, render a web page on the original raspberry pi-b, try and play video in a browser, do some sort of animation. It lags like a fucker. Use py-game (you know python with its 50% "what fucking type is this?" tax) and you can run animations at 60fps. The web is slow, its just moore's law has shielded us from it.
  - qgin 3y ago
    It's true, but a current version of a native app has minimum OS version requirements that make running on an old phone impossible. If you're just willing to have the same hardware requirements for mobile web, you've got hardware that can render text and images and buttons just fine.
    - KaiserPro 3y ago
      To render text in a browser, you are looking at a 10x cost in power. to animate anything, you are looking at 100x cost in power. This means that you will drain the battery much much faster than with native. The solution is not using webtools, its making native much more open/portable. you know like java was supposed to be (kinda like how APKs are now. )
      - amadeuspagel 3y ago
        If you render text in a browser, you have support for selection, translation, links that the user can open either in the same or in a new tab ...
  - hmottestad 3y ago
    Animations suck up so much resources. I have a PWA where I wanted a pulsating button with a frosted glass effect. I had to remove it cause it was using 20% of a single CPU core. After removing it the app is only using 6%, just sitting idle, which is about 6% more than any other native app on my Mac.
- hmottestad 3y ago
  I haven’t seen any AAA games that are developed to work in a browser. I also believe that a lot of APIs in iOS are not available from PWAs. If someone invested a lot of time and money into making PWAs work great then there shouldn’t be any technical reasons for why you should choose to develop a native app instead of a PWA. At the moment we are lacking in tooling and language support and also leaving a lot of performance on the table. I love how easy it is to get up and running with a PWA and most of my front end stuff is using PWAs today. From a technical standpoint it still needs a lot of work from the vendor side though.
  - meheleventyone 3y ago
    > I haven’t seen any AAA games that are developed to work in a browser. I think Stadia worked over the browser to deliver AAA games. There’s obviously a whole bunch of missing technology needed to deliver (and later patch) huge web apps locally though. Plus annoying browser limits like the hard kill based on memory usage in mobile Safari.
  - dwaite 3y ago
    > I also believe that a lot of APIs in iOS are not available from PWAs. The security model of a store is delegated trust and stewardship. There is someone who will review if applications need capabilities, and will provide business penalties for bad behaviors. The security model of the web is basically a mix of site sandboxing and caveat emptor. There is no guarantee the web app you hit one minute to the next will be the same code base, or belong to the same owner. For example, the same interface has to get consent for notifications from an advertising site which wants to spam you as your corporate chat app. Chrome had quite a bit more motivation to ignore this or to create a tiered model with PWAs because of Chromebooks, where the model (originally) was web-only development. Google created quite a few one-off API for their systems, and promoted several Chrome-only API as if they were web standards. Even there, this approach was too limiting and eventually Android compatibility was added. Apple has started to add some additional app-useful features like notifications, but behind the 'Add to Home Screen' option. One could look at this like promoting a website to an 'app' on the phone, partially because that gives a consistent way for the user to understand permissions and privacy implications for both native and web code. There are plenty of people who wish there was a better mechanism on iOS than the current add to Home Screen flow, but it is highly unlikely to become more streamlined because of abuse potential.
- dwaite 3y ago
  > It's wild that I can use a full-featured spreadsheet instantly on the web on my laptop, but on my phone someone wants me to download a 100mb binary to order a pizza Google Sheets is now basically a window-sized canvas element, with its own non-native control libraries. I suspect it is not using browser font rendering. That puts it effectively back into Windows 3.1 days of bitblt graphics, being driven by a difficult to optimize, dynamic language. It is indeed wild that desktops are good enough to be able to drive such a thing with such performance. However, there is plenty of reason to rely on native frameworks with modern graphics systems. I suspect there were radically different levels of engineering and optimization that went into Google Sheets vs a typical pizza-ordering app. Even with the same level of engineering, I suspect the pizza ordering app would be larger due to the need to bundle media like pizza and topping images.
amadeuspagel 3y ago
Maybe a few things changed since 2012.
chimeracoder 3y ago
> This was an actual debate in the early days of app stores. Facebook was the most prominent company that decided to go with an HTML5 app instead of a native one. Doing so was one of the biggest strategic mistakes they've ever made. That was over a decade ago. Back then, Youtube was still using Flash (the HTML5 beta was only around a year old), JavaScript engines were way slower, Chrome was still using WebKit... HTML5 today is not what it was in 2011. Even putting aside the fact that the web was "slower" in part because of the decisions mentioned in the article that are intended to encourage native app design, it's not a foregone conclusion that the same is true today.
yodon 3y ago
The state of the art 12 years ago and the state of the art today are generally quite different things.
echelon 3y ago
Maybe if Apple didn't purposely deliver a slow, dated browser and force it to be the only one. The cellphone duopoly is using their power to make sure the web cannot match native. That's how they make their gobs of money that hasn't been subject to real competition. They get a free rake off of the innovation of others. If you allow web downloads of apps with no store and no scare wall, companies will develop better / native-level browsers. They'll happily chip away at Google and Apple. With WASM, we have the tech. As soon as it goes multithreaded, it's game over for native apps. (So long as the DOJ clears the runway and forces these companies to allow fair competition and progress.)
- politelemon 3y ago
  I'm thinking that if Python becomes "easy to pick up" to do WASM development, it could go a long way towards helping PWAs thrive. I'm not very familiar with WASM but most tutorials seem to be around C/C++, Rust, or C#, so I wonder if there's something holding back Python + WASM. I only mention Python because of its current popularity and accessibility to the masses.
  - echelon 3y ago
    I think something like https://dioxuslabs.com https://dioxuslabs.com could deliver native, cross platform apps and win back mobile. YC made a good bet here.
    - firecall 3y ago
      How does one pronounce Dioxus?
      - echelon 3y ago
        IIRC, it's inspired by this [1], so maybe the same? [1] https://pokemon.fandom.com/wiki/Deoxys https://pokemon.fandom.com/wiki/Deoxys
  - jacobr1 3y ago
rezmason 3y ago
Them's citin' words! Are you sure you're as well-versed as you portray yourself to be? The article which you linked to is from 2012; it pertains to the performance of Facebook's web client in 2010, when run on mobile devices in 2010. Most apps today can be implemented as progressive web apps, without any user experience penalty. Instead, they are built with tools that lock developers into a platform of one type or another. That's because some handset manufacturers prioritize the platforms that have lock-in, such as the App Store and iMessage, over the platforms that do not, such as the web and RCS. It is not because the web is somehow a bad platform for apps. If you want FaceTime to call your mom on her headset when your watch detects a spike in your heart rate, then yes, you may want to write a native app to do that. But Sudoku, Pandora and the McDonald's app can live on the web, and so can most of the rest.
- KaiserPro 3y ago
  > Most apps today can be implemented as progressive web apps, without any user experience penalty yeah nah, the FT, the bastion of PWAs because of the "if you have a subscription, we'll take 25% of that thanks" flipped to native almost as soon as the rules changed. why? because the user experience sucked bollocks. It was slow, memory hog, and a massive massive bollockache to maintain. Don't get me wrong, thats not because they were bad at making the web app, its because the tech isn't up to scratch.
  - rezmason 3y ago
    Are you talking about this? https://enterprise.ft.com/en-gb/blog/ft-app-now-available-ios/ https://enterprise.ft.com/en-gb/blog/ft-app-now-available-io... This says they just wrapped their web app in a native app, like a web view, so they could then use system features that their web apps couldn't access. So are you sure you're not using a web app after all? You might be using the same tech as you were before.
modeless 3y ago
How's this for research: In 2011, when Facebook tried HTML5 for their app, an iPhone 4 ran the Sunspider JavaScript benchmark in a little over ten seconds according to Anandtech. Today we stopped using Sunspider because phones and browsers are so much faster there's no point to it, but an iPhone runs Sunspider in ~70ms. 150 times faster! And today we have APIs for camera, storage, video, 3D, notifications, threads, WASM, etc that didn't exist back then either. When developers can save 30% by going with the web, that's a real big incentive to explore the new performance and new APIs the web has today...
mnot 3y ago
LOL. Do you know who you’re talking about?
hobobaggins 3y ago
That was because Apple had gone out of its way to keep all of the best native functionality available only to native apps. Facebook is not a complicated front-end application (or it wasn't back then), so it should have been possible, but you couldn't even upload photos until iOS 6. It's amazing and audacious that Zuck even attempted it at all, in hindsight.
rchaud 3y ago
> Web apps were slower, had issues dealing with the various browsers and saw less use. Apps like Facebook are constantly preloading data in the background to fill your feed immediately on app launch. 99pct of web apps would not have that need fortunately. And let's be real, FB went with native apps because they could quietly hide app permissions that a web browser would warn you about with a big scary dialog window. That would be catastrophic for the world's biggest targeted advertising company. They ran a full page ad when Apple started requiring app tracking disclosures on iOS.
kevingadd 3y ago
Aside from your point about Facebook, "It doesn't seem like the author has done any real research here" is kind of a weird comment to make about a veteran browser dev who's been on web standards committees for over a decade.
fennecfoxy 3y ago
Funnily enough, Steve Jobs/Apple didn't even want an app store or native apps to begin with. It was gonna be only preinstalled apps + 3rd party web apps. Hell he had to be convinced to even allow non-Apple 3rd party apps in the first place. I don't think web apps are the future, but I also don't see why there can't be a more protected mode/sandbox for non app store sourced content to run in. Nobody has solved this yet - why can I visit pretty much any website and (mostly) be completely safe, yet I can't install any old random APK? Hell, it should be possible to jump from the web into native code with a single click by now, why tf not. The only good thing the app stores are good for is to serve up apps that are "more trusted" (even tho app stores constantly have a couple bad actor apps on em) as well as centralised place to easily find stuff (the reason people use Google). I guess the real problem with sandboxing/permissions systems is that users don't know what's good for them; my Tiktok loving friends would just hit "yes, yes, yes" to any dialog that says "TT wants to know your shoe size".

qgin 3y ago

There's no technical reason this needs to be true though. It's wild that I can use a full-featured spreadsheet instantly on the web on my laptop, but on my phone someone wants me to download a 100mb binary to order a pizza.

EA-3167 3y ago
I've always assumed it was by design, because you can't use ad blockers or privacy addons in an app.
outworlder 3y ago
These days they will ask you to download 100MB of JS, CSS, HTML and assets to order the same pizza.
- rezmason 3y ago
  That is a real problem. But if that problem manifests in web and native software alike, then neither the web nor the app stores directly cause it, right?
Eridrus 3y ago
"My highly abstract cross-platform framework must be as fast as native code" is not a sane view on this. A tonne of effort has gone into making spreadsheets work on the web; both in the browsers as well as the spreadsheet apps themselves. The fact that the web works as well as it does is a huge feat of engineering, but in no way indicative of there being no technical reason that native apps can be better.
- qgin 3y ago
  The vast majority of apps are just text, images, and buttons. Maybe a video player if you're getting wild. Not really anything that requires processing speed except to just render stuff on a screen and wait for touches. They don't need feats of engineering to run well.
  - Eridrus 3y ago
    "Many apps are fine as PWAs" and "there is no technical reason for an app" are very different statements. Many apps are fine as web apps without any OS support at all.
    - qgin 3y ago
      I should have been more specific. There's no technical reason for binary apps to be the dominant form of apps on phones, given that most apps are pretty simple experiences.
      - skydhash 3y ago
        No technical reason, but I don't see iOS and Android settling on a standard framework for doing native applications and setting a specification for frameworks (localization, camera capture, audio playbacks, and other apis). The web is great, but only when you treat each page as a documents (interactive). Anytime you break out of this, you find yourself in a whole suit of problems as there is no easy way to fit both experiences in the same application (responsive design is not the solution).
KaiserPro 3y ago
> There's no technical reason this needs to be true though. yes, yes there is. HTML/JS is a bastard to parse. it takes a fucktonne of resources to actually figure out how to render a box. Go and fire up a windows 95 box, with 133mhx of pentium III goodness. THen make a VB6 app that animates boxes/shows images. Look how fucking fast it can do it (and vb6 wasn't a fast language) Or, more easily, render a web page on the original raspberry pi-b, try and play video in a browser, do some sort of animation. It lags like a fucker. Use py-game (you know python with its 50% "what fucking type is this?" tax) and you can run animations at 60fps. The web is slow, its just moore's law has shielded us from it.
- qgin 3y ago
  It's true, but a current version of a native app has minimum OS version requirements that make running on an old phone impossible. If you're just willing to have the same hardware requirements for mobile web, you've got hardware that can render text and images and buttons just fine.
  - KaiserPro 3y ago
    To render text in a browser, you are looking at a 10x cost in power. to animate anything, you are looking at 100x cost in power. This means that you will drain the battery much much faster than with native. The solution is not using webtools, its making native much more open/portable. you know like java was supposed to be (kinda like how APKs are now. )
    - amadeuspagel 3y ago
      If you render text in a browser, you have support for selection, translation, links that the user can open either in the same or in a new tab ...
- hmottestad 3y ago
  Animations suck up so much resources. I have a PWA where I wanted a pulsating button with a frosted glass effect. I had to remove it cause it was using 20% of a single CPU core. After removing it the app is only using 6%, just sitting idle, which is about 6% more than any other native app on my Mac.
hmottestad 3y ago
I haven’t seen any AAA games that are developed to work in a browser. I also believe that a lot of APIs in iOS are not available from PWAs. If someone invested a lot of time and money into making PWAs work great then there shouldn’t be any technical reasons for why you should choose to develop a native app instead of a PWA. At the moment we are lacking in tooling and language support and also leaving a lot of performance on the table. I love how easy it is to get up and running with a PWA and most of my front end stuff is using PWAs today. From a technical standpoint it still needs a lot of work from the vendor side though.
- meheleventyone 3y ago
  > I haven’t seen any AAA games that are developed to work in a browser. I think Stadia worked over the browser to deliver AAA games. There’s obviously a whole bunch of missing technology needed to deliver (and later patch) huge web apps locally though. Plus annoying browser limits like the hard kill based on memory usage in mobile Safari.
- dwaite 3y ago
  > I also believe that a lot of APIs in iOS are not available from PWAs. The security model of a store is delegated trust and stewardship. There is someone who will review if applications need capabilities, and will provide business penalties for bad behaviors. The security model of the web is basically a mix of site sandboxing and caveat emptor. There is no guarantee the web app you hit one minute to the next will be the same code base, or belong to the same owner. For example, the same interface has to get consent for notifications from an advertising site which wants to spam you as your corporate chat app. Chrome had quite a bit more motivation to ignore this or to create a tiered model with PWAs because of Chromebooks, where the model (originally) was web-only development. Google created quite a few one-off API for their systems, and promoted several Chrome-only API as if they were web standards. Even there, this approach was too limiting and eventually Android compatibility was added. Apple has started to add some additional app-useful features like notifications, but behind the 'Add to Home Screen' option. One could look at this like promoting a website to an 'app' on the phone, partially because that gives a consistent way for the user to understand permissions and privacy implications for both native and web code. There are plenty of people who wish there was a better mechanism on iOS than the current add to Home Screen flow, but it is highly unlikely to become more streamlined because of abuse potential.
dwaite 3y ago
> It's wild that I can use a full-featured spreadsheet instantly on the web on my laptop, but on my phone someone wants me to download a 100mb binary to order a pizza Google Sheets is now basically a window-sized canvas element, with its own non-native control libraries. I suspect it is not using browser font rendering. That puts it effectively back into Windows 3.1 days of bitblt graphics, being driven by a difficult to optimize, dynamic language. It is indeed wild that desktops are good enough to be able to drive such a thing with such performance. However, there is plenty of reason to rely on native frameworks with modern graphics systems. I suspect there were radically different levels of engineering and optimization that went into Google Sheets vs a typical pizza-ordering app. Even with the same level of engineering, I suspect the pizza ordering app would be larger due to the need to bundle media like pizza and topping images.

amadeuspagel 3y ago

Maybe a few things changed since 2012.

chimeracoder 3y ago

> This was an actual debate in the early days of app stores. Facebook was the most prominent company that decided to go with an HTML5 app instead of a native one. Doing so was one of the biggest strategic mistakes they've ever made. That was over a decade ago. Back then, Youtube was still using Flash (the HTML5 beta was only around a year old), JavaScript engines were way slower, Chrome was still using WebKit... HTML5 today is not what it was in 2011. Even putting aside the fact that the web was "slower" in part because of the decisions mentioned in the article that are intended to encourage native app design, it's not a foregone conclusion that the same is true today.

yodon 3y ago

The state of the art 12 years ago and the state of the art today are generally quite different things.

echelon 3y ago

Maybe if Apple didn't purposely deliver a slow, dated browser and force it to be the only one. The cellphone duopoly is using their power to make sure the web cannot match native. That's how they make their gobs of money that hasn't been subject to real competition. They get a free rake off of the innovation of others. If you allow web downloads of apps with no store and no scare wall, companies will develop better / native-level browsers. They'll happily chip away at Google and Apple. With WASM, we have the tech. As soon as it goes multithreaded, it's game over for native apps. (So long as the DOJ clears the runway and forces these companies to allow fair competition and progress.)

politelemon 3y ago
I'm thinking that if Python becomes "easy to pick up" to do WASM development, it could go a long way towards helping PWAs thrive. I'm not very familiar with WASM but most tutorials seem to be around C/C++, Rust, or C#, so I wonder if there's something holding back Python + WASM. I only mention Python because of its current popularity and accessibility to the masses.
- echelon 3y ago
  I think something like https://dioxuslabs.com https://dioxuslabs.com could deliver native, cross platform apps and win back mobile. YC made a good bet here.
  - firecall 3y ago
    How does one pronounce Dioxus?
    - echelon 3y ago
      IIRC, it's inspired by this [1], so maybe the same? [1] https://pokemon.fandom.com/wiki/Deoxys https://pokemon.fandom.com/wiki/Deoxys
- jacobr1 3y ago

rezmason 3y ago

Them's citin' words! Are you sure you're as well-versed as you portray yourself to be? The article which you linked to is from 2012; it pertains to the performance of Facebook's web client in 2010, when run on mobile devices in 2010. Most apps today can be implemented as progressive web apps, without any user experience penalty. Instead, they are built with tools that lock developers into a platform of one type or another. That's because some handset manufacturers prioritize the platforms that have lock-in, such as the App Store and iMessage, over the platforms that do not, such as the web and RCS. It is not because the web is somehow a bad platform for apps. If you want FaceTime to call your mom on her headset when your watch detects a spike in your heart rate, then yes, you may want to write a native app to do that. But Sudoku, Pandora and the McDonald's app can live on the web, and so can most of the rest.

KaiserPro 3y ago
> Most apps today can be implemented as progressive web apps, without any user experience penalty yeah nah, the FT, the bastion of PWAs because of the "if you have a subscription, we'll take 25% of that thanks" flipped to native almost as soon as the rules changed. why? because the user experience sucked bollocks. It was slow, memory hog, and a massive massive bollockache to maintain. Don't get me wrong, thats not because they were bad at making the web app, its because the tech isn't up to scratch.
- rezmason 3y ago
  Are you talking about this? https://enterprise.ft.com/en-gb/blog/ft-app-now-available-ios/ https://enterprise.ft.com/en-gb/blog/ft-app-now-available-io... This says they just wrapped their web app in a native app, like a web view, so they could then use system features that their web apps couldn't access. So are you sure you're not using a web app after all? You might be using the same tech as you were before.

modeless 3y ago

How's this for research: In 2011, when Facebook tried HTML5 for their app, an iPhone 4 ran the Sunspider JavaScript benchmark in a little over ten seconds according to Anandtech. Today we stopped using Sunspider because phones and browsers are so much faster there's no point to it, but an iPhone runs Sunspider in ~70ms. 150 times faster! And today we have APIs for camera, storage, video, 3D, notifications, threads, WASM, etc that didn't exist back then either. When developers can save 30% by going with the web, that's a real big incentive to explore the new performance and new APIs the web has today...

mnot 3y ago

LOL. Do you know who you’re talking about?

hobobaggins 3y ago

That was because Apple had gone out of its way to keep all of the best native functionality available only to native apps. Facebook is not a complicated front-end application (or it wasn't back then), so it should have been possible, but you couldn't even upload photos until iOS 6. It's amazing and audacious that Zuck even attempted it at all, in hindsight.

rchaud 3y ago

> Web apps were slower, had issues dealing with the various browsers and saw less use. Apps like Facebook are constantly preloading data in the background to fill your feed immediately on app launch. 99pct of web apps would not have that need fortunately. And let's be real, FB went with native apps because they could quietly hide app permissions that a web browser would warn you about with a big scary dialog window. That would be catastrophic for the world's biggest targeted advertising company. They ran a full page ad when Apple started requiring app tracking disclosures on iOS.

kevingadd 3y ago

Aside from your point about Facebook, "It doesn't seem like the author has done any real research here" is kind of a weird comment to make about a veteran browser dev who's been on web standards committees for over a decade.

fennecfoxy 3y ago

Funnily enough, Steve Jobs/Apple didn't even want an app store or native apps to begin with. It was gonna be only preinstalled apps + 3rd party web apps. Hell he had to be convinced to even allow non-Apple 3rd party apps in the first place. I don't think web apps are the future, but I also don't see why there can't be a more protected mode/sandbox for non app store sourced content to run in. Nobody has solved this yet - why can I visit pretty much any website and (mostly) be completely safe, yet I can't install any old random APK? Hell, it should be possible to jump from the web into native code with a single click by now, why tf not. The only good thing the app stores are good for is to serve up apps that are "more trusted" (even tho app stores constantly have a couple bad actor apps on em) as well as centralised place to easily find stuff (the reason people use Google). I guess the real problem with sandboxing/permissions systems is that users don't know what's good for them; my Tiktok loving friends would just hit "yes, yes, yes" to any dialog that says "TT wants to know your shoe size".