godot-dlang (a GDExtension interface library that lets you write D scripts for godot) now has very basic and extremeeeeeely experimental Web export support, this means you can now export simple projects written in D to run in browser. That is being said, while simple, it does not mean compact because godot itself can be treated as full OS in this case.

This is still in its very early stage, there is lots of things missing, but hey it is here!

Github
https://github.com/godot-dlang/godot-dlang

Link to a readme
https://github.com/godot-dlang/godot-dlang/blob/master/WEBEXPORT.md

Thanks to Adam Ruppe (https://github.com/adamdruppe) and Marcelo Silva Nascimento Mancini (https://github.com/MrcSnm) for their amazing work on minimal D runtime for WASM!

a bit more techy details

In its core lies a minimal D runtime implementation that makes it possible to run full (well, almost) D subset in browser.
Being minimal, means there is no GC (WASM currently has no way running a GC scannable memory in any case), it does leaky allocations and other sloppy things but the project tries to minimize them to be able to do a long runs without running OOM.
Also since phobos is build with GC in mind some things will be tricky to use and generally using phobos should be avoided in favor of using built-in godot functions (luckily there is a lot of stuff).
Since WASM itself is just a low level virtual machine, it does not provides any system interfaces(we are not talking about WASI here which aims to be mostly compatible with POSIX), instead we rely on emscripten(which is yet another POSIX compatibility thing) which is what upon godot builds on for its web export, it provides traditional libc environment which we utilize for tasks like memory allocation.
Another difference between "normal" WASM and emscripten is that in WASM a program is self contained, basically a plain .exe/unix executable, while in emscripten it emulates the whole dynamic linking process.
While it is not impossible to target WASI directly and avoiding extra bloat I ain't no expert in WASM and not willing to spent months(if not years) on approaching that task.

That's all, thanks.

On Sunday, 29 June 2025 at 08:26:09 UTC, evilrat wrote:

Yo! I've saw some movement from you on that side and thanks for the update to LDC 1.40 :)
I'm busy these times working on other features so I've pushed your branch to my fork too since soon we'll be getting a new GC, and I wanted to at least support up to that version, I would need to work incrementally on that! That being said, feel free to propose PRs or anything to my fork in the future (currently I've just simply pushed your change) so it is easier to find that work :D

Thanks a lot for that work! Also, I don't know if you know about that but OpenD has support to the full D runtime on web (with also the GC working), but it requires Emscripten, if you're already using emscripten it might be a valid option for you! Though I still prefer using the custom runtime since it is easier to setup and also way faster to build (I've basically made running D on web my test first platform).

Also, one of the ways I've saw you can do for doing long run games for GC depending ones with the leaker is to simply have an effective auto save system. You might be able to schedule some page reloads as it will fix your thing.

And WASM is also hot reloadable, which means you actually can clean your memory, and load your binary back using your save system, so you don't even have to do page reload, you can do simply free the memory and start your binary with the save as an argument, making a simulation of the GC, and for that games might work really well

On Sunday, 29 June 2025 at 08:26:09 UTC, evilrat wrote:

That's cool! Even basic support is a really nice thing to have because it makes it easier to share projects online.

Yeah :)