godot-dlang now has experimental web export support

[Hipreme]

On Sunday, 29 June 2025 at 08:26:09 UTC, evilrat wrote:
> 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.

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