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.
