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.
> 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.
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.
> 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.
> 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.
Games on a browser are nearly impossible to monetize. They are fundamentally different to, say, a pizza-ordering app, which has monetization built-in. One exception could be MMORPGs, but in that case it's extremely difficult to avoid cheating, on a browser.
"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.
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.
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.
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).
Maybe not enough effort has gone into something as basic as ordering food online. Or rather it's such a simple problem that too many fragmented subpar options exists compared to web spreadsheets.
> 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.
Parsing is a tiny fraction of the time that a Web browser spends, and the various native resources are on the same level of complexity. TrueType hinting instructions from the 90s are of a similar complexity to the HTML 5 parsing spec.
> Go and fire up a windows 95 box, with 133mhx of pentium III goodness. THen make a VB6 app that animates boxes/shows images.
This will easily run at the same framerate on a modern Web rendering stack.
> 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.
Browsers on the Raspberry Pi B weren't accelerated, due to various reasons including Broadcom having (at the time) the worst GPU driver situation imaginable. You should compare against modern accelerated browsers (by "modern" meaning "within the last 20 years on mainstream OS's").
> 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.
Web apps have been able to run animations at 60 FPS for decades. (As an aside, the performance difference between CPython and native code is far more than 50%.)
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.
Nope, gifs only support binary transparency (transparent or opaque).
APNG would let you do frosted glass though. And I was expecting to add "but support is dire" but... actually it's not so bad? https://caniuse.com/?search=apng says 97%, only browsers with no support are legacy (IE and Opera mini), pretty much all browsers have supported it for years.
WebP and AVIF also have animation and alpha channel support, so these are also options.
Caveat emptor though, I don't have much experience with animation and alpha on any of these formats, so I don't know how buggy support is.
You can generate the gif dynamically. Unless you’re doing a lot of resizing, the one time cost of building the gif will amortize quickly across the total runtime of the animation.
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.
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?
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.