23 ms·

> Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors

> Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. You keep repeating this, but I don't see how you can be remotely serious about it. Compared to JS, DOM, HTML, and CSS, Pepper is downright simple: https://developers.google.com/native-client/peppercpp/inherits https://developers.google.com/native-client/peppercpp/inheri... As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. On the other hand, I can't even imagine trying to write a full browser stack, including HTML(5), CSS, JS, et al, in one year for <= $2M? Not a chance. Yet you call Pepper "too big" and "too complex". Meanwhile, the enormous weight of the mess that is the web stack creates a huge barrier to entry for anyone that might want to meaningfully contribute new ideas to the space. We're already seeing interesting development occur around (the much more approachable) NaCL/Pepper: http://zerovm.org/ http://zerovm.org/ > That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. This is rich coming from the CTO that's refused to collaborate with Google and instead is going off and "misdirecting" energy on alternative approaches. > It's 2013 now and Dart is not going cross browser. You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.

tedmielczarek 14y ago
> As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. > Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. We have no basis to know whether "attempt to specify all out the ambiguitity in the Pepper API, using the Chromium implementation as the standard" is harder than "implement the already-fairly-well-specified set of web technologies". We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. > You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog. And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.
- pifflesnort 14y ago
  > But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. Unless you consider the possibility that: - Web apps versus web documents are two very different things - You see this as a way by which we could escape the mess and massive size of the current web stack by standardizing on a much smaller base. - Simplifying the core stack could open the door to new competition and innovation in the field. Personally, I'd love to see WebKit and/or Gecko and all the browser chrome implemented on top of NaCL and/or asm.js, with only the most minimal runtime, such that you're not sitting in a privileged position of running native code while the rest of us are stuck in JS/HTML/CSS hell. > We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. We also know that it's ridiculously expensive and difficult, in no small part due to the resistance to enforcing things like formal validation of HTML in the browser itself, creating a problem that's as much art as it is science. > And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate. Apple and Microsoft have no interest in undercutting their own vertically integrated platforms. Only you and Google have an strong interest in furthering the web, and yet, you refuse to work with Google despite them expending considerable time and money on furthering the web, while sharing their work freely.
BrendanEich 14y ago
We at Mozilla don't have $2M and a year to spare, but you're wrong: we've assessed doing Pepper with high fidelity (not porting chromium and duplicating all the DOM and other browser API implementations). It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill. But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work? Anyway, Pepper is big, with over a thousand methods among all the interfaces that are "specified" only by C++ implementation code we cannot port. We have a DOM implementation already, for example. So you cannot escape the fact that Pepper is "and also", not "instead of" -- there's no savings, it is purely added-cost, and significant cost. I'm almost the only guy who will say this on HN, but as far as I can tell, Microsoft and Apple are on the same page. Maciej Stachowiak of Apple has agreed on HN, for what it's worth: https://news.ycombinator.com/item?id=4648045 https://news.ycombinator.com/item?id=4648045 Enough whining about Mozilla not doing Pepper. Let's get back to asm.js. It looks like V8 will implement the optimizations for "use asm": http://code.google.com/p/v8/issues/detail?id=2599 http://code.google.com/p/v8/issues/detail?id=2599. Also, Epic is just the first big game publisher we are working with. Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only. But they are super-excited about cross-browser web-wide reach with asm.js and browser-hosted C++-sourced games. That's the PNaCl output format and runtime for Google to collaborate on. /be
- pifflesnort 14y ago
  > It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill. So you don't believe Google's offers to work with external implementors? > But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work? I run a systems programming consulting shop. We focus on low-level OS/driver and VM projects, with application development making up the remainder of our work. In theory, reliable estimates are my livelihood, and I have a very vested interest in the future of the platforms that we will have to develop for. I'm very concerned about the market requiring us to develop apps for a Mozilla platform. > Microsoft and Apple are on the same page What reason do they have to roll out something that helps Google undercut their vertical platform/app markets? If NaCL is 'too good', then it threatens their business. Take that for what it means in terms of asm.js optimization adoption. > Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only. CWS-only and Chrome-only are again, oddly, something you have a hand in. Google pushed out beta PNaCL tools, and CWS-only has primarily been (rightfully) pending PNaCL.

tedmielczarek 14y ago

> As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. > Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. We have no basis to know whether "attempt to specify all out the ambiguitity in the Pepper API, using the Chromium implementation as the standard" is harder than "implement the already-fairly-well-specified set of web technologies". We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. > You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog. And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.

pifflesnort 14y ago
> But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. Unless you consider the possibility that: - Web apps versus web documents are two very different things - You see this as a way by which we could escape the mess and massive size of the current web stack by standardizing on a much smaller base. - Simplifying the core stack could open the door to new competition and innovation in the field. Personally, I'd love to see WebKit and/or Gecko and all the browser chrome implemented on top of NaCL and/or asm.js, with only the most minimal runtime, such that you're not sitting in a privileged position of running native code while the rest of us are stuck in JS/HTML/CSS hell. > We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. We also know that it's ridiculously expensive and difficult, in no small part due to the resistance to enforcing things like formal validation of HTML in the browser itself, creating a problem that's as much art as it is science. > And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate. Apple and Microsoft have no interest in undercutting their own vertically integrated platforms. Only you and Google have an strong interest in furthering the web, and yet, you refuse to work with Google despite them expending considerable time and money on furthering the web, while sharing their work freely.

BrendanEich 14y ago

We at Mozilla don't have $2M and a year to spare, but you're wrong: we've assessed doing Pepper with high fidelity (not porting chromium and duplicating all the DOM and other browser API implementations). It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill. But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work? Anyway, Pepper is big, with over a thousand methods among all the interfaces that are "specified" only by C++ implementation code we cannot port. We have a DOM implementation already, for example. So you cannot escape the fact that Pepper is "and also", not "instead of" -- there's no savings, it is purely added-cost, and significant cost. I'm almost the only guy who will say this on HN, but as far as I can tell, Microsoft and Apple are on the same page. Maciej Stachowiak of Apple has agreed on HN, for what it's worth: https://news.ycombinator.com/item?id=4648045 https://news.ycombinator.com/item?id=4648045 Enough whining about Mozilla not doing Pepper. Let's get back to asm.js. It looks like V8 will implement the optimizations for "use asm": http://code.google.com/p/v8/issues/detail?id=2599 http://code.google.com/p/v8/issues/detail?id=2599. Also, Epic is just the first big game publisher we are working with. Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only. But they are super-excited about cross-browser web-wide reach with asm.js and browser-hosted C++-sourced games. That's the PNaCl output format and runtime for Google to collaborate on. /be

pifflesnort 14y ago
> It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill. So you don't believe Google's offers to work with external implementors? > But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work? I run a systems programming consulting shop. We focus on low-level OS/driver and VM projects, with application development making up the remainder of our work. In theory, reliable estimates are my livelihood, and I have a very vested interest in the future of the platforms that we will have to develop for. I'm very concerned about the market requiring us to develop apps for a Mozilla platform. > Microsoft and Apple are on the same page What reason do they have to roll out something that helps Google undercut their vertical platform/app markets? If NaCL is 'too good', then it threatens their business. Take that for what it means in terms of asm.js optimization adoption. > Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only. CWS-only and Chrome-only are again, oddly, something you have a hand in. Google pushed out beta PNaCL tools, and CWS-only has primarily been (rightfully) pending PNaCL.