www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D for the web?

reply Trass3r <un known.com> writes:
Just discovered this LLVM-to-Javascript translator: http://emscripten.org/
Looks really interesting, they even converted CPython.

Might be interesting for D as well.
Question is how the low-level stuff in druntime would work out.
Jan 23 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 23 January 2012 16:21, Trass3r <un known.com> wrote:

 Just discovered this LLVM-to-Javascript translator: http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.


Alternatively, you could just program CGI in D.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 23 2012
parent "Trass3r" <un known.com> writes:
 Alternatively, you could just program CGI in D.


This is about client-side.
Jan 23 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Monday, 23 January 2012 at 16:21:35 UTC, Trass3r wrote:

 Just discovered this LLVM-to-Javascript translator: 
 http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.


Javascript really is a pretty limited language and I'd imagine a 
lot of unexpected behavior from D-to-JS programs. There are 
better languages for large client-side web apps like 
Coffeescript, Obective-J, and Dart.

D running on Google's Native Client looks more promising.
Jan 23 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2012 05:43 PM, F i L wrote:

 On Monday, 23 January 2012 at 16:21:35 UTC, Trass3r wrote:

 Just discovered this LLVM-to-Javascript translator:
 http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.


 Javascript really is a pretty limited language and I'd imagine a lot of
 unexpected behavior from D-to-JS programs. There are better languages
 for large client-side web apps like Coffeescript, Obective-J, and Dart.

 D running on Google's Native Client looks more promising.


http://jslinux.org/
Jan 23 2012
parent "F i L" <witte2008 gmail.com> writes:
Timon Gehr wrote:

 http://jslinux.org/


That's pretty impressive.


Joshua Niehus wrote:

 On Monday, 23 January 2012 at 16:43:06 UTC, F i L wrote:

 There are better languages for large client-side web apps like 
 Coffeescript...


 
 "CoffeeScript is a little language that compiles into 
 JavaScript"


Yes and emscripten compiles LLVM IL code into Javascript. I'm not 
sure I see your point.
Jan 23 2012
prev sibling next sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
A CPPCMS-like framework would be far more interesting for D :
http://cppcms.sourceforge.net/<http://cppcms.sourceforge.net/wikipp/en/page=
/main>

Jo=C3=ABl Lamotte
Jan 23 2012
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
On Monday, 23 January 2012 at 16:43:06 UTC, F i L wrote:

 There are better languages for large client-side web apps like 
 Coffeescript...


"CoffeeScript is a little language that compiles into JavaScript"
Jan 23 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 23/01/2012 16:43, F i L wrote:
<snip>

 Javascript really is a pretty limited language and I'd imagine a lot of
unexpected
 behavior from D-to-JS programs. There are better languages for large
client-side web apps
 like Coffeescript, Obective-J, and Dart.


<snip>

Just had a look at CoffeeScript
http://coffeescript.org/

It appears to be mostly a candygrammar for JavaScript, designed to give it a
more 
functional feel.

And what about MiniD?

Moreover, it seems that getting a new scripting language implemented in web
browsers isn't 
going to be easy.  But it seems that language-to-JS compilers would work as
long as the 
language's concepts are readily and efficiently implementable in JS.

Stewart.
Jan 24 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Stewart Gordon wrote:

 Moreover, it seems that getting a new scripting language 
 implemented in web browsers isn't going to be easy.  But it 
 seems that language-to-JS compilers would work as long as the 
 language's concepts are readily and efficiently implementable 
 in JS.


Stewart Gordon wrote:

 Moreover, it seems that getting a new scripting language 
 implemented in web browsers isn't going to be easy.  But it 
 seems that language-to-JS compilers would work as long as the 
 language's concepts are readily and efficiently implementable 
 in JS.


Problem with efficiency is, in the best of cases, Javascript is 
15-30x slower than native C code; and only after a lot of 
fine-tuning and on the newest browsers. Modzilla and Google 
engineers have been hacking away at performance issues for years, 
but the problem is Ecmascript's spec is the real limiting factor. 
The spec does update, but when major browsers vendors like 
Microsoft simply ignore implantation proposals (like SVG) and 
fight against spec improvements (like Ecmascript 4.0) new 
features can hardly be used at large, considering 30-40% of web 
traffic is still Internet Explorer.

This is why I mentioned Google's Native Client (NaCL), which if 
you don't already know, is a *plugin* for running sandboxed 
native code (  95% efficiency) over the web with the same 
security limits as Javascript. The world needs Operating Systems 
that work like browsers IMO, and I think D would fit in nicely 
here.
Jan 24 2012
next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 24.01.2012, 16:41 Uhr, schrieb F i L <witte2008 gmail.com>:


 Stewart Gordon wrote:

 Moreover, it seems that getting a new scripting language implemented in  
 web browsers isn't going to be easy.  But it seems that language-to-JS  
 compilers would work as long as the language's concepts are readily and  
 efficiently implementable in JS.


 Stewart Gordon wrote:

 Moreover, it seems that getting a new scripting language implemented in  
 web browsers isn't going to be easy.  But it seems that language-to-JS  
 compilers would work as long as the language's concepts are readily and  
 efficiently implementable in JS.


 Problem with efficiency is, in the best of cases, Javascript is 15-30x  
 slower than native C code; and only after a lot of fine-tuning and on  
 the newest browsers. Modzilla and Google engineers have been hacking  
 away at performance issues for years, but the problem is Ecmascript's  
 spec is the real limiting factor. The spec does update, but when major  
 browsers vendors like Microsoft simply ignore implantation proposals  
 (like SVG) and fight against spec improvements (like Ecmascript 4.0) new  
 features can hardly be used at large, considering 30-40% of web traffic  
 is still Internet Explorer.

 This is why I mentioned Google's Native Client (NaCL), which if you  
 don't already know, is a *plugin* for running sandboxed native code (   
 95% efficiency) over the web with the same security limits as  
 Javascript. The world needs Operating Systems that work like browsers  
 IMO, and I think D would fit in nicely here.


I find the performance not so much the limiting factor as the lack of  
compact arrays to cache data. My JavaScript applications quickly become  
RAM hoggers. I'm not so keen on turning browsers into operating systems  
though. It is very difficult on the one hand to write such a browser,  
which shrinks the market, and we already have a good selection of  
operating systems and desktop environments, together with transparent  
storage of personal data, temporary files and configuration. Not to  
mention installers/uninstallers and the rest of the software  
infrastructure. Sun invented Java Web Start. Isn't that a technology that  
can serve the same purpose, without running the application in a  browser  
tab?
Jan 24 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Marco Leise wrote:

 I'm not so keen on turning browsers into operating systems 
 though. It is very difficult on the one hand to write such a 
 browser, which shrinks the market, and we already have a good 
 selection of operating systems and desktop environments, 
 together with transparent storage of personal data, temporary 
 files and configuration. Not to mention installers/uninstallers 
 and the rest of the software infrastructure.


I'm didn't mean browsers the way they are today. I meant OS's 
that "browse" powerful applications in an entirely care-free way, 
from a security and memory management standpoint. Browser tabs 
and "back" functionality are logical workspace and memory 
management designs IMO.



 Sun invented Java Web Start. Isn't that a technology that
 can serve the same purpose, without running the application
 in a  browser tab?


I'm unfamiliar with Java Web Start, but if it's anything like 
MS's ActiveX plugin (which is commonly compared to NaCL) then it 
differs from NaCL in one major way: security. ActiveX could run 
native native code in a browser as well, and Java applets got 
pretty close. The problem is that those plugins can harm you 
system, whereas NaCL cannot. Every machine instruction in NaCL is 
sandboxed and checked for malicious intent before it's deemed 
execute-ready and ran. You can check out some NaCL games made 
with Unity3D on Google's webstore. Search "Chordy" or "Sleepy 
Jack".
Jan 24 2012
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 24.01.2012, 20:57 Uhr, schrieb F i L <witte2008 gmail.com>:


 I'm unfamiliar with Java Web Start, but if it's anything like MS's  
 ActiveX plugin (which is commonly compared to NaCL) then it differs from  
 NaCL in one major way: security. ActiveX could run native native code in  
 a browser as well, and Java applets got pretty close. The problem is  
 that those plugins can harm you system, whereas NaCL cannot. Every  
 machine instruction in NaCL is sandboxed and checked for malicious  
 intent before it's deemed execute-ready and ran. You can check out some  
 NaCL games made with Unity3D on Google's webstore. Search "Chordy" or  
 "Sleepy Jack".


No, it is about launching desktop applications via a link from a website.  
The applications are signed to get access to the computer. Web Start also  
keeps the software up to date and installs Start Menu links. Pretty  
simple, much like installing a FireFox plugin.
Jan 24 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"F i L" <witte2008 gmail.com> wrote in message 
news:izxjcveflvwsxtukfwuu dfeed.kimsufi.thecybershadow.net...

 Problem with efficiency is, in the best of cases, Javascript is 15-30x 
 slower than native C code; and only after a lot of fine-tuning and on the 
 newest browsers. Modzilla and Google engineers have been hacking away at 
 performance issues for years, but the problem is Ecmascript's spec is the 
 real limiting factor. The spec does update, but when major browsers 
 vendors like Microsoft simply ignore implantation proposals (like SVG) and 
 fight against spec improvements (like Ecmascript 4.0) new features can 
 hardly be used at large, considering 30-40% of web traffic is still 
 Internet Explorer.


Solution: Create an IE-compatible JS module that will translate the newer 
spec into IE-style. Yes, it'll be much slower, but that would just give MS 
that much more reason to get off their asses and fix things.

Although sometimes I almost want to root for MS though: MS's box model and 
JS mouse API both prove just how far the W3C has it's head up its ass. I 
can't help wondering if Google has been pushing for subpar shit just because 
the better alternative was MS's idea.
Jan 24 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Nick Sabalausky wrote:

 Solution: Create an IE-compatible JS module that will translate 
 the newer spec into IE-style. Yes, it'll be much slower, but 
 that would just give MS that much more reason to get off their 
 asses and fix things.


See Google's Dart language. ATM it's just a client-side 
Javascript compiler + server-side VM, but Google has talked about 
a native client side VM in Chrome.



 Although sometimes I almost want to root for MS though: MS's 
 box model and JS mouse API both prove just how far the W3C has 
 it's head up its ass. I can't help wondering if Google has been 
 pushing for subpar shit just because the better alternative was 
 MS's idea.


ALL of MS's inovations haven't been bad of course, take CSS 
expressions for example. But their cons far outweigh their pros, 
IMO. IE8, the best IE on XP (which is still the dominate web 
browser/OS), can't properly render semi-transparent PNGs with 
alpha channels.... It's impossible to do any kind of visual 
effects with that limitation and you're left with browser 
conditioning hacks which eat up needless time to write and test. 
Recently they've decided to play ball a bit more (cause they have 
to) but they will never support WebGL which is one of HTML5's 
best features. In fact, their whole DirectX strategy is just a 
developer lock-in.

That said, I'm not a huge fan of W3C either, most surrounding 
their pace.. but they at least share their inovations with each 
other...
Jan 24 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"F i L" <witte2008 gmail.com> wrote in message 
news:yfxraaqypcvgjmpicbju dfeed.kimsufi.thecybershadow.net...

 Nick Sabalausky wrote:

 Although sometimes I almost want to root for MS though: MS's box model 
 and JS mouse API both prove just how far the W3C has it's head up its 
 ass. I can't help wondering if Google has been pushing for subpar shit 
 just because the better alternative was MS's idea.


 ALL of MS's inovations haven't been bad of course, take CSS expressions 
 for example. But their cons far outweigh their pros, IMO. IE8, the best IE 
 on XP (which is still the dominate web browser/OS), can't properly render 
 semi-transparent PNGs with alpha channels.... It's impossible to do any 
 kind of visual effects with that limitation and you're left with browser 
 conditioning hacks which eat up needless time to write and test. Recently 
 they've decided to play ball a bit more (cause they have to) but they will 
 never support WebGL which is one of HTML5's best features.


Right, I'm not saying IE is awesome, just that there are *some* things I'd 
be rooting for MS on.

Although I just used IE8 the other day and *HATED* it. I hated it much, 
*much* more than IE7 (which I avoid using, too). IE8 is "Clippy", converted 
from a paper clip to a web browser. It's the same obnoxious Clippy, just in 
non-corporeal form. Always deciding it knows better than me. Always getting 
in my way for the sake of being "helpful". Ever been around someone who 
offered you garbage junk food you nether wanted nor needed...but *would not* 
take "no" for an answer no matter how many times or how firmly you declined? 
That's IE8.

(I get the impression MS's famed usability lab is forbidden to any users who 
aren't never-touched-a-computer grandmothers.)
Jan 24 2012
prev sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
Let just make sure D can compile for NaCl and wait for it to be on other
browsers than Chrome...

Native code should be executed in native.

Klaim
Jan 24 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 23.01.2012, 17:21 Uhr, schrieb Trass3r <un known.com>:


 Just discovered this LLVM-to-Javascript translator:  
 http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.


I've seen that a while ago. I wrote the visualizer (or replay viewer) for  
aichallenge.org and had to cover an applet for older IEs, a HTML 5 version  
for standards complient browsers and an standalone application. Back then  
I decided to write the viewer in JavaScript and use a Java JavaScript  
engine (Rhino from Mozilla) to wrap it into a cross-platform desktop  
application and an applet all at once. Quite literally even, since the JAR  
file worked as an applet and standalone application.

In parallel I made my first steps with D2 and when the CTFE regex came  
out, I wondered if DMD could compile my JavaScript to native code.

Then I found emscripten and that opens a whole new alternative: To write  
the viewer in Python/C/D and let emscripten generate JavaScript. There is  
even a version of Gtk (and Cairo?) running in JavaScript, so the graphics  
should not be a problem either. Once the converter is rock solid, it is  
definitely easier to run unit tests with a native application, than it is  
with JavaScript, especially with its lack of strong typing. It is a  
scripting language after all.
Jan 23 2012
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On 23/01/12 17:21, Trass3r wrote:

 Just discovered this LLVM-to-Javascript translator: http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.



Am I the only one who thinks this sounds like a horrible idea? :)

-Lars
Jan 23 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:jfk4f6$2elm$1 digitalmars.com...

 On 23/01/12 17:21, Trass3r wrote:

 Just discovered this LLVM-to-Javascript translator: 
 http://emscripten.org/
 Looks really interesting, they even converted CPython.

 Might be interesting for D as well.
 Question is how the low-level stuff in druntime would work out.



 Am I the only one who thinks this sounds like a horrible idea? :)


It's horrible, but not as horrible as using straight JavaScript (or 
CoffeeScript, IMO).

It's a necessary evil thanks to JavaScript's underserved ubiquity.
Jan 23 2012
parent reply Tobias Pankrath <tobias pankrath.net> writes:
 Am I the only one who thinks this sounds like a horrible idea? :)


 
 It's horrible, but not as horrible as using straight JavaScript (or
 CoffeeScript, IMO).
 
 It's a necessary evil thanks to JavaScript's underserved ubiquity.


Google Web Toolkit works quite well.
Jan 23 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Tobias Pankrath" <tobias pankrath.net> wrote in message 
news:jfkn05$h2n$1 digitalmars.com...

 Am I the only one who thinks this sounds like a horrible idea? :)


 It's horrible, but not as horrible as using straight JavaScript (or
 CoffeeScript, IMO).

 It's a necessary evil thanks to JavaScript's underserved ubiquity.


 Google Web Toolkit works quite well.


I'd have a hard time trusting it. Would the resulting code necessarily use 
Ajax even if I didn't want it to? How much JS overhead does it pull in for 
simple uses of JS? Does the resulting code automatically interact with 
Google's servers in any way? How compatible is the resulting JS? Would the 
resulting code break the page when JS is off? It's Google, for god's sake, 
can they even be trusted at all? Etc.
Jan 23 2012
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 24.01.2012, 03:43 Uhr, schrieb Nick Sabalausky <a a.a>:


 "Tobias Pankrath" <tobias pankrath.net> wrote in message
 news:jfkn05$h2n$1 digitalmars.com...

 Am I the only one who thinks this sounds like a horrible idea? :)


 It's horrible, but not as horrible as using straight JavaScript (or
 CoffeeScript, IMO).

 It's a necessary evil thanks to JavaScript's underserved ubiquity.


 Google Web Toolkit works quite well.


 I'd have a hard time trusting it. Would the resulting code necessarily  
 use
 Ajax even if I didn't want it to? How much JS overhead does it pull in  
 for
 simple uses of JS? Does the resulting code automatically interact with
 Google's servers in any way? How compatible is the resulting JS? Would  
 the
 resulting code break the page when JS is off? It's Google, for god's  
 sake,
 can they even be trusted at all? Etc.


Trust is not enough, you must love the big brother.</brainwash>
Jan 24 2012
prev sibling parent reply Tobias Pankrath <tobias pankrath.net> writes:
Nick Sabalausky wrote:


 "Tobias Pankrath" <tobias pankrath.net> wrote in message
 news:jfkn05$h2n$1 digitalmars.com...

 Am I the only one who thinks this sounds like a horrible idea? :)


 It's horrible, but not as horrible as using straight JavaScript (or
 CoffeeScript, IMO).

 It's a necessary evil thanks to JavaScript's underserved ubiquity.


 Google Web Toolkit works quite well.


 
 I'd have a hard time trusting it. Would the resulting code necessarily use
 Ajax even if I didn't want it to? How much JS overhead does it pull in for
 simple uses of JS? Does the resulting code automatically interact with
 Google's servers in any way? How compatible is the resulting JS? Would the
 resulting code break the page when JS is off? It's Google, for god's sake,
 can they even be trusted at all? Etc.


Can't see any technical argument here.
Jan 24 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Tobias Pankrath" <tobias pankrath.net> wrote in message 
news:jfmm43$1c99$1 digitalmars.com...

 Nick Sabalausky wrote:


 "Tobias Pankrath" <tobias pankrath.net> wrote in message
 news:jfkn05$h2n$1 digitalmars.com...

 Am I the only one who thinks this sounds like a horrible idea? :)


 It's horrible, but not as horrible as using straight JavaScript (or
 CoffeeScript, IMO).

 It's a necessary evil thanks to JavaScript's underserved ubiquity.


 Google Web Toolkit works quite well.


 I'd have a hard time trusting it. Would the resulting code necessarily 
 use
 Ajax even if I didn't want it to? How much JS overhead does it pull in 
 for
 simple uses of JS? Does the resulting code automatically interact with
 Google's servers in any way? How compatible is the resulting JS? Would 
 the
 resulting code break the page when JS is off? It's Google, for god's 
 sake,
 can they even be trusted at all? Etc.


 Can't see any technical argument here.


What's your point? Any one of them answered the wrong way would render it 
unusuable for my use-cases. Technical or not, that certainly makes them 
relevent.
Jan 24 2012
parent reply Tobias Pankrath <tobias pankrath.net> writes:
 What's your point? Any one of them answered the wrong way would render it
 unusuable for my use-cases. Technical or not, that certainly makes them
 relevent.


My point was, that compiling a language like D/Java to Javascript for 
web programming is an approach, that can work well.

Your arguments are all matters of trust (or the lack of) in an 
implementation and its implementor. Thus they don't apply in the
general case.
Jan 25 2012
parent "Nick Sabalausky" <a a.a> writes:
"Tobias Pankrath" <tobias pankrath.net> wrote in message 
news:jfoo3q$2ge8$1 digitalmars.com...

 What's your point? Any one of them answered the wrong way would render it
 unusuable for my use-cases. Technical or not, that certainly makes them
 relevent.


 My point was, that compiling a language like D/Java to Javascript for
 web programming is an approach, that can work well.

 Your arguments are all matters of trust (or the lack of) in an
 implementation and its implementor. Thus they don't apply in the
 general case.


Oh right. I wasn't talking about the general case at all, just that 
particular one. I absolutely agree that compiling a language down to JS is a 
valid approach. (It's no substitute for bypassing JS altogether of course, 
but that unfortunately isn't a realistic option for web developers at the 
moment.)
Jan 25 2012