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

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

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.

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>

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.

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.

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.

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?

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

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