3 ms·

I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture. Technic

I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture. Technically it was a plugin for Pepper and the only difference between it and Flash was that it was open source and only available to Chrome.

corysama 11y ago
In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's work together to figure out a better API" fixable. But, the idea that the huge, Chrome-specific API would be required to be incorporated into every other browser as-is and could not have been replaced in the last six years seems to be assumed as a fact of life.
- pcwalton 11y ago
  > The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable Agreed. Web Assembly is the solution :)
- denniskane 11y ago
  Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen. Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do. I think everyone has always known that NPAPI was eventually going to have to be completely overhauled or even replaced. For anyone to constantly harp on the idea that "all that matters is the open web" when they come from the very same organization -- although going by a different name -- for which the original binary plugin architecture was named (Netscape Plugin API) is just patently absurd. There is so much quality, freely available C/C++ code in this world that it is pretty mind boggling, and the purely technical achievement of allowing this code to be efficiently used by end users through the web platform is, again, a fairly mind boggling idea. I'm not saying that this web assembly concept won't have any use cases whatsoever in the future, but I am saying that the proven PNaCl technology that exists right now is way, way too powerful for any web-based applications developer worth his or her soul to pass up very easily.
  - pcwalton 11y ago
    > Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do. And implementing a modern JS engine isn't? Or developing Rust? Come on. The objections that many other browser vendors have to integrating PNaCl into the Web platform have been detailed repeatedly and have nothing to do with "X browser vendor doesn't have the talent on staff to implement the technology".

corysama 11y ago

In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's work together to figure out a better API" fixable. But, the idea that the huge, Chrome-specific API would be required to be incorporated into every other browser as-is and could not have been replaced in the last six years seems to be assumed as a fact of life.

pcwalton 11y ago
> The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable Agreed. Web Assembly is the solution :)
denniskane 11y ago
Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen. Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do. I think everyone has always known that NPAPI was eventually going to have to be completely overhauled or even replaced. For anyone to constantly harp on the idea that "all that matters is the open web" when they come from the very same organization -- although going by a different name -- for which the original binary plugin architecture was named (Netscape Plugin API) is just patently absurd. There is so much quality, freely available C/C++ code in this world that it is pretty mind boggling, and the purely technical achievement of allowing this code to be efficiently used by end users through the web platform is, again, a fairly mind boggling idea. I'm not saying that this web assembly concept won't have any use cases whatsoever in the future, but I am saying that the proven PNaCl technology that exists right now is way, way too powerful for any web-based applications developer worth his or her soul to pass up very easily.
- pcwalton 11y ago
  > Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do. And implementing a modern JS engine isn't? Or developing Rust? Come on. The objections that many other browser vendors have to integrating PNaCl into the Web platform have been detailed repeatedly and have nothing to do with "X browser vendor doesn't have the talent on staff to implement the technology".