It has been suggested to me to take the following concerns regarding the general direction of WebAssembly before a more CG-level forum, an advice I am following now in the hope that we as a community can eventually resolve them for good.

As some may know, my perspective on WebAssembly's goals has been clashing with the ideas of a certain group responsible for various proposals for quite a while, often leading to more or less heated discussions. So I think that there is an opportunity here to identify the root of the disagreement and work it out, so we can eventually align towards common goals again. I can only speak from my perspective, one that is more common among people who are interested in running WebAssembly on the Web, and also off the Web, which is coincidentally exactly what I am working on, and I am very interested in others thoughts.

From my perspective, the disagreement stems from the expectation induced by initially and still advertising WebAssembly as being part of the Open Web Platform (I'll shorten to "the Web" below). For instance, it has been expressed many times that Wasm isn't meant to replace (or harm) JavaScript, but is rather a companion technology, so I always assumed that it is a priority to achieve excellent compatibility (for me also means: interoperability) with the existing Web, which is a generally desirable goal on the Web. Or, as webassembly.org states:

Unfortunately, over the course of all these heated discussions, I got the impression that my understanding of WebAssembly's goals does not align with what my more influential adversaries within the CG are working towards, which I cannot help but see as attempts to create a new status quo that largely factors out compatibility with the Web. The first issue this disagreement showed in is STRING i32 pairs for UTF-16LE over at Interface Types (in 2017, at the time of creation named Host Bindings), where after 1 1/2 years of silence many arguments have been exchanged on whether UTF-8, a string encoding largely incompatible with Web APIs and JavaScript, should actually be the only supported encoding, or whether it would be useful to also account for compatibility from the start. In my book this should be a given, so I was very surprised by the sheer chain of contrary arguments, in turn fueling the disagreement. The issue eventually (mostly) resolved with the acknowledgement that there are just so many languages using a JavaScript-like string encoding that we should support it, in turn leading to the thorough concept of adapter fusion, yet it was hardly ever acknowledged that compatibility with Web APIs in particular is important. There are certainly more non-technical points to talk about in context of this issue, but I suggest we avoid these for now and focus on WebAssembly's direction.

Another similar issue is GC story for strings? over at the GC proposal, which so far did not reach resolution, and it probably also does not necessarily have to if the goal is an MVP we all can agree on. Yet, discussion so far also indicated that there is disagreement we'll have to resolve eventually, that is as soon as GC may be used in a way that requires interoperability between WebAssembly and Web APIs involving strings, perhaps also involving an arbitrary module graph, so ideally with minimal conversions and copying. The general disagreement also shows in a follow-up issue regarding a better GC story for arrays?, that quickly side-tracked to question my ability and the value of the project I am working on instead of discussing the concern at hand, which I today see more as an unfortunate consequence of a long-standing misunderstanding. If anything, it underlines that there is an opportunity here to align on common ground again.

I was also surprised by the recent efforts to Disallow duplicate imports?, a mechanism useful to integrate with dynamic languages like JavaScript where overloading with multiple signatures is common. The hurry to vote on removal in the same meeting after the presentation had me raise my eyebrows at least, but this may well be just another misunderstanding, or a disagreement on how the process should work.

Similarly, I recently came to question whether WASI may turn out to harm Wasm use cases on the Web?, as to me it appears to establish a new status quo as a side-effect before the more Web-focused part of the community had a chance to find a solution that promotes compatibility with the Web over fragmentation, due to related proposals not being far enough. Personally I consider the priorities at play there problematic for the reasons brought up in the issue. And coincidentally, the efforts at WASI are driven forward by CG members earlier arguing against my points at Interface Types, and while correlation does not necessarily imply causation, it ultimately led me to question the general direction of WebAssembly, leading us back to this issue.

As should be obvious by now, I have grown very worried that we, as a community, are not doing what is necessary to ensure excellent compatibility with the Web, while at the same time tolerating new proposals and related technology to break compatibility with the Web too much, or otherwise affect it negatively, directly, or indirectly. This has led me to wonder, for instance, whether Wasm, or at least its future self, should perhaps not be a W3C recommendation as it compromises backwards compatibility one essential piece at a time, which is certainly an extreme conclusion, but would be the ultimate question we'd have to ask when the level of disagreement increases even more, I think.

On that background, I am today turning to the CG with the request to discuss the following addition to WebAssembly's overall goals in order to hopefully reduce unnecessary friction in the future:

Compatibility with the Open Web Platform in general, and Web APIs and JavaScript in particular, is critical for WebAssembly's long-term success, and must not be compromised if it can be avoided. The bar is especially high for proposals promoting functionality not primarily targeting the Web, as there may be little incentive to not negatively affect this goal.

This is the higher level aspect I have been advocating for, in a nutshell, and if we can agree on it, and just write it down, most of the friction in discussions above would become (mostly) obsolete, at least as far as I am concerned, while restoring my faith into the process.

What this could imply:

• Interface Types is fine, but JS string encoding is important due to compatibility, and promoting UTF-8 over it to provide gentle pressure or similar, or justifying it with purported trends, may be problematic
• Threads, SIMD, i31ref etc. are all fine, as these are unrelated and only add functionality, unless they are/do not anymore
• GC is fine, but would be motivated to find a suitable solution for interoperability eventually
• WASI is fine, but would be motivated to consider alternatives to what is essentially a libc currently before going further down the fragmentation route
• WASI-nn is fine, but would be motivated to cooperate for example with the Machine learning for the Web CG

If it turns out that the CG cannot find consensus on making such a paragraph official, or if major modifications to it are necessary, I'd be very worried about the future of Wasm especially in context of being a Web standard and would suggest to re-evaluate our goals, and what we communicate publicly, in more detail. In this case, we may also want to hold a vote to legitimate such a course, I think.

Let me know of your thoughts, thank you! :)