6 ms·

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web As

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.

vvanders 9y ago
Yup, when you consider that WASM can be polyfilled with Asm.js it's pretty obvious where things were headed.
- jfbastien 9y ago
  Except with all browser vendors being involved with WebAssembly, efficient polyfill-ability hasn't been a goal for a while.
  - cromwellian 9y ago
    WASM has 64-bit ints, did asm.js support those? How can you polyfill that without a real slowdown.
    - recursive 9y ago
      A property with getter and setter backed by singleton typed array instance?
      - cromwellian 9y ago
        "without a real slowdown" Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
- wyldfire 9y ago
  What does that mean: "polyfilled with asm.js"?
  - bitmapbrother 9y ago
    That you can run asm.js code on wasm.
    - wyldfire 9y ago
      I suppose I should have asked "what does polyfill mean in this context?" Does that term really alias "run [it] on" or is there something more subtle about this term's meaning?
      - __s 9y ago
        There's a high performance asm.js implementation of WASM (converting WASM to asm.js at runtime). ie if a browser didn't implement WASM, but had a JIT which executed asm.js at high speed, it could execute WASM at high speed
        azakai 9y ago
        There isn't such a polyfill. There is currently no good tool to translate wasm into asm.js (or general JS) on the client. The best that exists is to run the wasm in a wasm interpreter, very slowly. In theory a translator could be written into asm.js, but there would still be wasm code that won't run fast, such as 64-bit ints, unaligned loads and stores, bitcasts, and other operations.
        johncolanduoni 9y ago
        Yes, but emscripten can compile to both (with or without using the new native LLVM WebAssembly backend). It's stretching the word polyfill, but emscripten users have pretty close to a turnkey solution for producing code that detects WebAssembly support and falls back to asm.js.
      - jholman 9y ago
        Web developers, bless their hearts, feel uncomfortable with the word "emulate", so they use "polyfill", or sometimes the more general "shim". To some degree, "polyfill" implies that the functionality being emulated/shimmed is functionality that is under some other circumstances is expected to be provided by the browser itself.
phonon 9y ago
Uhhh, I think you missed this-- https://wiki.mozilla.org/Mortar_Project https://wiki.mozilla.org/Mortar_Project
- withjive 9y ago
  Project Mortar is different in the fact that it is PDFium and Adobe Flash being allowed via Pepper API — basically it's for sandboxing those current native plugins. This would not be a public web use case. PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts. Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security. Mozilla wanted a more open web which led to Web Assembly.
  - indolering 9y ago
    Yeah, AFAIK PDFium doesn't use PNaCI and Flash will only be around as long as absolutely necessary. The only reason they aren't using PDF.js is because the PDf spec is ~12K pages long and they don't want to throw engineer resources at it anymore.
    - thristian 9y ago
      I'm sad to see PDF.js go. The PDF spec is ~12K pages long, and most of those pages describe things I don't want my PDF viewer to support, like embedded Flash, in much the same way I don't want my browser to support Flash. PDF.js is at a very comfortable nexus of compatibility and efficiency, and I kind of wish I could use it for non-web-PDFs as well (but not so much that I want to put it in an Electron wrapper).
      - Caspy7 9y ago
        PDF.js isn't "going" per se, but its lack of inclusion and development may certainly take wind out of its sails. It should still be possible as a PDF viewer in the browser (as an addon). And I think you can already use it (inside Firefox) to view non-web-PDFs.
bitmapbrother 9y ago
How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.
- withjive 9y ago
  What you said is true, however... I am referring to the initial offering of Native Client for inclusion into FireFox. Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed. Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable. We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible. Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap. Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.
- roca 9y ago
  Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which are now going by the wayside. Mozilla put together a small team and did asm.js to show that you could port C/C++ apps to the Web and get good performance while reusing the JS engine and all the existing Web platform APIs. Now we have WebAssembly, which uses existing Web platform APIs and which browser vendors are implementing by reusing the guts of their JS engines. It's obvious who won. In a way it doesn't matter "who won" because as you say Web developers are the ultimate winners. But it does underscore how much the Web continues to owe to Mozilla. (It's also an illustration of how powerful companies can commit massive blunders and get away scot-free in the marketplace and in PR.)
  - dragonwriter 9y ago
    There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted. That's a strategic victory for Google.
supremesaboteur 9y ago
Can you open a socket or write to the file system with WASM ?
- flohofwoe 9y ago
  You can only do what the browser sandbox provides, no direct access to the underlying operating system, only to HTML/JS APIs.
  - johncolanduoni 9y ago
    Notably JavaScript embedders that give more access (e.g. ChromeOS apps) do provide such interfaces.

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.

vvanders 9y ago

Yup, when you consider that WASM can be polyfilled with Asm.js it's pretty obvious where things were headed.

jfbastien 9y ago
Except with all browser vendors being involved with WebAssembly, efficient polyfill-ability hasn't been a goal for a while.
- cromwellian 9y ago
  WASM has 64-bit ints, did asm.js support those? How can you polyfill that without a real slowdown.
  - recursive 9y ago
    A property with getter and setter backed by singleton typed array instance?
    - cromwellian 9y ago
      "without a real slowdown" Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
wyldfire 9y ago
What does that mean: "polyfilled with asm.js"?
- bitmapbrother 9y ago
  That you can run asm.js code on wasm.
  - wyldfire 9y ago
    I suppose I should have asked "what does polyfill mean in this context?" Does that term really alias "run [it] on" or is there something more subtle about this term's meaning?
    - __s 9y ago
      There's a high performance asm.js implementation of WASM (converting WASM to asm.js at runtime). ie if a browser didn't implement WASM, but had a JIT which executed asm.js at high speed, it could execute WASM at high speed
      - azakai 9y ago
        There isn't such a polyfill. There is currently no good tool to translate wasm into asm.js (or general JS) on the client. The best that exists is to run the wasm in a wasm interpreter, very slowly. In theory a translator could be written into asm.js, but there would still be wasm code that won't run fast, such as 64-bit ints, unaligned loads and stores, bitcasts, and other operations.
        johncolanduoni 9y ago
        Yes, but emscripten can compile to both (with or without using the new native LLVM WebAssembly backend). It's stretching the word polyfill, but emscripten users have pretty close to a turnkey solution for producing code that detects WebAssembly support and falls back to asm.js.
    - jholman 9y ago
      Web developers, bless their hearts, feel uncomfortable with the word "emulate", so they use "polyfill", or sometimes the more general "shim". To some degree, "polyfill" implies that the functionality being emulated/shimmed is functionality that is under some other circumstances is expected to be provided by the browser itself.

phonon 9y ago

Uhhh, I think you missed this-- https://wiki.mozilla.org/Mortar_Project https://wiki.mozilla.org/Mortar_Project

withjive 9y ago
Project Mortar is different in the fact that it is PDFium and Adobe Flash being allowed via Pepper API — basically it's for sandboxing those current native plugins. This would not be a public web use case. PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts. Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security. Mozilla wanted a more open web which led to Web Assembly.
- indolering 9y ago
  Yeah, AFAIK PDFium doesn't use PNaCI and Flash will only be around as long as absolutely necessary. The only reason they aren't using PDF.js is because the PDf spec is ~12K pages long and they don't want to throw engineer resources at it anymore.
  - thristian 9y ago
    I'm sad to see PDF.js go. The PDF spec is ~12K pages long, and most of those pages describe things I don't want my PDF viewer to support, like embedded Flash, in much the same way I don't want my browser to support Flash. PDF.js is at a very comfortable nexus of compatibility and efficiency, and I kind of wish I could use it for non-web-PDFs as well (but not so much that I want to put it in an Electron wrapper).
    - Caspy7 9y ago
      PDF.js isn't "going" per se, but its lack of inclusion and development may certainly take wind out of its sails. It should still be possible as a PDF viewer in the browser (as an addon). And I think you can already use it (inside Firefox) to view non-web-PDFs.

bitmapbrother 9y ago

How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.

withjive 9y ago
What you said is true, however... I am referring to the initial offering of Native Client for inclusion into FireFox. Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed. Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable. We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible. Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap. Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.
roca 9y ago
Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which are now going by the wayside. Mozilla put together a small team and did asm.js to show that you could port C/C++ apps to the Web and get good performance while reusing the JS engine and all the existing Web platform APIs. Now we have WebAssembly, which uses existing Web platform APIs and which browser vendors are implementing by reusing the guts of their JS engines. It's obvious who won. In a way it doesn't matter "who won" because as you say Web developers are the ultimate winners. But it does underscore how much the Web continues to owe to Mozilla. (It's also an illustration of how powerful companies can commit massive blunders and get away scot-free in the marketplace and in PR.)
- dragonwriter 9y ago
  There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted. That's a strategic victory for Google.

supremesaboteur 9y ago

Can you open a socket or write to the file system with WASM ?

flohofwoe 9y ago
You can only do what the browser sandbox provides, no direct access to the underlying operating system, only to HTML/JS APIs.
- johncolanduoni 9y ago
  Notably JavaScript embedders that give more access (e.g. ChromeOS apps) do provide such interfaces.