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

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

Well, now we're getting to the core of it! :)

I agree! I think the web should stick to rendering documents, which it has always done reasonably well, and leave applications to technologies such as NaCL, which people can use to produce the next web browser.

[azakai]

I almost agree. But I don't think the web should stop from improving just because there is stuff like NaCl. If it's easy and straightforward to run code at near-native speeds in JS, and it took just a few months to build the asm.js prototype, then why not?