High-level goals?

[hcphoenix]

I'm interested in this project, but relatively green, so I have an embarrassingly basic question: what advantages does a WASM backend for Nim present versus, e.g., compiling from Nim to C and to WASM through Enscripten (aside from a simpler build process)? Are there features that don't work through that build process currently? Performance concerns? Something else?

Thanks for your patience.

[stisa]

Hi! Compiling directly to WASM doesn't have clear perfomance advantages over C->WAsm, but as you mention, this allows for a very simplified build process, and it is one of the reasons I started this, to see if it was possible to build wasm directly without clang, emscripten, binaryen, etc. . With my branch, you only need to build nim, so a C compiler (to build nim from sources) is all that is needed.
Obviously, those projects have a lot more contributors and a good way to bring nim to wasm is probably with llvm and https://github.com/arnetheduck/nlvm

A direct wasm backend also allows for simple interoperability with js, eg importing a function log is just:

proc log[T](x:T) {.header:"glue", importc:"log".}

where log a function defined in the glue object that is passed to the wasm module when instatiating

glue: {
   log: function(arg){
     console.log(arg)
    },
   ...
}

and we can also have nim run the module with nodejs simply by nim wasm -r file.nim.
(see here for the default html and node templates)

Exporting to js is even simpler, as a proc with the export marker is automatically exported and calling it from js is as simple as

$file.exports.procName(args)

File size should also be smaller (at a similar level of features, this project is obviously still too WIP to have a meaningful comparison), as it does not need to compile the C layer, and nim is good at dead code elimination, so only the parts actually used end up in the binary.

In the future, having a direct wasm backend also allow for nim specific optimizations, for example once wasm gets gc primitives, or when nim moves to newruntime.

This backend also uses a different way to produce the output code, compared to other nim backends. Instead of appending to a string representation of the code, I produce something similar to an AST for wasm that then gets translated to binary wasm, which I believe could be useful also as a "model" for a new c or js backend, as NimAST->TargetAST transformations feel cleaner and less error prone than NimAST->string.

(Sorry about the length of this reply, I got a bit carried away. I hope I answered your question)

TL;DR: No clear advantage (for now) aside from easy interoperability with js and build process, project started mostly "for fun".