What in Gods Name is Happening to Wasm

I am quite interested in ways for all different kinds of languages to produce shared libraries and consume them. Writing a Java library I can use in Zig for example. Because of the different runtimes often found in languages and different ABI’s it’s usually boiling down to the common denominator that is a C shared library.

It would be nice if we instead could define a common interface that is not C that could be targeted by language that don’t quite fit into the C-ABI. That is why I was drawn to WASM and its new component model. It promises a language neutral agnostic way to interop between languages. EXACTLY what I wished for. Being able to easily mix and match languages regardless of their runtime.

I wasn’t really interested in the web aspect of WASM. So I was pleasantly surprised when I saw that Wasm implement a common API for POSIX functions. Print, read, standard systems APIs work using Wasi.

Now after reading about this new and cool component model and Wasm runtimes that implement it, I though cool lets write some components!

The thing is that creating components is not really something implemented by the languages itself like the C/C++ compiler clang. Instead of directly generating it we need some sort of wrapper. This works fine. But it is quite cumbersome to do. It’s not just like compiling a shared library and saying but instead of a native one make it a Wasm one. The Bytecode Alliance lists some languages where it should be possible to generate components from.

Wait It’s All Rust?

After trying out some other languages and then Rust, it dawned on me. The interface file you need to create, so the component can be consumed is heavily suited for Rust and its type system while for other languages it feels a bit off. Notably more Java like languages or JavaScript. I put this thought on a back burner for a while.

But then after searching for some articles and comments on the component model to see how other people feel about and use it. I saw this comment.

“annihilated for disagreeing”, “Component Model suddenly targets Web integration again”. Mhhh this does not sound good. Maybe AssemblyScript wrote more about this? Ohhh yea they did, and it does not sound good.

It starts with “In extraordinary circumstances, when collaboration towards eventual resolution is no longer deemed possible, AssemblyScript may object to individual efforts in context of WebAssembly standardization.” It’s an interesting read you should definitely go over.

The basics are that Wasm components break interoperability with the web and in general with every language that is not like Rust. One major problem is how strings are represented in Wasm components they are represented as UTF-8. Now languages that don’t have that as standard for their string representation have to do conversion that is usually quite expensive. And that major improvements for interacting with the DOM in Wasm are laid on ice because other areas that have nothing to do with the Web are being worked on like creating cross language components, ohhhh. Maybe they are onto something.

Personally I thought that the entire Wasm component proposal has nothing to do with the web. It definitely feels like the desire to move Wasm in a direction it was never imagined in. Rust seems to have great control over what happens to Wasm and strongly influences it. I wish for a way for different languages to better work together and share functionality. This in itself has nothing to do with web or Wasm on the first look, but the component model actually promises exactly that, but it seems that Wasm components are more interested in being Rust modules for other languages that support that.

How should I feel about the entire split personality of Wasm?