[pifflesnort]

> Out of all the big browsers, Mozilla Firefox comes closest to being a web browser for the sake of web browsing.

There's a flip side to this coin; Firefox exists to support Mozilla's main business, which is the web.

This also means that Mozilla staunchly and without fail opposes any technological shift that could unseat the entrenched market position of the existing web technology stack, even if it would improve things for end users.

Google developed SPDY, NaCL, Dart, all in an effort to improve the underlying constraints of delivering code/information -- in any form -- to users.

If we only had Mozilla, we'd be locked into HTTP/HTML/CSS/DOM/JS forever. Technology has to evolve to move forward, but Mozilla has very little reason to want the web to evolve.

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

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

[sergiosgc]

How would replacing HTTP with SPDY offset Mozilla? It's not a threat. NaCL? NaCL is a different applet sandboxing, again not a threat to the browser or Mozilla. Dart? Dart is an alternative webpage scripting language (an alternative to Javascript).

Each of these does not threaten the importance of the browser. On the contrary, they both widen the use cases of the browser and raise the entry barrier for competing browsers. These effects protect Mozilla, instead of threatening Mozilla.

On the other hand, Google pushes OAuth single sign-on against Google accounts, whereas Mozilla is pushing Mozilla Persona, a distributed, no-central-authority SSO for the web.

I conclude the exact opposite of what you state. If we use Chrome, we're locked into technologies that serve Google, if we use Firefox we're pushing open technologies.

[scribu]

> Mozilla has very little reason to want the web to evolve.

What? Mozilla very much has a reason to want the web to evolve, in order to stay competitive with the various non-web mobile app ecosystems.

[pifflesnort]

That requires evolving to embrace the strengths of the non-web mobile app ecosystem -- which means evolving away from the web as Mozilla sees it: dom/js/css/html.

If you accept 'the web' as more of a conceptual ideal of openness, then there's a lot more room for innovation.

The problem is, at its core, that the people who are best suited to change the way the web works, are the developers that stuck it out through learning JavaScript, HTML, CSS, and browser quirks, and then spent the years required on top of that to begin working on the browsers themselves.

Of that self-selecting group, how many of them are likely to want to voluntarily rework and/or abandon core web technologies?

On the other hand, Chrome, existing to further Google's interests, has every reason to employ whatever creative technology solutions are necessary to improve the user experience, even if that means changing or abandoning the legacy web technology stack in the process.

[evilpie]

Not to mention the dozens of WebAPIs that Mozilla invented and are on the path to standardization.

[icebraining]

Mozilla has had XUL before Chrome was even a blueprint.