Mobile CPUs and the Performance Inequality Gap

Apple's decision doesn't apply to PWAs as clarified on a later update.

Plus updating the browser cache every couple of days isn't a big deal, native apps get store updates almost every day.

Assuming compute & bandwidth costs are fixed, are there any remaining justifications for doing SPA, et. al., especially if the server is required at all times in order to satisfy application requests? Is pushing a final compressed DOM over the wire really all that much worse than pushing 20 different JSON objects in order to recompose the same logical DOM client-side? Doesn't it seem like one of these approaches would be substantially faster and easier than the other in most cases?

I think we got off track somewhere around when cloud computing was introduced. I can see a huge motivating factor for pushing the "offload to client" narrative if your cloud compute portfolio provides 10% the relative cost-adjusted performance compared to a rack full of DL380s sitting in a colo. With the density of compute being offered today (e.g. 256 x86 cores in a 2U w/ 2TB ram), I feel a lot of businesses should start to look back to these approaches. The software and operating systems have vastly improved as well. Just take look at the performance you get with something like Kestrel in .Net Core:

https://www.techempower.com/benchmarks/#section=data-r18&hw=...

Nearly 7 million HTTP requests per second on a single 10GBe host. For 99% of business applications out there, just 1 of these servers is probably all you would ever need... A decade ago we were putting the finishing touches on 10k/second. Why the hell are we not aggressively trying to leverage this 100x speedup? Is it because all of this extra margin is being spread thin by Amazon, et. al for purposes of maximum profit extraction? Or, is there a more nuanced game afoot?

And you might say those kinds of applications shouldn’t be built on the web but I’d rather have them on the web than locked up in some proprietary app store with all the centralization and potential abuses of power that allows.

H.265 support in graphics cards and consumer processors has laughably lacked behind on mobile, probably because of licensing.

There's also the fact that a lot of video applications on Windows don't enable hardware decoding by default out of fear of encountering buggy drivers or hardware.

On mobile there's basically only one way to decode video, which makes use of all the phone's dedicated hardware, while on desktop applications can use a wide variety of codecs. Then comes the decision whether to decode on the CPU or GPU, as both have hardware decoding support these days, or to fall back to software decoding because the specific combination of codec and bit depth wasn't supported by the hardware of choice.

Then there's the fact that Apple logically encodes video the camera records into a format that iMovie is well optimised for. If you encode video with your PC's GPU, it'll probably be just as snappy playing back while the iPhone video might still be struggling.

The Bionic chips aren't cheating to a win. They win GeekBench, and virtually any other cross-platform activity that you can throw at them. As I mentioned in another post, my iPhone 11 absolutely lays waste to my laptop with an i7-7700HQ processor at the JetStream 2 benchmark. Now this is a JavaScript benchmark that runs on completely different software stacks / OS / etc (my i7 running Windows 10, Chrome 80, etc), but it is layers and layers of dependencies on the performance of the platform. And my big beefy i7 is beaten by a tiny little mobile processor. It is quite remarkable.

It's a blazingly fast little processor. We would probably have seen them use them in other hardware sooner if Apple wasn't always suspicious that Intel was sandbagging in some way and was ready to wow the industry.