It's already a breakthrough in my opinion.

Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.

The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.

To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.

▲

Rochus 2 hours ago | parent [-]

> I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web

Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?

▲

throawayonthe an hour ago | parent [-]

this is a confusing question; why would it be much better to e.g. compile a C program for x86 linux musl but not the C compiler?

	▲	Rochus 21 minutes ago \| parent [-]
		Your analogy doesn't quite hold. The primary use case of a compilation target is to compile programs, not the compiler itself. With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.