I agree, except for the magnitude difference in time required in most cases.
A web-app that takes more than 10 seconds to load is consitered broken to many. A desktop app that can go from "discovery" to "using" in less than a minute is consitered fantastic. Plus then there are update headaches.
I genuinely believe one of the major reasons why the web is taking over is because every other platform makes the process of "installing" code such a difficult slow process.
Not to mention the security issues with giving code access to desktop systems which traditionally are difficult for the average user to secure. And the fact that I don't ever think i've had a piece of installed software ever completely "uninstall" itself correctly. They always leave stuff behind. In a browser, a single "clear browsing data for this domain" gets rid of all of it, entirely.
>This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.
But you do. Some platforms (like iOS) don't allow distribution over any methods other than their app store, or a browser. Still more heavily discourage distribution over HTTP (most linux distros). And most users will download the "installer" for a game via a browser in the extreme vast majority of cases, so why not cut out the middleman and just allow the game to be playable in a browser?
There are also other benefits of a web-platform game, like the ability to "deeplink" inside the app. I can not only share a link to the game, but can easily share a link to a specific screen in the game, or can share a link to allow you to connect to my game. And that whole process is crawl-able for search engines, and easy to implement. Sure, it's possible to do with desktop software, but it's much harder in most cases, especially when you throw cross-platform into the mix.
>...the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.
While of course a specific site can act as a gatekeeper, that's not what I was talking about. Time and time again we see stories about how Apple removed some app from the app store, or some company pulls their subscriptions from being allowed to sign-up on iOS devices, or how some game makes their own app-store to get around the limitations on android, or even how most "app stores" don't allow adult content.
That is the kind of stuff that the web-as-a-platform gets you away from. You aren't going to have Google removing your app because it's too adult, or Apple charging you a 30% fee for all subscriptions made on their platform.
I'm all for streamlining this process to allow users like yourself that want a "local install" to get it, but I don't think we should throw the baby out with the bathwater here. Browsers give us a shitload of benefits, and the discovery and "install" process (or the lack of) is second to none. I think we can work with those benefits, and give users and developers the options needed for other formats if they want.
For example, The microsoft store has started allowing PWAs to be listed, browsers could work with the OS and define some APIs that allow you to choose where to "install" a PWA or web game, possibly even allowing you to simply move it or uninstall it after the automatic "install" happens.
We are finally getting away from the days where it would take tens of minutes to download and install software on a computer, where it would require you to give a considerable amount of trust to that software once you run it, and making it really hard to share content within apps with others. I don't see why you would want to go back.
But now that I said all of that, I realized that I don't really know why someone would want to not have it. So I guess my question is why do you want a traditionally "installable" code? Is there something I'm missing here, or some assumption that one of us is making that is getting rolled in with this conversation?
>I think we can work with those benefits, and give users and developers the options needed for other formats if they want.
That's literally what I'm advocating. Not getting rid of webassembly applications in the browser, but also having native runtimes that are optimized for running the same webassembly applications.
Every benefit that the browser as application model provides could improve the way native applications work as well - there could literally just be a button or an option in the browser to "install as native" and the Webassembly binary in the browser could just be copied somewhere, maybe with some metadata, and an icon generated for the desktop. Native runtimes could sandbox them just as a browser might, and the uninstallation process need be not much more complex than dumping a cache or deleting a folder.
Your last paragraph basically describes a browser with a special "install" flow. Mobile Chrome already has a flow like that for PWAs where it will ask you "do you want to add this to the home screen?" and it will add the icon to your app drawer on android just like any other app, allow you to "uninstall" it just like any other app, and when you launch it it launches fullscreen just like any other app.
I'd love to see this expanded to cover desktop as well. And with some additional work (like giving the option to move storage data to different drives or manage apps based on their hostname more easily), it could become a very powerful system.
If you want to learn more, take a look at the google developers page for PWAs. It seems to be what you are looking for in some ways!
Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper.
>I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves.
This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that.
>no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.
Except the browser is the "launcher" and the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.