A REST API is really an app specific network protocol that happens to build on HTTP instead of TCP. It's not actually an API in the sense we're talking about above. Most obviously there's no standard way for a web server to say "I implement this standard typed interface X", and even if there was, there's no way to ask browsers to enumerate all the web apps the user "has" that implements interface X because browsers don't have any notion of a user "having" an app to begin with. That's sometimes beneficial, and sometimes it just means things can't integrate with each other.

In contrast stuff like DCOM/OLE supported tons of features that REST doesn't even try to address so it's an apples/oranges comparison to a large extent.

Don't get me wrong - decoupling the app APIs from the underlying operating systems has advantages, and I'm not trying to bring DCOM back, but clearly the advantages aren't that huge because on mobile a more modern take on the exact same concepts stomped web tech completely. Everyone wants native Android/iOS apps and they want them so badly that companies will write the same app frontend twice to satisfy that need.

"The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction."

True, but this is engineering. There are always tradeoffs. It gets this zero distribution friction by simply ignoring any use cases that don't fit its document-oriented model. Most obviously, every approach to making the web support poor or non-existent connectivity is terrible and has never gained traction, but that's a problem. Many, many apps need to be able to run offline. Anything that manages a critical process of any kind simply cannot handle being served from the cloud as a web app:

• Industrial control

• Medical

• Servers themselves

• Military

• Much gaming (you play games when you're bored, why are you bored, maybe because you don't have the internet ...)

• Anything to do with managing the network itself

• Anything where latency is critical (can't beat the speed of light)

• Airgapped for security

etc. Apps in these fields don't just experience friction when trying to use the web, they experience a brick wall.

Then there are the many, many apps that struggle to ram their square pegs into the round hole of a browser, e.g. embedded devices struggle because browsers won't automatically discover them, because browsers are slowly turning the screws on requiring TLS but the TLS model doesn't really work for embedded devices you connect to locally. Developer tools. And so on and so forth.

Finally, there are other common distribution use cases browsers don't even try to support:

• Downgrading if the server ships a regression. "Regression" doesn't have to mean bug or outage, it can mean deliberate UI redesign, hence all the screaming whenever web apps change their UI layouts. Your workforce productivity can drop overnight because some SaaS shipped a new UI nobody asked for, and you're just screwed at that point. If it didn't come at a good time for your business or the new version is a downgrade for you, once again the web cordially invites you to try pounding sand. It might help you feel better.

• Apps that aren't controlled by a single organization (hence why web apps suck for the blockchain/decentralization community - Bitcoin 0.1 wasn't a web app for good reasons).

• Apps that need to keep working even if the originating organization goes bankrupt.

• Apps that need to separate data storage from software distribution. The origin concept doesn't make this easy.

A lot of companies in the mobile world are basically wishing mobile apps were distributed like web apps were, and the mobile world is going towards a web like distribution model slowly with things like android dynamic features and app clips.

Web apps are infinitely expandable, instant rollbacks and roll outs and no need for an update & app store review cycle which can add weeks of delays between code complete and landing on a user's doorstep. Because updates are not instant, you have to delay a lot longer in deploys than you would in an equivalent web app.

You could also hack it today via dynamic libraries that you update on demand via a supervisor shell for your actual app. There is nothing necessary with browsers and web specific tech to do all of the above.

Yes, there are lots of benefits to having apps be streamed on demand with an open world approach. I'm not trying to argue that mobile distribution is universally better, just observing that people have a choice there and they avoid the web platform. Effectively trading a different distribution model, maybe a worse one, for other benefits.

"Web apps are infinitely expandable, instant rollbacks and roll outs and no need for an update & app store review cycle which can add weeks of delays between code complete and landing on a user's doorstep"

This is an advantage for developers and may or may not be an advantage for users, depending on whether the upgrade is truly an upgrade or not. Web SaaS firms simply pretend their software always gets better and any disagreement is mere "change aversion" but their incentives aren't always aligned with the end users, many of whom may simply not need new versions. The web can't handle this scenario because browsers have no understanding of version numbers to begin with.

No they don't have a choice in the mobile world. Google and apple defacto decide the distribution model and place a lot of restrictions on how you can distribute updates to your app, forcing people into a specific model on how to do app updates. Certain web features that would make web apps significantly more competitive to mobile apps stay unimplemented on the apple platforms, which if you follow some webdevs on twitter see them complain constantly about.

Apple explicitly does not allow unreviewed binary code downloads, but do allow a sort of gimped version with javascript. If apps could manage their own update cycles and methods, you'd be seeing a lot more of this dynamic behavior today vs. the half solutions that are things like react native and homegrown equivalent. I wouldn't be surprised if android has similar restrictions here and there.

Also further more, it's not really devs / engineers that want these instant testing cycles, but PMs and businesses. Businesses want it because it lets them execute faster and make more money via faster A/B test cycles and lose less money from client side outages via much faster rollbacks. The cultural appetite for this is voracious and it's because of that business side demand I don't see it going away. Eventually software is going to need a internet connection whether you like it or not and there won't really be any such thing as version numbers anymore for the vast majority of software.

It's basically Darwinian evolution, because it makes more money and users don't really think about versions or updates that much at all unless special marketing is done to make differentiation of versions. Like evolution, the solution might be unpleasant, but it stays in place if it is effective.

People do have a choice on mobile. They can make web apps or native apps and they choose native. You can blame Apple for not implementing every last web standard, but Google definitely do, and people make native Android apps in preference to web apps too. So clearly the web isn't all that competitive when put up against motivated OS teams. Windows hasn't had that for a long time, nor has Linux or macOS (not motivated in the right way) so the Chrome guys have taken over there.

Still, it's just not the case that the web would win if not for Apple. And "I wouldn't be surprised if android has similar restrictions here and there", well, be surprised. Android allows side-loading as a condition of licensing it, which allows self-updating apps. Telegram do this for example. They've also added features for app streaming to the Play Store and so on.

Fast rollouts and A/B testing isn't something specific to the web, it just happens to be a consequence of how it works. As for client side outages, well, that's really something that we associate with web apps. I've never had a sudden outage of a desktop or mobile app unless it was just a frontend for a service that went away. Updates can contain bugs but updates so broken they take everything down - no, doesn't happen, gets picked up in testing and/or during the incremental rollout because not everyone updates at once. Whereas it happens to web apps pretty regularly.