View mode: basic / threaded / horizontal-split · Log in · Help
January 23, 2012
Re: D for the web?
>> 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.
January 24, 2012
Re: D for the web?
"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.
January 24, 2012
Re: D for the web?
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.
January 24, 2012
Re: D for the web?
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>
January 24, 2012
Re: D for the web?
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.
January 24, 2012
Re: D for the web?
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.
January 24, 2012
Re: D for the web?
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.
January 24, 2012
Re: D for the web?
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?
January 24, 2012
Re: D for the web?
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".
January 24, 2012
Re: D for the web?
"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.
1 2 3
Top | Discussion index | About this forum | D home