4 ms·

Well, it grew out of ASM.js, so not really an accident. https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly "the initial implem

Well, it grew out of ASM.js, so not really an accident. https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly "the initial implementation was based on the feature set of asm.js." https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js NaCL tried more to be a real assembly language but had cross-platform issues.

pjmlp 3y ago
Hence why PNaCL came to be.
- capitainenemo 3y ago
  Huh. I thought PNaCL had cross-platform endian issues from what I'd read at the time. However: https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html https://www.tomshardware.com/news/chrome-deprecates-pnacl-em... Just mentions API concerns and: https://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html?gad_source=1 https://robert.ocallahan.org/2013/05/blink-pnacl-and-standar... " PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. " and "1. NaCl is CPU-specific. That's not suitable for the web. 2. PNaCl is in theory portable, so it is potentially worth considering. 3. However there is no spec for PNaCl, and standardizing it would take an extreme amount of effort: It means standardizing a subset of LLVM IR, which is quite rich and complex, as well as the Pepper plugin API. This is an enormous amount of work that has not even been begun by Google AFAIK." But you're right, I don't see anyone mentioning any hardware complications. Oh well. Moot point these days, and I think we're all better off that everyone else stood their ground, in terms of security, integration with JS APIs, and having a variety of WASM implementations.
  - capitainenemo 3y ago
    (And I'm sure the situation would have been very different nowdays, with a google controlled engine dominating 95% of browsers)

pjmlp 3y ago

Hence why PNaCL came to be.

capitainenemo 3y ago
Huh. I thought PNaCL had cross-platform endian issues from what I'd read at the time. However: https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly,34583.html https://www.tomshardware.com/news/chrome-deprecates-pnacl-em... Just mentions API concerns and: https://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html?gad_source=1 https://robert.ocallahan.org/2013/05/blink-pnacl-and-standar... " PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. " and "1. NaCl is CPU-specific. That's not suitable for the web. 2. PNaCl is in theory portable, so it is potentially worth considering. 3. However there is no spec for PNaCl, and standardizing it would take an extreme amount of effort: It means standardizing a subset of LLVM IR, which is quite rich and complex, as well as the Pepper plugin API. This is an enormous amount of work that has not even been begun by Google AFAIK." But you're right, I don't see anyone mentioning any hardware complications. Oh well. Moot point these days, and I think we're all better off that everyone else stood their ground, in terms of security, integration with JS APIs, and having a variety of WASM implementations.
- capitainenemo 3y ago
  (And I'm sure the situation would have been very different nowdays, with a google controlled engine dominating 95% of browsers)