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 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
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 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
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.

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 "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 "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 next sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
--20cf3011da15030e8e04b734dd08
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

--20cf3011da15030e8e04b734dd08
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A CPPCMS-like framework would be far more interesting for D :=C2=A0
<a href=3D"http://cppcms.sourceforge.net/wikipp/en/page/main">http://cppcms=
.sourceforge.net/</a><div><br></div><div>Jo=C3=ABl Lamotte</div>

--20cf3011da15030e8e04b734dd08--
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 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 next sibling 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 "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
next sibling 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
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
prev 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 next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
--14dae93411176dbf0404b75459d5
Content-Type: text/plain; charset=UTF-8

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

--14dae93411176dbf0404b75459d5
Content-Type: text/html; charset=UTF-8

Let just make sure D can compile for NaCl and wait for it to be on other
browsers than Chrome...<div><br></div><div>Native code should be executed in
native.</div><div><div><br></div><div>Klaim</div></div>

--14dae93411176dbf0404b75459d5--
Jan 24 2012