The web got it because for some _insane_ reason, websites were able to convince IT departments to allow scripts to run.

That left the barn door unlocked. Suddenly the download everything every time (or hope some is at least cached) environment of JavaScript / ECMAScript became the ONE place a user could 'for sure' 'install' (run someone else's unapproved) program.

-

Websites, _really_, should work just fine with zero scripts turned on. Possibly with the exception of a short list of trusted or user approved websites.

As opposed to native apps like the parent poster is proposing with no sandbox and that need to be created for each platform?

As opposed to applications authorized by professionals in charge of equipment.

???

It can work. I have spent several years of my life making it work :) Obviously, on mobile you have app stores including enterprise app stores.

On desktop you don't, or you do but they suck so people often don't want to use them. Making shipping desktop apps as easily as you can ship a web app is the goal of my company [1] and although it's always a work in progress it does get very close to that goal now. In particular:

- Once set up you can deploy with a single command that builds, signs, integrates auto update engines, renders icons, uploads and everything else. It's not harder than uploading a new version of a web app.

- Apps can do synchronous update checks on startup, web style, so once you push a new version everyone will get that version when they next start up the app. You can easily implement version checks whilst the app runs to remind users to restart after a while (big SPAs have the same issue if the server changes whilst user's tabs are still open).

- Apps can update in the background too.

- Delta updates make update times very low once the initial install is done.

- On Windows, apps from different vendors can share files. So if two apps share a runtime and it's stable enough that files don't change totally from version to version, the user won't have to download them. Unfortunately on other platforms this nice trick doesn't work, and in a world where runtimes update every few weeks it's of less value. But still.

All this works behind the firewall, also.

[1] https://hydraulic.dev/

Native development's story has been, for the longest time, the native way or the highway, which is precisely why it failed in favor of web where everyone begrudgingly supports a common feature set. No one wants to implement the same feature in five different native idioms.

And unfortunately, every system had their own way. Native development has suffered for decades from stubborn OS vendors who are incentivized against portability and cross-platform interoperability. Everyone's "way" was different and required you to rewrite your application to support it. I always wonder, if the web never took off as the common platform, would we today have better cross-platform native tools and APIs? I guess we'll never know.

Yes, but in fairness if operating systems don't differ then what's the point in having them.

This is the "what killed [os] innovation" problem: if nobody is writing native apps then there's no incentive to add new capabilities to your OS.

What's really needed here is a platform with the same advantages as the web, but which makes it much easier for OS vendors to expose proprietary capabilities. Then you will get innovation. Once browser makers killed off plugins it was over for desktop operating systems as outside of gaming (where innovation continues apace), there was no way to let devs write 90% cross platform code whilst still using the 10% special sauce.