[pcwalton]

Mozilla has implemented SPDY.

Mozilla, Apple, and Microsoft will not implement NaCl and Dart because they feel that they are technically worse than alternatives (asm.js and either ES6 or compiling other languages to JS).

The technical problems will ultimately provide a worse experience to end users. For example, NaCl is not portable, meaning that users' apps will not work on all the users' devices like they expect, and PNaCl is not backwards compatible, so the apps won't work on all browsers. Dart threatens to make garbage collection slower because of cross-language cycle collection, which results in a worse experience to end users.

Mozilla has every reason to want the Web to evolve. If the Web doesn't evolve and loses to native platforms, Mozilla becomes irrelevant and dies. How is that not incentive?

[pifflesnort]

> Mozilla has implemented SPDY.

After Google designed it, developed it, and then deployed it to their properties. And even then Mozilla was still questioning whether it should be implemented, because "would anyone use it?".

> Mozilla, Apple, and Microsoft will not implement NaCl and Dart because they feel that they are technically worse than alternatives (asm.js and either ES6 or compiling other languages to JS).

We fundamentally disagree on that. I see NaCL as a route to the future of haardware-supported sandboxing, in the same way that virtualization was. NaCL is a way to fundamentally re-invision how we implement sandboxing of process, and move beyond the legacy ring-0 design.

asm.js is just another application-level hack on top of a huge pile of application-level hacks. It's time to coalesce the stack of these hacky abstractions, and clean up shop.

> For example, NaCl is not portable, meaning that users' apps will not work on all the users' devices like they expect, and PNaCl is not backwards compatible, so the apps won't work on all browsers.

So what? You know what happens when I fire up a PPC Mac from 1998 and try to use Netscape 4 on the modern web? Nothing works.

At least something like PNaCL has a MUCH smaller surface area than something like the full HTML/DOM/CSS/JS stack, which makes supporting it in a backwards compatible manner indefinitely far, far easier.

> Mozilla has every reason to want the Web to evolve. If the Web doesn't evolve and loses to native platforms, Mozilla becomes irrelevant and dies. How is that not incentive?

Because the web needs to evolve away from what it currently is, and that's the one thing Mozilla ideologically doesn't want and won't do.

[azakai]

> At least something like PNaCL has a MUCH smaller surface area than something like the full HTML/DOM/CSS/JS stack

PNaCl, to interact with the world, uses Pepper. Pepper is a huge surface area, comparable with the web stack in size.

[pifflesnort]

> Pepper is a huge surface area, comparable with the web stack in size.

It's neither comparable in size or complexity to the entire browser stack. CSS, HTML, DOM, and JavaScript are so large that they that require the full weight of large-scale corporations to provide a working implementation that's even remotely compatible with the web as its deployed today.

Mozilla received a leg-up in terms of having the majority of the code donated by a large corporation, and by having the web be compatible with that existing technology stack. I can see how I could spend $1M and have a team implement the Pepper API in 6-12 months, and that includes an independent implementation of NaCL/PNaCL sandboxing (if we leveraged google's development tools).

I can't even begin to imagine trying to create an independent browser stack for any reasonable amount of money.

[edit] This is the current Pepper API documentation:

https://developers.google.com/native-client/peppercpp/inheri...

It's tiny.

[azakai]

I didn't realize what you meant before. Yes, if you add the internal stuff of HTML and CSS, it is a lot. But Pepper is comparable in size to the APIs needed for general input and output on the web - both contain rendering, audio, input control, etc. In that respect they are comparable.

[pifflesnort]

The difference is that as a 3rd party, I actually have a snowball's chance in hell of implementing something like Pepper. This improves competitiveness and diversity.

Pepper, NaCL, et al also collapse a huge number of complex and nuanced layered web abstractions back down to the approachable problem of running somewhat arbitrary user code, at speed, in a relatively open and loosely define environment.

That's the same environment that projects like Mozilla needed to ever have the chance of producing a web browser in the first place. It sure seems to me that you guys -- consciously or not -- have divided the market into 'browser makers' and 'non-browser makers', and then decided to constrain the tooling and power available to everyone that is not a browser maker.

This can't be healthy for the internet.

[azakai]

The fact is, browsers evolved to render pages. HTML and CSS were invented for that, and JS added to make content more dynamic. So it's not surprising the web has the ability to render documents as a fundamental capability.

NaCl is something new. It isn't meant to render documents. It sandboxes native code.

Both the web and NaCl are great, just for different things.

[pifflesnort]

Given that the above text covers a ton of ground, I'm very curious what parts specifically downvoters are objecting to. Something about the comment (and its location in the thread) seems to have evoked a very negative response, but given the broad and very technical subject matter, I'm not sure exactly what or why.

[1] NaCL and the future of hardware, Google's investment in SPDY, surface area of NaCL's complexity, evolution of the web ...