On Wed, Nov 16, 2022 at 10:51:31PM +0000, bioinfornatics via Digitalmars-d-learn wrote:
> Dear community,
> 
> I look some day ago to the D wasm page:
> -> https://wiki.dlang.org/Generating_WebAssembly_with_LDC
> 
> And since then I ask myself can we at  compile time convert a D code to an extern C code for wasm ?
> 
> Indeed, if a library/framework  would wrap this to let end user write his code in plain D that would be awesome.

You mean with Phobos and everything included?  I think there may be issues with that... because the current WASM does not define a memory management mechanism, so you'd have to convert the GC implementation to work with WASM.  Which would have issues with deployment because AIUI currently WASM still requires Javascript to initiate running it; if druntime needs special handling, for example, then you'd have to worry about coordinating with any JS code that the user may also wish to deploy, for example.  There are also language constructs that may not be supportable, like exceptions that propagate beyond the JS/WASM boundary (although if we add a layer of indirection to D functions called from JS, this might be possible to shoehorn into a semblance of working).

I did actually play with this a week or two ago; and found that it was actually quite difficult to get meaningful native code (D or otherwise) off the ground, because of the currrently mandatory Javascript component that need not only to load and initialize the WASM module, but also to interface with various browser APIs --- since WASM cannot call any of them directly, but has to go through a JS export/import API. String support also needs a lot of boilerplate.

Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work.

[1] I.e., there'd be a special D helper tool that imports your user D code and performs introspection on it, and spits out JS glue code at runtime. So you'd run this as part of your build, and it creates the necessary JS file(s) that you need to insert into your HTML; in the meantime, you run a separate build command to compile the user D code into WASM.  (This is why dub seriously needs to break out of its single executable modus operandi -- I don't think this can be easily bundled with dub right now.)

Having this tool is essential to making D's WASM experience tolerable; currently the insane amounts of JS boilerplate you have to write in order to get non-trivial D code off the ground is ridiculous.  Trying to write a WASM function that does string processing, for example, requires a ton of hacks to work around the lack of a built-in string type.  D could totally automate this crap away by having a wrapper tool that introspects your D code at compile-time and spits out the necessary JS boilerplate and any other needed shims in order to get this to work with a minimum of fuss.  Also, interfacing with browser APIs like WebGL also needs to be doable with a minimum of fuss, which currently isn't possible because of the unavoidable JS component with its associated boilerplate.


T

-- 
Hey, anyone can ignore me and go ahead and do it that way. I wish you the best of luck -- sometimes us old coots are dead wrong -- but forgive me if I'm not going to be terribly sympathetic if you ignore my advice and things go badly! -- Walter Bright

On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote:
> You mean with Phobos and everything included?  I think there may be issues with that...

Yes, this is a problem, but I think I have a solution: defer GC runs until javascript is running. There's also some llvm features that might fix it.

If I had a spare day I think I could play with it.


> Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work.

Sebastiaan Koppe generates the D/JS glue code from web standards. I've done it more dynamically inside D itself (exposing an `eval` hook on the JS side).

Sebastiaans: https://github.com/skoppe/spasm

mine: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html

Actually pretty easy to solve.

Thanks Adam, H. S., max for your point of view

On Wednesday, 16 November 2022 at 23:23:48 UTC, Adam D Ruppe wrote:
> On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote:
>> You mean with Phobos and everything included?  I think there may be issues with that...


Yes that would be really fantastic to get those enhancement. As example I see this wasm framework wrote in rust: https://github.com/yewstack/yew

Get a such framework in D wold be helpful