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

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

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

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.

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

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

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