design

I have not been able to get excited about WASM due to the poor memory management situation. It’s been years since the MVP and we are still in limbo about freeing memory. A great issue documenting a lot of the pain points around this is here: https://github.com/WebAssembly/design/issues/1397 Until this is solved WASM is dead in the water for a huge variety of applications. I am rooting for WASM, but it has been discouraging to watch this go unsolved over the years.

In both cases the idea was to start simple in wasm 1.0 and leave those things for later. Both are being discussed now. For the first see e.g. https://github.com/WebAssembly/design/issues/1397 For the second, WASI is doing that on the server, while on the Web we just haven't found a way that is better/faster than calling through JavaScript (we tried to do direct WebIDL bindings among other things).

There are some important differences in approach. Java was never designed to be downloaded over a network, and didn't have a module format or JARs back then. This is part of what made it so slow. In contrast, efforts to make the encoding of modules as compact as possible started the moment WASM began. [1] It was based on past research in compactly encoding IRs, and the modules are often processed in parallel. The IR is also a lot less opinionated than other VMs. It started out being similar to a stripped-down JavaScript in capability, but broadened. At the same time it remained easy for browser engines to process into native code. Compared to optimizing applets, it has a simpler task to solve. This does have the disadvantage that modules need to come with their own runtimes. Compilers for languages like C have to deal with the fact that t

You cannot escape the politics of browsers by going to WebAssembly, because that's where WebAssembly was born. To use features outside of the original WASM spec, you have to consult a table and perhaps use a polyfill, like with CSS or JS features. Browser implementers have a large influence on the direction of the VM. For example, around a year into the original spec's development, it switched from being based on an abstract syntax tree to being based on a stack in a decision made by the browser teams [1]. A big change like that, a year in! The s-expressions in the text format are an artifact of that period, since tools already relied on their existence for optimization. Anyone who writes a compiler or engine for WebAssembly is going to have to deal with the mess of web standards, unfortunately. 1. https://github.com/WebAssembly/design/is

> WebAssembly will never have direct access to the DOM I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document <https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?