Making WebAssembly a first-class language on the Web

The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved.

The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.

The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.

The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?

I suppose I could sum up the concern as shifting complexity rather than eliminating it.

I created and maintain a couple of WASM projects and have not experienced the problems you describe:

- https://floooh.github.io/tiny8bit/

- https://floooh.github.io/sokol-webgpu/

- https://floooh.github.io/visualz80remix/

- https://floooh.github.io/doom-sokol/

All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users.

Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have one - unless you count integer and float types as type system"). Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file.

E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.

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 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.

> why webassembly is not used by the overwhelming majority of websites

This is such a bizarre take that I don't know whether it's just a trolling attempt or serious...

Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.