search

timotheecour / D_vs_nim

comparison of D vs nim
Apache License 2.0
62 stars 14 forks source link

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

Open Laeeth opened 4 years ago

Laeeth commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

skoppe commented 4 years ago

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.