4 ms·

Pepper was floated on plugin-futures@mozilla.org a long time ago, roc replied advocating not reinventing web APIs: https://mail.mozilla.org/pipermail/plugin-fu

Pepper was floated on plugin-futures@mozilla.org a long time ago, roc replied advocating not reinventing web APIs: https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html https://mail.mozilla.org/pipermail/plugin-futures/2010-April... The collaborative aspect is important, but one side of a coin whose other side is polyfillability. Nick Bray of the PNaCl team stubbed out Pepper.js more recently, and JS finally got some SIMD and threads love. It's all converging, finally. Yay!

JoshTriplett 11y ago
There are a few key aspects where web APIs will want to differ between JavaScript and WebAssembly, though. For instance, some APIs really do need 32-bit and 64-bit integers, not floating-point, and the APIs should be specified as accepting and returning values of those types. An API tailored to JavaScript would have to specify how to encode such a number into what JavaScript can express. Ditto for data structures (with actual layout, not JavaScript "bag of key-value properties" objects). Ultimately, I'm hoping new web APIs will be specified as a WebAssembly ABI, without taking JavaScript into account; the JavaScript interface to those APIs can be responsible for questions like "how do I call a function specified as taking a 64-bit unsigned integer?".
- BrendanEich 11y ago
  JS is getting int64 and uint64, so you need a better example, like zero-cost exceptions, dynamic linking, call/cc (listed in my post).
  - JoshTriplett 11y ago
    > JS is getting int64 and uint64 It's a fine example for today's browsers that don't have those. Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs. And it doesn't invalidate the point that JavaScript limitations should not be web limitations. For instance, how about efficient structs with defined in-memory layout? Targeting web APIs to WebAssembly means that the web can tell JavaScript to keep up, rather than JavaScript telling the web to wait up.
    - BrendanEich 11y ago
      Wait, how does wasm help APIs being designed today? Please use the same yardstick when comparing. Important that JS grow too, including SIMD, shared memory, value types including 64-bit int. Does not alter the case for wasm, per the FAQ: parse time win soon, divergence to relieve JS from serving two masters in longer run.
      - JoshTriplett 11y ago
        I'm using the same yardstick, relative to the baseline implementation of each language. APIs won't be able to natively target WebAssembly until browsers have native support for it. However, once browsers natively support WebAssembly, there won't need to be a "today's WebAssembly" versus "tomorrow's WebAssembly" issue; interesting new features belong in the languages targeting WebAssembly, with WebAssembly itself handling things like "how do we efficiently generate SIMD instructions on every target platform". Questions like "what datatypes do we support" become uninteresting; the answer is "whatever both ends of an ABI can agree on".
        BrendanEich 11y ago
        You wrote "Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs." and I asked "Wait, how does wasm help APIs being designed today?" Your different yardstick is the shift from "today" to "future". WebAsm that is a super of JS is in the future, past the polyfill era of co-expressiveness. Fault JS today for lacking int64 by the same (temporal) yardstick should fault wasm today. In general we agree, but you are arguing carelessly. There is no essential difference between int64 for JS in the future, and int64-equipped wasm in the future. Both are in the future. The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS. But it'll be a managed standards, so don't expect a huge iteration-time win. It'll be good for both JS and wasm in that farther future to decouple concerns, I agree. Are we done yet?
        JoshTriplett 11y ago
  - benjaminjackman 11y ago
    Can you link to where that is being discussed? I hadn't heard that int64 was being added. My google-fu has failed to turn up anything. int64 would be very useful for long types in ScalaJs. They run really slow because they have to be emulated with the whole split it into smaller parts stuff. Lots of jvm targetting code I have ported at work was written with the "just use a long, it's not much slower than an int" thought process, true on the JVM, not true in JS.
  - michaelsbradley 11y ago
    Any possibility for consideration of composable continuations as a WebAssembly language feature, e.g. shift/reset in Racket? See: Adding Delimited and Composable Control to a Production Programming Environment https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf

JoshTriplett 11y ago

There are a few key aspects where web APIs will want to differ between JavaScript and WebAssembly, though. For instance, some APIs really do need 32-bit and 64-bit integers, not floating-point, and the APIs should be specified as accepting and returning values of those types. An API tailored to JavaScript would have to specify how to encode such a number into what JavaScript can express. Ditto for data structures (with actual layout, not JavaScript "bag of key-value properties" objects). Ultimately, I'm hoping new web APIs will be specified as a WebAssembly ABI, without taking JavaScript into account; the JavaScript interface to those APIs can be responsible for questions like "how do I call a function specified as taking a 64-bit unsigned integer?".

BrendanEich 11y ago
JS is getting int64 and uint64, so you need a better example, like zero-cost exceptions, dynamic linking, call/cc (listed in my post).
- JoshTriplett 11y ago
  > JS is getting int64 and uint64 It's a fine example for today's browsers that don't have those. Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs. And it doesn't invalidate the point that JavaScript limitations should not be web limitations. For instance, how about efficient structs with defined in-memory layout? Targeting web APIs to WebAssembly means that the web can tell JavaScript to keep up, rather than JavaScript telling the web to wait up.
  - BrendanEich 11y ago
    Wait, how does wasm help APIs being designed today? Please use the same yardstick when comparing. Important that JS grow too, including SIMD, shared memory, value types including 64-bit int. Does not alter the case for wasm, per the FAQ: parse time win soon, divergence to relieve JS from serving two masters in longer run.
    - JoshTriplett 11y ago
      I'm using the same yardstick, relative to the baseline implementation of each language. APIs won't be able to natively target WebAssembly until browsers have native support for it. However, once browsers natively support WebAssembly, there won't need to be a "today's WebAssembly" versus "tomorrow's WebAssembly" issue; interesting new features belong in the languages targeting WebAssembly, with WebAssembly itself handling things like "how do we efficiently generate SIMD instructions on every target platform". Questions like "what datatypes do we support" become uninteresting; the answer is "whatever both ends of an ABI can agree on".
      - BrendanEich 11y ago
        You wrote "Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs." and I asked "Wait, how does wasm help APIs being designed today?" Your different yardstick is the shift from "today" to "future". WebAsm that is a super of JS is in the future, past the polyfill era of co-expressiveness. Fault JS today for lacking int64 by the same (temporal) yardstick should fault wasm today. In general we agree, but you are arguing carelessly. There is no essential difference between int64 for JS in the future, and int64-equipped wasm in the future. Both are in the future. The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS. But it'll be a managed standards, so don't expect a huge iteration-time win. It'll be good for both JS and wasm in that farther future to decouple concerns, I agree. Are we done yet?
        JoshTriplett 11y ago
- benjaminjackman 11y ago
  Can you link to where that is being discussed? I hadn't heard that int64 was being added. My google-fu has failed to turn up anything. int64 would be very useful for long types in ScalaJs. They run really slow because they have to be emulated with the whole split it into smaller parts stuff. Lots of jvm targetting code I have ported at work was written with the "just use a long, it's not much slower than an int" thought process, true on the JVM, not true in JS.
- michaelsbradley 11y ago
  Any possibility for consideration of composable continuations as a WebAssembly language feature, e.g. shift/reset in Racket? See: Adding Delimited and Composable Control to a Production Programming Environment https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf