[haberman]

The significant substantive differences, to me as a reader, are:

- You don't make final-sounding judgments like "never" or "non-starter" that preemptively reject any future evolution of the technology.

- Your criticisms are highly pragmatic and specific, such that it is clear what hurdles the technology would have to clear to address them, and you don't close the door to the idea that they could (even if it seems unlikely to you).

- You don't fall back on ideological arguments like native code as a "social ill" that would suggest that your true objections run deeper than what any technical improvements could possibly address.

Thank you for that.

[othermaciej]

Wow, I didn't notice that the thread continued for so long after I posted.

The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state.

My "highly pragmatic and specific" criticisms seem to me like they say the same thing as Brendan's original slide bullets, just with more detail. I did not mention "no view source", but I agree that is a significant downside, if not necessarily as much of a showstopper as the others. Being a single-vendor-controlled technology is the biggest showstopper.

Another big issue that I didn't mention, and which I think also aligns with Brendan's criticisms, is that adding a major new technology to the web platform requires tremendously compelling use cases and a good argument that they cannot be handled with existing technologies. I don't think that case has really been made for NaCl.

And yes, I did jokingly coin the term "ActiveG" to refer to NaCl. Though I believe it was another wag who later referred to Dart as "GBScript".

[haberman]

Oh hey, I just saw this now.

For what it's worth I thought you were from Mozilla when I wrote my post, not that it matters that much either way.

I think you made some substantial points that were not covered in Brendan's slides, specifically:

- A standard with only one implementation is de facto controlled by one entity. This is a great point, and different than Brendan's point "defined by implementation." Brendan's criticism would be solved simply by standardizing (P)NaCl under multi-party governance, which I fully expect Google will do at some point. [0] Your criticism is not solved unless it is actually practically feasible for someone else to implement that standard.

- Relying on binary-level validation of binary code has a lot of attack surface. This is a great point that I've seen others make, though I believe it is being addressed (perhaps since you wrote your message) by having multiple layers of defense (ie. also running in a separate process inside a ptrace sandbox).

It doesn't bother me that you joke around with your friends by calling it "ActiveG," because in the context of serious discussion you acknowledge that it has "a better attempt at security design than ActiveX." It does bother me when others seriously compare the two, as if a completely unsandboxed execution environment can be compared to a serious attempt at sandboxing.

In any case, now that it supposed to be shipping soon (http://news.cnet.com/8301-1023_3-57534803-93/google-offers-l...) we should get a better chance to see if it truly can demonstrate a compelling improvement over JavaScript.

[0] Just wanted to mention that though I work for Google I am not involved in (P)NaCl and have no inside information about it.

[BrendanEich]

The purpose of my "final-sounding judgments" is to cut the crap in the short term that keeps getting dumped on Mozilla by you and others with an enlarged sense of entitlement, and an unjustified assumption that NaCl/PNaCl + Pepper is somehow "better" in the large, and so should get free support from non-Chrome browsers.

If you think overcoming some hurdles enumerated by Maciej will get PNaCL and Pepper support into Safari (where, BTW, Pepper is closest to porting cleanly by any measure, e.g., patch size), you're dreaming. Remember, I did not coin the funny "Active G" phrase. That shoe was fit by the guy you're trying to suck up to here.

If an indefinite-future-tense, and therefore worthless, promise from me to be open to portable SuperPNaCl in 2020, will get you to stop bashing Mozilla and flattering Apple, then here it is. Indeed my plan is for JS to evolve and mutate to be that portable object format for native code to compile to.

Emscripten is a promising sign along this path. And the PNaCl folks are targeting JS too, I hear, so this looks like a common goal.

Now can you stop defaming Mozilla?

/be

[askimto]

Now can you start ignoring haberman like you said you would? Your belligerent comments are getting a bit old at this point. You hate NaCl. We get it. Criticizing a slide makes you upset. OK. Understood.

[BrendanEich]

I always reply when I have something worth saying.

"Hate" is the wrong word. There's nothing to hate in a well-done SFI-enforcing compiler. I admire the R&D effort. We -- bad old Mozilla, including evil-me -- are seriously considering using NaCl (not Pepper) for SFI in native code parts of Servo. No "hate" here, so do try to grow up: "You hate NaCl" is just weak, beneath you, as an analysis of motives and causes.

Let's step away from NaCl as pure tech for safer compilation of unsafe languages.

I do call Google's business strategy pushing NaCl+Pepper via games and even (till it all fell apart last November) Flash heavy-handed, and one-sided to such an extent that what's pushed can never be standardized.

What's belligerent here is for someone (haberman), who I hear works for Google, a company that has all the money and power in the world, and which makes actual "pro-NaCl propaganda" as well as pays game developers and others to use the Chrome-only tech (NaCl, not PNaCl, note well), to fire first on this thread. It wasn't me who showed "belligerence".

That first shot even tried open-washing, lamely, and it tellingly put Mozilla in the subordinate position. ''I could understand "we want to be more involved in the process."''

If you don't work for Google or hold a brief for them, ask yourself why haberman's presumption is that Mozilla, or any other browser maker, should be asking or begging to be included in a process that we were excluded from and practically speaking could never participate in without equal big bucks and market power.

The great thing about the Web is that no one owns it. Browser vendors, tool makers, and developers (whom the first two groups avidly court) have to reach consensus via standards. And I find that developers, not just pure web devs, definitely including @kripken (Emscripten's creator), @jashkenas (CoffeeScript), and others, are more creative and faster moving than many highly-paid C++-first hackers, including those perpetrating single-vendor follies such as NaCl+Pepper.

Whine at me, cry "hate" and "belligerence" while turning a blind eye to the big gun who fired first, and shoot the messenger. It doesn't matter. NaCl+Pepper have already lost to JS for portable cross-browser high-performance native code compilation.

[gunsmith]

That's why you have been supporting Emscripten with... just one developer, it's creator? Shouldn't there be a whole team towards this goal you envision?

Currently emscripten should have the amount of people three.js has.

[BrendanEich]

There is a team working on the longer-term goal, including game platform, JS engine, and Mozilla Research people. Why did you assume otherwise?

Also, Emscripten has a strong github community. Unlike Google we can't afford to pay everyone who might be needed -- we also prefer not to if we can build a wider community from day one.

[askimto]

Ah I see I should have said "Google" where I said "NaCl". My mistake.

[BrendanEich]

You're doing better! But no, I don't "hate" Google. Big companies and big groups of people in general have inherent morally failure-prone properties. Google fights these, and in many ways still manages "don't be evil".

Heavy-handed and one-sided strategies and tactics may be odious, I may "hate" them -- you should too if they're not well-justified and likely to prevail -- but that's not the point of this exchange, which haberman started. Nice try deflecting, though.

The point of my slide, and of my comments here, is to make the case for what's best for the Web. So let's get back to that.

What is best for the Web? Not NaCl, we all agree. PNaCl? Not with Pepper as a mandatory API for all browsers to adopt. And PNaCl has a JS back end.

Steve Jobs killed Flash. Plugins are in decline. However well Google, Mozilla, and others use NaCl for native code safety, on the Web JS looks highly likely to continue, and to get super-fast for the well-typed and GC-free code produced by Emscripten.

This all points to a future where evolved JS is the PNaCl format that works cross-browser. We're already working on this at Mozilla, but via Emscripten not PNaCl. If Google aims its formidable engineers at the same goal and works in the standards bodies early and fairly, great. I'd love that.

[gunsmith]

Do you think the current status of Emscripten justifies your words? We'd all like to believe that.