It's odd to talk about js target and not wasm

[Laeeth]

It seems to me a much less common thing to want to do to compile to js than wasm. But you mention js and not wasm. It makes it look like you are writing the feature comparison to cater to the peculiarities of the language you advocate rather than what's actually likely important to users.

I suppose both D and Nim compile to wasm. Right now for D you lose the runtime. But once there's a better way in wasm to manage memory then we will probably support the development of a port to wasm. Sebastian Koppe has ported std allocator to wasm already.

[timotheecour]

PR very welcome to clarify/update this; no bias was intended at the time I wrote this; since then, there have been some updates wrt wasm, see relevant links:

• https://forum.nim-lang.org/t/4309#26813 mentioning D's Spasm (where I'm raising the same point as you are)
• https://github.com/yglukhov/nimwasmrt for nim to wasm proof of concept

that being said, js as a compilation target does have its use, wasm can't do everything (or as conveniently) especially relating to DOM

[Laeeth]

V sorry but I have no time - just about possible to file an issue from my phone but a PR is impracticable for me right now.

[Laeeth]

It's just if you don't mention that this is out of date and you link to it from Reddit then people could easily get the wrong idea.

[timotheecour]

btw, do you have the reddit link? i wasn't the one who put it up

[skoppe]

that being said, js as a compilation target does have its use, wasm can't do everything (or as conveniently) especially relating to DOM

I wonder what specific DOM operations are easier when you compile to js versus wasm. Care to enlighten?

The way I see it, regardless of whether you target js or wasm, you are still going to need bindings/interfaces for the web apis in your language. (Nim/D/Rust/Go/etc.)

Currently with wasm you need some js glue code. But that is just an implementation detail. When the host bindings will arrive it will only require a change under-the-hood.

I have to admit that at various points I thought about targeting js as well, since it does avoid trampolining from js <-> wasm and back. However, those calls are pretty fast nowadays, and I don't think I want to write a js backend that emits as tight code as the llvm emits wasm.

Also, wasm can be parsed and compiled way faster than js. Firefox can do it at 70mb/s, which is a couple time faster than an end-user's network connection.