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