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.
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 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.
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.
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.
Many apps are fine as web apps without any OS support at all.
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.
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. )
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.
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%.)