Experiments with emscripten and D

[H. S. Teoh]

On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:
> On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
> >On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
> >>On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:
[...]
> >>>It's just like Nick Sabalausky always likes to rant about. In 1975,
> >>>we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
> >>>applications ran rather slowly.  Then processor speed increased
> >>>exponentially, RAM increased exponentially, and today we have
> >>>64-bit computers with 4GHz CPUs (and multicore!) and who knows how
> >>>many GBs of RAM, and our (web) applications run at about the same
> >>>speed as in 1975.  Clearly, *something* is very, very wrong with
> >>>this picture.
[...]
> >>How do we fix it? We have a great language here, let's revolutionise
> >>the web :p
> >
> >Yeah! vibe.d FTW! :) And the client-side version thereof. :)
[...]
> Yeah the server-side is relatively easy to pull off, seeing as
> you're completely in control there.
> 
> The client side is an eensy little bit harder haha. It would
> probably require heavily modifying/creating a new web-browser and
> then convincing people to use it.
> 
> I wonder how powerful browser extensions can be these days...

Hmm. That's an idea, write an extension that can run code through rdmd.
(You have to deliver the source rather than the object code, since you
don't know what OS your client is running on.)

Requiring an extension puts it in the same boat as Flash, though. :-(

And you'd have to sandbox the code since arbitrary D code running wild
on the user's computer is a Bad Thing(tm). Which runs into GC-related
issues when your client is a low-memory handheld device. Though arguably
this would still be an improvement over JS, since an interpreted
language necessarily uses more resources.


T

-- 
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com