6 ms·

"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't

"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!

Blackthorn 11y ago
If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...
- denniskane 11y ago
  Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.
- bobajeff 11y ago
  Either he's mixing narratives here or he's using standard web development practices as the context of it failing. Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.
josteink 11y ago
PNaCl is cancer to the web and requires Google Spyware. No thanks.
- denniskane 11y ago
  PNaCl allows me to run vim and python natively in my browser. Thanks. (Shout out to my boys, Sam Clegg, Brad Nelson and company!)
  - icebraining 11y ago
    Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/ https://brendaneich.com/2005/09/python-for-xul-scripting/
- derefr 11y ago
  PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.
  - mintplant 11y ago
    Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree. The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability. Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.
    - derefr 11y ago
      Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest. I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI. The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}. [1] http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf http://static.googleusercontent.com/media/research.google.co...
_wmd 11y ago
Supported by a single browser and based on a single (and the same) vendor's spec, which needlessly duplicates about half a web browser's functionality using a brand new API, and with no support due for other browsers any time soon
- denniskane 11y ago
  False. From the Native Client wikipedia page: As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.
  - eropple 11y ago
    All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.
    - denniskane 11y ago
      Okay, so let's examine the remaining browsers, shall we? Safari and IE/Edge automatically don't matter because they are exclusive to their respective [proprietary] host operating systems. That leaves Firefox. Does anyone really think there is legitimate competition between Chrome and Firefox anymore? I mean don't get me wrong, Firefox was a godsend in the bad old days of M$IE domination... But this is 2015, and Google is basically Skynet, while Firefox is not much more than a warm, fuzzy memory. Seriously... does anyone really want to turn this into a battle between Google and Mozilla?
      - nicalsilva 11y ago
        What? Whether or not a browser matters depends on the amount of people using it, not on whether you can install it on several operating systems.
        11y ago
corysama 11y ago
The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need to get all of the browser vendors (including IE and Safari) in agreement and on board synchronously to avoid years of "works only in Chrome and X". Asm.js "cheated" by creating a path forward that did not require consensus. Mozilla used it to innovate without needing to argue with anyone else. For other vendors, asm.js would technically "work" without other vendors putting in any technical or political investment. But, the hook was that if they didn't get on board eventually, their browsers would start to look bad if they ran asm.js sites poorly. WebAssembly is the outcome of Mozilla's trick. Now that all of the vendors have slowly become convinced over a period of years that there is a smooth, gradual path forward over the next several years that does not involve any technical or political chasms to cross, they are starting to work together to make it happen.
- bobajeff 11y ago
  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.
opinali 11y ago
And we used to think x86 was a bad design of native code.

Blackthorn 11y ago

If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...

denniskane 11y ago
Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.
bobajeff 11y ago
Either he's mixing narratives here or he's using standard web development practices as the context of it failing. Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.

josteink 11y ago

PNaCl is cancer to the web and requires Google Spyware. No thanks.

denniskane 11y ago
PNaCl allows me to run vim and python natively in my browser. Thanks. (Shout out to my boys, Sam Clegg, Brad Nelson and company!)
- icebraining 11y ago
  Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/ https://brendaneich.com/2005/09/python-for-xul-scripting/
derefr 11y ago
PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.
- mintplant 11y ago
  Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree. The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability. Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.
  - derefr 11y ago
    Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest. I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI. The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}. [1] http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf http://static.googleusercontent.com/media/research.google.co...

_wmd 11y ago

Supported by a single browser and based on a single (and the same) vendor's spec, which needlessly duplicates about half a web browser's functionality using a brand new API, and with no support due for other browsers any time soon

denniskane 11y ago
False. From the Native Client wikipedia page: As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.
- eropple 11y ago
  All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.
  - denniskane 11y ago
    Okay, so let's examine the remaining browsers, shall we? Safari and IE/Edge automatically don't matter because they are exclusive to their respective [proprietary] host operating systems. That leaves Firefox. Does anyone really think there is legitimate competition between Chrome and Firefox anymore? I mean don't get me wrong, Firefox was a godsend in the bad old days of M$IE domination... But this is 2015, and Google is basically Skynet, while Firefox is not much more than a warm, fuzzy memory. Seriously... does anyone really want to turn this into a battle between Google and Mozilla?
    - nicalsilva 11y ago
      What? Whether or not a browser matters depends on the amount of people using it, not on whether you can install it on several operating systems.
      - 11y ago

corysama 11y ago

The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need to get all of the browser vendors (including IE and Safari) in agreement and on board synchronously to avoid years of "works only in Chrome and X". Asm.js "cheated" by creating a path forward that did not require consensus. Mozilla used it to innovate without needing to argue with anyone else. For other vendors, asm.js would technically "work" without other vendors putting in any technical or political investment. But, the hook was that if they didn't get on board eventually, their browsers would start to look bad if they ran asm.js sites poorly. WebAssembly is the outcome of Mozilla's trick. Now that all of the vendors have slowly become convinced over a period of years that there is a smooth, gradual path forward over the next several years that does not involve any technical or political chasms to cross, they are starting to work together to make it happen.

bobajeff 11y ago
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.

opinali 11y ago

And we used to think x86 was a bad design of native code.