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.
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.
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.
> 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.
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?
reply