This is SDL and std.algorithm code translated to JavaScript with emscripten. I've used the latest git versions of LDC and emscripten (the latter needed some modifications).

https://gist.github.com/pszturmaj/6244260
https://gist.github.com/pszturmaj/6244266

I couldn't manage to post it as single gist, and it seems there's a bug in the sdl.html gist (it looks empty). Just click Download Gist or '< >' icon (view raw) and save it as sdl.html.

Then open sdl.html in the web browser. It should print sorted and mapped array contents and run simple graphics demo.

I'm starting to work on this to fix the rest of the druntime so it can work under JS VM. Any help with this will be appreciated :-)

Piotr Szturmaj:

> Then open sdl.html in the web browser. It should print sorted and mapped array contents and run simple graphics demo.

Very nice. D is meant to run efficiently, but the Web is very important. There are many situations where it could be useful to run D code in a browser, so your work is important.

Integration with asm.js too is useful. (Expecially when asm.js gets a garbage collection, as Mozilla says). Currently only C and C++ are perhaps the only two languages usable to write asm.js+WebGL games for the browser. This could become one of the few niches open for D. There is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in the browser.

I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

Once your work is more more completed, the dlang site could show (in a sub-page) the compiler that compiles the online examples of the docs that's able to produce html+JS on the fly from the D code written in the browser.

Bye,
bearophile

On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:
> Integration with asm.js too is useful.

Doesn't the llvm backend do that automatically now? So ldc should get that too. I thought I read that llvm did in a blog somewhere, but I'm not sure.

W dniu 15.08.2013 23:45, Adam D. Ruppe pisze:
> On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:
>> Integration with asm.js too is useful.
>
> Doesn't the llvm backend do that automatically now? So ldc should get
> that too. I thought I read that llvm did in a blog somewhere, but I'm
> not sure.

Emscripten can output asm.js. Just add -s ASM_JS=1 to emcc arguments.

bearophile:
> Piotr Szturmaj:
>
>> Then open sdl.html in the web browser. It should print sorted and
>> mapped array contents and run simple graphics demo.
>
> Very nice. D is meant to run efficiently, but the Web is very important.
> There are many situations where it could be useful to run D code in a
> browser, so your work is important.
>
> Integration with asm.js too is useful. (Expecially when asm.js gets a
> garbage collection, as Mozilla says). Currently only C and C++ are
> perhaps the only two languages usable to write asm.js+WebGL games for
> the browser. This could become one of the few niches open for D. There
> is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in
> the browser.

Also D is garbage collected like JS. This means that high level code translation (like Adam D. Ruppe's work) should be more straightforward. On the other hand translating LLVM IR opens the possibility to mix D with C/C++ libraries.

> I have found some related activity from Rust people:
> https://github.com/mozilla/rust/issues/2235
> https://github.com/Yoric/Mozilla-Student-Projects/issues/33
> https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
>
> Once your work is more more completed, the dlang site could show (in a
> sub-page) the compiler that compiles the online examples of the docs
> that's able to produce html+JS on the fly from the D code written in the
> browser.

Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.

On 16 August 2013 07:55, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:

> bearophile:
>
>  Piotr Szturmaj:
>>
>>  Then open sdl.html in the web browser. It should print sorted and
>>> mapped array contents and run simple graphics demo.
>>>
>>
>> Very nice. D is meant to run efficiently, but the Web is very important. There are many situations where it could be useful to run D code in a browser, so your work is important.
>>
>> Integration with asm.js too is useful. (Expecially when asm.js gets a garbage collection, as Mozilla says). Currently only C and C++ are perhaps the only two languages usable to write asm.js+WebGL games for the browser. This could become one of the few niches open for D. There is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in the browser.
>>
>
> Also D is garbage collected like JS. This means that high level code translation (like Adam D. Ruppe's work) should be more straightforward. On the other hand translating LLVM IR opens the possibility to mix D with C/C++ libraries.
>
>
>  I have found some related activity from Rust people:
>> https://github.com/mozilla/**rust/issues/2235<https://github.com/mozilla/rust/issues/2235>
>> https://github.com/Yoric/**Mozilla-Student-Projects/**issues/33<https://github.com/Yoric/Mozilla-Student-Projects/issues/33>
>> https://mail.mozilla.org/**pipermail/rust-dev/2012-April/**001607.html<https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html>
>>
>> Once your work is more more completed, the dlang site could show (in a sub-page) the compiler that compiles the online examples of the docs that's able to produce html+JS on the fly from the D code written in the browser.
>>
>
> Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...
>
> The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.
>

^^ this!
I've been looking into this too recently.

On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
> bearophile:
>> Piotr Szturmaj:
>> I have found some related activity from Rust people:
>> https://github.com/mozilla/rust/issues/2235
>> https://github.com/Yoric/Mozilla-Student-Projects/issues/33
>> https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
>>
>> Once your work is more more completed, the dlang site could show (in a sub-page) the compiler that compiles the online examples of the docs that's able to produce html+JS on the fly from the D code written in the browser.
> 
> Yes, and it could be used to write rich web applications (which is the reason I'm working on it). JavaScript certainly wasn't created for big codebases...

Never understood the excitement about things like these. Yes, it's somewhat interesting and technically impressive, but in the end, the only language that benefits here *is* JavaScript. And it's already spreading like cancer. Why help it if you don't like it?

If even 1/10th of the effort spent on compile-everything-to-JS projects was directed towards properly bringing other languages into the browser land, the web would be a much better place now.

> The other big advantage would having one codebase shared between server, browser (including mobile) and desktop apps.

Yes, in theory. In practice, this is just something Node.JS people came up with for advocacy of their platform. It's false. In-browser JavaScript has so many constraints imposed on it that it will never behave exactly like server-side code. (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.)

Worse, no one took time to actually design a sensible model of interaction between server and the client for a "shared" codebase. It's all a jumbled mess of ad-hoc implementations and subverted web technologies that were originally meant for an entirely different purpose. I sometimes see JS examples like this:

if (imOnTheServer){
    //do one thing
} eles {
    //do another thing
} //Yay, "shared" code!!!

Every time I do, I get the urge to abandon programming and change my occupation.

On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
> Every time I do, I get the urge to abandon programming and change my
> occupation.

My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can  stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad.

IMO the current direction leads to a dead end.

The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.

--rt

On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
> On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
> >Every time I do, I get the urge to abandon programming and change my occupation.
> 
> My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can  stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most "personal computers" are now low powered mobile devices which makes the situation really bad.
> 
> IMO the current direction leads to a dead end.
> 
> The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess.
[...]

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.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis

W dniu 17.08.2013 16:42, Gambler pisze:
> On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
>> bearophile:
>>> Piotr Szturmaj:
>>> I have found some related activity from Rust people:
>>> https://github.com/mozilla/rust/issues/2235
>>> https://github.com/Yoric/Mozilla-Student-Projects/issues/33
>>> https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
>>>
>>> Once your work is more more completed, the dlang site could show (in a
>>> sub-page) the compiler that compiles the online examples of the docs
>>> that's able to produce html+JS on the fly from the D code written in the
>>> browser.
>>
>> Yes, and it could be used to write rich web applications (which is the
>> reason I'm working on it). JavaScript certainly wasn't created for big
>> codebases...
>
> Never understood the excitement about things like these. Yes, it's
> somewhat interesting and technically impressive, but in the end, the
> only language that benefits here *is* JavaScript. And it's already
> spreading like cancer. Why help it if you don't like it?
>
> If even 1/10th of the effort spent on compile-everything-to-JS projects
> was directed towards properly bringing other languages into the browser
> land, the web would be a much better place now.

It's not about helping JavaScript. It's about using another language to do client side scripting. I hate JS, I really don't like to write bigger applications in it.

What happens when you forget a semicolon or a comma? Or make some typos? It silently breaks. I don't care if there are tools to help with it. It's still a mess. Did you see WAT (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here are some examples of JS "additions" which WAT demonstrated:

[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN

Seriously, WTF!

And again, I don't want to write in it, but I _must_ use it. I just want to use another language that translates to JS. There are many of them already. Still, no one is even close to D in its usefulness.

The whole problem is that you need to write a web applications _now_, when the only supported languages for the web is JS. You really don't have a choice. Even if other languages could be widely supported from today, you'd still have to support older browsers. This means JS will stay in for another couple of years.

>> The other big advantage would having one codebase shared between server,
>> browser (including mobile) and desktop apps.
>
> Yes, in theory. In practice, this is just something Node.JS people came
> up with for advocacy of their platform. It's false. In-browser
> JavaScript has so many constraints imposed on it that it will never
> behave exactly like server-side code. (For example, your gist doesn't
> work in IE. Not that I use IE normally, but you get my point.)

Obviously, you can't share every possible code. It's about sharing the cross cutting parts. Imagine an application with a server, web frontend and desktop frontend. With shared codebases, you could write one client code. Just use the same abstractions for the web and for the desktop. Then you can create similar interfaces from the same codebase. It's a huge win. Duplicating efforts is tiresome, error prone and obviously takes time.

> Worse, no one took time to actually design a sensible model of
> interaction between server and the client for a "shared" codebase. It's
> all a jumbled mess of ad-hoc implementations and subverted web
> technologies that were originally meant for an entirely different
> purpose. I sometimes see JS examples like this:
>
> if (imOnTheServer){
>      //do one thing
> } eles {
>      //do another thing
> } //Yay, "shared" code!!!
>
> Every time I do, I get the urge to abandon programming and change my
> occupation.

This is not a new idea. Morfik is a webdev tool that automatically splits your code to the server and JS. I remember it was available in 2005. Also, there is Opa language.

I don't see anything wrong with cross platform code. For D example, I'd imagine it could look like this:

void showMsg(string s) {
    version (JS)
        js.alert(s);
    else
        YourDesktopWidgetToolkit.showMessageDialog(s);
}

void main() {
    showMsg("hello world");
}

Compiled with a regular compiler and GTK, will show a dialog.
Compiled with emscripten-like compiler will show a message in the browser.