eqrion

Yeah, and one thing that has been unclear to the WebAssembly CG is what is the performance and binary size impact of not allowing irreducible code. People can write microbenchmarks that show an impact, but we don't have great real world data.

So right now it's not a priority to fix. But the door is open to allowing it in the future.

> There is a novel WASM->JS JIT for experimental site speedup

I would love to see the details for this. SpiderMonkey had an attempted wasm32 JIT backend, but it was never finished.

edit: Apparently it also has some sort of WebAssembly interpreter backend too, which SpiderMonkey doesn't have.

Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts disabled, but it would be nice to have a translator.

The concurrency part of the C-M is complicated (I think for inherent reasons), but won't be exposed to end users. It's basically defining an API that language toolchains can use to coordinate concurrency.

For end users, they should just see their language's native concurrency primitives (if any). So if you're running Go, it'll be go routines. JS, would use promises. Rust, would have Futures.

I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.

And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were:

  1. Support non-Web API's
  2. Support limited cross language interop

WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more portable.

I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.

I'm not sure I follow this.

> WebAssembly is the wrong abstraction for running untrusted apps in a browser

WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.

> Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.

There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.

> Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented

The first major language for WebAssembly was C++, which is object oriented.

To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.