On Thursday, 3 September 2015 at 02:02:06 UTC, Laeeth Isharc
wrote:
Adam Ruppe already wrote a javascript backend - it's not
maintained as I guess not so much interest.
It is several years old now, the compiler has been completely
refactored since then so it wouldn't work anyway. Besides, I
wasn't particularly happy with my approach and found it pretty
useless in actual practice. (In fact, I think ALL JS converters
are useless in practice right now, not adding enough benefit over
plain javascript to warrant the extra pains the converter brings.
But maybe browsers will change that by supporting better
debugging features, etc., to bridge the gap.)
I think ldc can output javascript if you compile it yourself
using a llvm thing too.
BTW those refactorings in the compiler should make it quite a bit
easier to do than it was then; if we were to start over, we could
probably have it more-or-less working in like a full-time work
week. But getting all the semantics right and then any runtime
library etc would be tricky. (One thing I wanted with mine was to
generate compact code, so I tried to match JS semantics fairly
closely rather than D, and offered bindings to native JS
functions to prefer over using phobos (though a decent chunk of
Phobos actually did work, notably most of std.algorithm).
Array.sort is like a few dozen bytes. std.algorithm.sort is
hundreds of kilobytes of generated JS code.)
but still i'm meh on the practical usefulness of such things. I
guess if you target a canvas and run your code in it that makes
more sense but my preferred style is a progressive enhancement
webpage where you want to know the browser platform and work with
it rather than around it.
