Surely the fact that NaCl is currently led by Google should not disqualify it from being a potentially valuable contribution to web apps. Most prevalent technologies started in this way, include js. And most started in a much less 'open' way than NaCl. The point surely is not where they originate but rather whether they offer enough distinctive value that they are compelling enough to be adopted more widely and hence become a key part of our ecosystem. Hence the question is, does NaCl have such a compelling value proposition? Evidently, in Brandan's eyes, and those of several of his colleagues, the answer is no. But other people can disagree and hope that the value is sufficient to eventually win over a broader market share. A good example of such a community is those with large code bases in say C, or C++ who would rather port their code than rewrite it all with all the ensuing maintenance problems. Imho NaCl does have something distinctive to offer and I wish the project well.
The State of JavaScript - Brendan Eich
181–190 of 266 posts
Re: The State of JavaScript - Brendan Eich
#182Aren't most of these language features already in the now defunct ES4 aka ActionScript 3? I'm just wondering why that language is never mentionned when it's already a glimpse in the future for Javascript (for better or worse ... who knows!)
Re: The State of JavaScript - Brendan Eich
#183Earlier quoted context omitted.
Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser? Why wouldn't other browsers have Pepper? Compilers are as good as what they've been tuned for. In my view PNaCl's shortcoming is startup time because it lacks a JIT and LLVM's back end is too slow for now. Speed up the backend or JIT code and you'll get close to GCC performance while being portable a…
> Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser? I think you answered your own question with the "save" part. The vendor shipping it with the browser means it controls it, it has responsibility for it, it secures it, and it allows it. End of story. > Why wouldn't other browsers have Pepper? JS is a necessity for a web browser/vendor, and is alrea…
I'll rephrase: why is any new VM to be relegated to the OS? The presence of incumbent VMs?
JS is an incumbent. Pepper is similar to nsapi, and has nice features which are compatible with HTML5's implementation (as in canvas). Saying it shouldn't be adopted because Nobody is adopting it is circular.
What are old-style plugins? Anything not JS?
Re: The State of JavaScript - Brendan Eich
#184Earlier quoted context omitted.
You seem to misunderstand "structs" -- see http://wiki.ecmascript.org/doku.php?id=harmony:binary_data , this is an extension of WebGL's typed arrays, which are already in all the new browsers (IE10 too). As for implicit coercions, I enjoyed Gary Bernhardt's "Wat", referred to it, and at past talks even mocked along with. At Strange Loop, I went through each "Wat" in the "Wat Secrets Revealed" slide series (use down a…
> You would opt into macrology redefining == to be === or whatever you want. Oh, please let the syntax for this be something like let == = ===; :-P
Let's not run an extra let statement if we don't have to!
if (== != === || == !== ===)
let == = ===;Re: The State of JavaScript - Brendan Eich
#185Earlier quoted context omitted.
Taking your points one at a time: 1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited. 2) Google is opposed to anyone else being more involved in the process. Other people have tried. 3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the…
> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing. > If PNaCl ever happens and is not directly tied to Chrome's internal…
> or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night.
Really now. I created that slide, taking the picture from Google's own NaCl web site:
https://developers.google.com/native-client/
I zoomed it in because I thought it looked pretty. Let's all just take a deep breath.
Dave
Re: The State of JavaScript - Brendan Eich
#186Earlier quoted context omitted.
> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing. > If PNaCl ever happens and is not directly tied to Chrome's internal…
> or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night. Really now. I created that slide, taking the picture from Google's own NaCl web site: https://developers.google.com/native-client/ I zoomed it in because I thought it looked pretty. Let's all just take a deep breath. Dave
Mea culpa on that point (the image). I drew the wrong conclusions about its intent.
Re: The State of JavaScript - Brendan Eich
#187Earlier quoted context omitted.
> Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser? I think you answered your own question with the "save" part. The vendor shipping it with the browser means it controls it, it has responsibility for it, it secures it, and it allows it. End of story. > Why wouldn't other browsers have Pepper? JS is a necessity for a web browser/vendor, and is alrea…
I'll rephrase: why is any new VM to be relegated to the OS? The presence of incumbent VMs? JS is an incumbent. Pepper is similar to nsapi, and has nice features which are compatible with HTML5's implementation (as in canvas). Saying it shouldn't be adopted because Nobody is adopting it is circular. What are old-style plugins? Anything not JS?
I said clearly why Pepper is not being adopted: it is a gigantic pile of API and implementation specified only by the C++ in chromium.org svn. Other browsers cannot port all that OS and WebKit glue code except at very high cost, direct and opportunity -- and even then on a bet that Pepper + NaCl wins, and again on a treadmill far behind Chrome.
Do you actually work on a browser codebase? If so, have you worked on competing browsers' codebases at all? Do you begin to see the problem? It's not quite Active X (open source is a small help), but it's on that slope and uphill only a bit.
Re: The State of JavaScript - Brendan Eich
#188> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…
PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format. PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified now…
I don't understand why you feel it necessary to make your points in such an inflammatory manner. Your arguments are well made, why do you feel the need to, for example, call someone 'astoundingly naive?' Being rude doesn't make your points more convincing and I would have hoped you were above that kind of thing. It's a pity because you have a huge amount to contribute.
Re: The State of JavaScript - Brendan Eich
#189Earlier quoted context omitted.
> (P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC And this is the argument he's making: that does not fly by browser vendors. They DON'T want to have code run OUTSIDE their VM/GC.
He said "including Chrome." Chrome supports NaCl. This does not compute.
It's not hard: Chrome sandboxes NaCl'ed code and links it against a runtime, Pepper. That's a "VM" by any other name.
Re: The State of JavaScript - Brendan Eich
#190Earlier quoted context omitted.
PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format. PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified now…
I don't understand why you feel it necessary to make your points in such an inflammatory manner. Your arguments are well made, why do you feel the need to, for example, call someone 'astoundingly naive?' Being rude doesn't make your points more convincing and I would have hoped you were above that kind of thing. It's a pity because you have a huge amount to contribute.
I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not.
Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it, in contrast to my fine counterpart. Yeesh!