WebAssembly becomes a W3C Recommendation

Even back inn the 90s, people were thinking of the browser as a potential OS-like platform. Netscape certainly did, and that's why MS was so worried about them.

Thanks! I'm still thinking if I should need to learn a 'learning language' first (Java or Python) and then move on to a low-level language or go directly to C++. I've been on Linux for years and feel quite comfortable with it, BTW. Can C++ be learned/used on Linux?

Some retrospective ...

Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times.

WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way.

WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist.

Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly.

To say in CSS:

     my-component {
        behavior: my-native-event-handler url(controllers/my-controller.class); 
        flow: my-native-layout-manager;        
     }

Still working on this myself, but I'm using wasm to allow usage of a Rust library for parsing Rocket League replay files. I already had a binary utility that I could share with people who needed it, but it's a lot easily to just send them to a webpage where they upload their files and get a downloadable csv output.

I don't know what your experience with the JVM is, but it really isn't legacy. It's actually much more state of the art.

Can you explain a bit more in what way you see it as legacy?

Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive.

You can argue Java as a language has some legacy hanging around, though they've made great progress there with the latest versions. But the JVM has support for other languages as well, such as Ruby, Python, Scala, Kotlin, Clojure, Common Lisp, JavaScript, Fantom, etc.

Now WASM isn't a runtime. WASM is more akin to Java Bytecode or LLVM bitcode.

Each browser vendor will implement their own WASM VM. Currently, there is no standard for Garbage Collection, which means GCed languages won't be good candidates for WASM. If you want to use Python, Java, C#, Kotlin, TypeScript, Haskell, etc. your resulting program will need to bundle a full runtime for your language compiled to WASM as well. In all cases, this will end up having slower performance, and on the web will cause bigger download sizes.

Hopefully, this gets addressed in the future.

The flip side is portability. For example, Go compiled to WASM could run on all WASM non-web compliant VMs. But it'll run slower than GO compiled for the target machine directly.

That's why a good use case for WASM right now is to allow JavaScript to make use of C/C++ libraries in the browser. As well as Node.js to do the same in non-browser contexts.

This will often mean an HTML/CSS/JS UX with certain section of it in C/C++/Rust.

It does mean that Electron apps will be able to make use of portable C/C++ libraries more easily, as they get compiled to WASM and the V8 runtime will be able to run that WASM and eventually offer interop with the DOM and JS. Though that's not yet supported, as the boundary between GCed JS/DOM and WASM hasn't been fully figured out yet.

Also, WASI is the standard library for WASM, and that'll need to grow as well. Progress is being made there too, but its goal is to remain minimal, and delend more on libraries.

Conclusion, let's say you have WASM, Java Bytecode and LLVM bitcode, and maybe even .net IR. All of them are a form of virtual assembly which need a VM to run them. Any language could build a compiler to any of these. But they have different trade offs.

Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages.

.net IR is pretty similar, though the bytecode can be a bit more difficult in its handling of reified generics. That can make it a bit harder to target for higher level languages. Its JIT isn't as sophisticated, same as its GC, but it comes real close, and has good tooling around it and an excellent standard library.

LLVM will remain king for high performance, as it is designed to handle all kind of optimizations, and support multiple's language feature set efficiently. That said, it isn't as portable and isn't optimized for small binaries and fast parse times. It too, is best for low level languages as it doesn't enforce a memory model.

WASM also doesn't enforce a memory model, making it a great target for low level languages. It is optimized for safety and portability. Which means it'll most likely always be slower than LLVM. But it also tries to be as fast as it can, and theoritically could beat out Java Bytecode or .net IR given it can avoid GC overhead. It also is optimized to be streamed over the wire, that means small binaries that can be quickly parsed. So ideal for code that you can't predict where it is going to run, like the web.

The VM landscape overall is looking pretty healthy. But I think there's misconceptions out there, especially around the JVM and .net Core, and also about people's hype for WASM. Specifically, the JVM and .net Core are almost impossible to beat for what they do. So don't expect better from WASM. Similarly, JS is almost impossible to beat for what it does, and WASM doesn't plan to replace it, but enhance it.