[I think this isn’t a very good article and isn’t going to be. Cross-language wasm APIs are hard and also don’t need to be advocated for. Just build it.]

Wasm is an executable format that can run anywhere. Every computer that C programs can compile to have an implementation of a wasm interpreter, and most platforms also have sophisticated Just in Time runtimes (a combination of an interpreter — able to run code immediately from a cold start — and a compiler, able to optimize code over time, sometimes even exceeding the capacity for optimization of a traditional compiler by studying the way the code runs in motion). Every programming language, eventually, will be able to compile to wasm. Crucially, it differs from past compilation targets (LLVM, JVM, Erlang VM bytecode, OS-specific binaries, or javascript) with the following critical combination of features

• It’s trustworthy. Guest wasm processes can’t mess with memory outside of their own, and by standard they can’t do anything to your system that they haven’t explicitly been given the ability to do. If you’re strict, you can even prevent them from doing timing attacks by witholding access to a clock or any means of estimating the passage of time (eg, thread checks). It can call other libraries, or be called into, without being able to engage in stack manipulation, and it can be given capability handles, which is a whole new paradigm for writing secure systems of interoperating programs. This should excite us because it means we can run random code from strangers without having to go through the extensive process of compiling it.
• It’s reliably about as fast as or faster than native code: Its interpreters are pretty fast, and its Just-in-Time runtimes already run at speeds comparable to native code. In future, in many cases it will run predictably faster than native as a result of cross-library inlining (optimizes programs across library boundaries) and within-kernel execution (bypasses system call handoffs).
• Due to the simplicity of its runtimes, if you have a wasm component, it should remain usable on every platform forever. Unlike source code, you don’t need an additional bootstrapped compiler toolchain to revive a wasm component, if it was compiled once, the result will still run, but if you need to compile it again, the compiler toolchain will be available as wasm too. Additionally, a wasm component should be used from any language that supports wasm, which should eventually be all of them, so moving to a new language doesn’t obligate you to abandon your old tooling.

A wasm component userspace adds up to a major general accelerant of social technology. Social technology makes us better people.

Why doesn’t the web have better account systems, and components??? I think this might have absolutely nothing to do with wasm components.

Is the problem just javascript programmers? They don’t understand why they should define interfaces so they don’t so all of their components are brittle and just use json?

But also nobody wants to be stuck with javascript so the good programmers wont come?

We will no longer be dependent on the W3C to build standards and add new functionality to browsers, because browsers will mostly consist of wasm components.

This is the contention??: Features like video playback, audio codecs and cryptography are not well suited to javascript for performance reasons, but they will all have excellent implementations in wasm.