Proposal for porting D runtime to WebAssembly

Sebastiaan Koppe mail at skoppe.eu
Mon Nov 25 12:52:46 UTC 2019


On Monday, 25 November 2019 at 09:01:15 UTC, Dukc wrote:
> On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe 
> wrote:
>> This is my proposal for porting D runtime to WebAssembly. I 
>> would like to ask you to review it. You can find it here: 
>> https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> This proposal is so perfectly balanced between value and 
> implementability that I can find nothing to add or remove.

Thanks!

> I'm interested, what's your motivation in doing all this? If I 
> understood correctly, your primary motivation to write Spasm 
> was to write better optimized front-end programs than you get 
> with JS frameworks.

That is a fair question. Spasm has been very successful if you 
look at rendering speed. It (almost) beats everything else out 
there [1]. Well, that is not surprising since everything is known 
at compile time; it literally compiles down to the same code as 
if you issued low-level dom calls manually. I am very happy about 
that.

With regards to developer experience it is behind. First of all 
you have to deal with betterC. This alone is already a hurdle for 
many. Second is the DSL, or lack of it. It doesn't come close to 
something like e.g. SwiftUI. In fact, I wrote a (unfinished) 
material-ui component library on top of spasm and I was 
struggling at times.

So it became clear to me I need to have druntime available. It 
will allow people to use the (almost) complete set of D features 
and it opens up some metaprogramming avenues that are closed off 
right now. With that I will be able to create some nice DSL, in 
line with JSX/SwiftUI or 
<insert-your-favorite-declarative-framework>.

There are plenty of opportunities here. It is not unfeasible to 
connect spasm to Qt, or dlangui, and create a cross-platform UI 
library, something like flutter.

On the other hand, I am very excited about WebAssembly in 
general. It is certainly at the beginning of the hype curve and I 
suspect some very exciting things will appear in the future. Some 
of them are already here right now. For instance, you can target 
ARM by compiling D code to wasm and then use wasmer to compile it 
to ARM. With D connecting itself to the wasm world it exposes 
itself to a lot of cool things, which we mostly get for free.

As an example, it is just a matter of time before a PaaS provider 
fully embraces wasm. Instead of having docker containers you just 
compile to wasm, which will be pretty small and can boot in (sub) 
milli-seconds (plus they don't necessarily need a linux host 
kernel running and can run it closer to the hypervisor.)

There are tons of possibilities here, and I want D to be a viable 
option when that day comes.

So it is not just about frontends anymore.

> But wouldn't it be easier to just use Rust since it has already 
> implemented all this?

All the rust frameworks for web apps that I have seen rely on 
runtime techniques like the virtual dom. As a consequence they 
spend more cpu time and result in bigger files. That may be 
perfectly fine for most (and it probably is), but I wanted to 
squeeze it as much as I could. Maybe it is possible to do that in 
rust as well, I don't know. D's metaprogramming seemed a more 
natural fit.

[1] except Svelte, which is a little bit smaller in code size, 
and a tiny bit faster. But they build a whole compiler just for 
that. Lets wait for host bindings support in wasm and measure 
again.


More information about the Digitalmars-d-announce mailing list