Godot currently supports exporting to WebAssembly, and through GDNative, importing from C/C++ and other languages. But it doesn't support importing WebAssembly modules, which I think is a big omission.

WebAssembly is a good format to import for the same reason glTF is:

• It's an open-source, multilateral design (unlike Java or C# bytecode).
• It's supported by multiple industry giants.
• It's lightweight (wasmtime is 20MB).
• There's very little cruft: the wasm specification is minimalist, has no ambiguous instructions, and aims to be easy to implement.

WebAssembly plugins would have a lot of advantages over GDNative, including:

• Write Once, Run Anywhere: Right now, if I want to include C++ code in my Godot project, I need to compile it to a different shared library format for every platform I want to target; the process is under-documented, and I'm told it can hit snags when exporting to iOS. On the other hand, once you've compiled to WebAssembly, you're done. The code runs the same on every platform.

• Fewer compatibility problems: This is particularly useful in development pipelines that include non-coders. I'm currently working on a game where a friend of mines makes the assets. I use Linux, he uses Windows. I set up my project with C++ scripts, but now he can't build the project unless he installs Visual C++ and builds the scripts on his side, which is complicated because I'm the one writing the build scripts. With wasm compatibility, I could just export a bunch of binaries on github, have him install them and he could work on assets with worrying about compiling the scripts.

• Sandboxing and object capabilities: wasm is sandboxed by default. The upcoming WASI API will ship with object capabilities, which allow programs to executed untrusted code without compromising your filesystem, which would be especially useful for integrated modding systems. The current approach gives native scripts unrestricted access to the filesystem, and relies on the community to spot any malicious code published on the asset library. The event-stream incident has shown that this approach does not scale well, and that targeted attacks do happen once a platform is popular enough.

These would be the short-term benefits, that a good wasm implementation would provide. On the longer term, integrating wasm into Godot would leverage improvements from developers working on other parts of the ecosystem:

• GDScript could be compiled to wasm. This would allow the engine to leverage wasm optimizers, instead of coming up with its own optimizations.

• Godot could use source maps to debug native code in-editor.

• Game developers could use wasm modules to import other languages' ecosystems that are missing in Godot. For instance, developers who want to use Python modules in GDScript could export these modules to wasm, and import the wasm code from Godot.

Now, WebAssembly as a standard isn't ready to be integrated in Godot yet. There are a few proposals (reference types, WebIDL bindings, WASI) that need to be standardized and implemented in compilers and runtimes before wasm can be integrated into Godot.

But I think it's worth starting to consider it now. I'm especially interested in what @Faless and @eska014 think on the subject. What kind of work is needed to integrate a wasm interpreter into Godot? Is it something that can plausibly be added to the 4.0 roadmap?