Allow developers to deliver .wasm apps directly to their users

[sideshowbarker]

Problem description

Browsers lack a native MIME type handler for WebAssembly content (.wasm~application/wasm resources).

• Users navigating in browsers to URLs like https://example.com/gui-app.wasm aren’t able to have browsers just run the WebAssembly-based GUI app there. It’s reasonable for normal users to expect that it will just work. But it doesn’t.

• Developers wanting to provide WebAssembly GUI apps to their users on the web are blocked from being able to serve .wasm to users directly, and instead restricted to delivering .wasm apps indirectly only, through HTML documents. ^✳️

Specifically, developers are required to serve HTML+JS “glue code” (stub files) to browsers (to, e.g., instantiate a canvas and render the app GUI to it), and to have HTML+JS stubs reference/import/link to their .wasm resource as a “module”.

Needing to have HTML+JS glue code for a WebAssembly app is kludgy — it places an unnecessary extra complication in the way of developers who just want their users to able to navigate to a URL on the web and run their WebAssembly app.

So users should instead be able to navigate in a browser straight to the URL for a .wasm resource (so that browsers load it directly), and that should cause the browser to compile and directly instantiate the WebAssembly GUI app at that URL — to run that WebAssembly GUI app directly, and present the app experience from it directly to the user.

^{✳️ Examples of developers stating that they want to do something like this can be found in Stack Overflow questions and in various other places; for a recent somewhat-related example, see the Stack Overflow question Can I upload to webassembly without Javascript.}

Arguments against enabling WebAssembly GUI apps to be run directly on the web…

This section lists arguments against trying to solve this problem for developers and users — along with counterarguments.

• Only a tiny bit of “glue code” is needed and it already works just fine and isn’t burdensome.
  Since what we have already works, we don’t need to do anything more to help developers and users.

  Counterargument: If only a tiny bit of glue code is required, then it’s imaginable we should be able to figure out a way to have browsers automatically emulate what that glue does — rather than developers needing to provide such glue.

  Making millions of developers (over time) keep manually doing something the browser could automatically be doing for them instead runs counter to the Priority of Constituencies, one of our core tenets.

• There would be no performance gain from this.

  Counterargument: This issue isn’t about performance, nor about trying to solve performance problems; rather, it’s about trying to provide a better developer experience, and better developer ergonomics: to help developers and to make it easier for developers to deliver the kind of user experiences to their users that they want their users to have.

• The vast majority of existing WebAssembly content on the web doesn’t need this.
  Only the Flutter project wants this, and only Google would benefit from it.

  Counterargument: Yes, most existing WebAssembly content on the web doesn’t need this — because most existing WebAssembly content on the web isn’t built to provide its own GUI but is instead intended to be incorporated as a module into an HTML+JS+CSS web app that does something with the WebAssembly content as just a part of the app.

  This issue is only about the very-real subset of WebAssembly content on the web that is built to provide its own GUI — and about making things easier for developers who create those WebAssembly GUI apps, and easier for their users.

  The fact that there are currently only a relatively small number of developers creating such WebAssembly GUI apps for web delivery doesn’t prove that more developers don’t want to do it — in fact it somewhat suggests the opposite: That we’re currently making it harder for developers than it should be, and if we can do something more and better to help developers to do it, we will then see more developers actually doing it — and more users benefiting from it.

  And even if most existing WebAssembly GUI apps on the web are made with Flutter, that doesn’t prove Flutter’s the only UI SDK project that wants to invest in enabling use of WebAssembly GUI apps on the web; rather, it‘s an existence proof of a project that has invested in enabling developers to deliver WebAssembly GUI apps to their users on the web. And if the Flutter project stands out as having been successful at doing that, then providing a further, standard way to help developers do it better will support the ability of other UI SDK projects to replicate that success.

• We actually shouldn’t help developers to do this, because this would be very bad for the web.
  This is fundamentally a horrible idea; this will lead us to a web that’s full of just unindexable bitmaps.
  It’s bad for every web app to have an entire layout engine or UI framework compiled into the app.
  It’s bad for users if an app’s load size is bloated by an entire layout engine or UI framework being compiled in.
  The load times for WebAssembly GUI apps are horrible. (Try, for example, an existing Flutter app, and you’ll see).
  Existing web apps built this way (e.g., Flutter apps) provide an odd/undesirable user experience for users.

  Counterargument: This issue is about developers having an option to allow a user to navigate directly to .wasm URL to be able to run their app — that is, this issue is about enabling developers to have a choice to do that. The problem is that currently, developers and their users have no such choice available.

  Whatever opinions we ourselves might have about the approach of delivering WebAssembly GUI apps as single .wasm runnable binaries on the web, we should not let our opinions limit the options available to developers, and we should not preëemptively and unilaterally enforce our own choices on developers.

  Developers should be allowed to weigh the pros and cons of the approach on their own — based on their own understanding of their own users and the needs of their own users — and to make their own choices.

  This issue is not about obsoleting normal HTML+JS+CSS content on the web, nor even about displacing the normal use of HTML+JS+CSS for all the cases where it makes perfectly good sense to use HTML+JS+CSS.

  There are obviously many cases where WebAssembly itself isn’t necessary at all in any form — that is, many (or maybe even most) classes of web content don’t need to be built with WebAssembly and wouldn’t benefit from using it. But this issue isn’t about all those cases — instead this issue is very specifically only about the particular subset of web application cases where it does make sense for developers to use WebAssembly.

Proposed solutions

1. Towards a modern Web stack is a design document laying out details for some specific changes that would help solve the problem this issue describes. It’s just one possible approach, and any concerns about the details of the approach described there shouldn’t be used to dismiss out of hand the problem described in this issue. Other approaches are imaginable — so discussion in this issue should focus on the problem description first and foremost, and only secondarily on the details of that ”Towards a modern Web stack” document, or any other proposed solutions.