Can we ease WASM in D ?

[H. S. Teoh]

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