5 ms·

So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation? Ironic that Ei

by rockdoe 11y ago

So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation? Ironic that Eich is the one to pull the trigger on JS.

pcwalton 11y ago
It's not "pulling the trigger" on JS—per the FAQ, it's fully polyfillable and typically implemented inside the JS engine, as essentially a separate interface to all the implementation work that's already there. This is a crucial difference from everything that's been tried before (including PNaCl). JS isn't going anywhere and continues to be improved.
- JoshTriplett 11y ago
  > JS isn't going anywhere Sure it is. Step 1: get all browsers to support WebAssembly, so that sites can drop the polyfills. Step 2 (specifically noted in the article): make WebAssembly more full-featured than JavaScript, ignoring the ability to polyfill it because browsers have native support. Step 3 (potentially doable before 2): implement JavaScript in WebAssembly, so it becomes just one of many possible languages, and its implementation is no longer beholden to browser quirks. That'll make JavaScript a better language for its proponents (latest ECMAScript features everywhere), and entirely avoidable for people who prefer other languages.
  - trbent 11y ago
    There are a lot of web coders who seem to believe in the most outlandish ideas and who act as if coding ever more rickety stacks is progress.
  - BrendanEich 11y ago
    Dream on. JS is "obligate, not facultative", as biologists say, for browser implementors. It lives in source form on the web and must load super-fast. We can wager about when it might actually die (I said it might given something like wasm, at Strange Loop 2012), but that's beyond the horizon by years if not decades. Gary Bernhardt knows!
    - JoshTriplett 11y ago
      People build latest-ECMAScript polyfills today. Future such implementations will likely use WebAssembly. And anything caring about performance can start targeting WebAssembly directly rather than JavaScript. CPU-bound JavaScript performance will start mattering a lot less. (DOM-access performance will still be critical, but it will be for WebAssembly too.)
      - BrendanEich 11y ago
        You moved the goal post from dropping JS (again, dream on) to (in the future) using wasm as compiler and polyfill target. S'ok, I'm obv. a supporter of the latter, although it'll take some time to make win for smaller programs.
        JoshTriplett 11y ago
        > You moved the goal post from dropping JS (again, dream on) to (in the future) using wasm as compiler and polyfill target. I'm not suggesting dropping JS; that's too much to hope for. If nothing else, backward compatibility with existing sites will require supporting it approximately forever. I never intended to imply dropping it, just that WebAssembly becomes the interoperable baseline, with JavaScript and other languages being peers on that common baseline. I disagreed with the statement that "JS isn't going anywhere"; I don't think it's going away, but it's clearly going to evolve and go new places.
        megaman821 11y ago
        This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser.
        JoshTriplett 11y ago
        > This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, It won't have zero performance overhead, since unfortunately it will still require translation to native code. But it'll be far higher-performance than asm.js, and precompiling JavaScript to WebAssembly could produce higher performance than a JavaScript JIT. > and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser. You don't need to do the compilation in the browser; do the compilation ahead of time and ship wasm bytecode. The DOM and all other web APIs will still be provided by the browser, so I don't see any obvious reason why wasm needs to have substantial size overhead compared to JavaScript.
  - pcwalton 11y ago
    No browser is going to implement JS in Web Assembly anytime soon. You have no idea how tight the performance margins are on SunSpider and the V8 benchmarks, for example. The entire compilation pipeline has to be lightning fast; adding another IR will kill you. Web sites move to new technology at a glacial pace. You're posting this comment on a Web site that, by and large, hasn't even adopted CSS 1.0 for layout yet.
BrendanEich 11y ago
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.

by rockdoe 11y ago

So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation? Ironic that Eich is the one to pull the trigger on JS.

pcwalton 11y ago

It's not "pulling the trigger" on JS—per the FAQ, it's fully polyfillable and typically implemented inside the JS engine, as essentially a separate interface to all the implementation work that's already there. This is a crucial difference from everything that's been tried before (including PNaCl). JS isn't going anywhere and continues to be improved.

JoshTriplett 11y ago
> JS isn't going anywhere Sure it is. Step 1: get all browsers to support WebAssembly, so that sites can drop the polyfills. Step 2 (specifically noted in the article): make WebAssembly more full-featured than JavaScript, ignoring the ability to polyfill it because browsers have native support. Step 3 (potentially doable before 2): implement JavaScript in WebAssembly, so it becomes just one of many possible languages, and its implementation is no longer beholden to browser quirks. That'll make JavaScript a better language for its proponents (latest ECMAScript features everywhere), and entirely avoidable for people who prefer other languages.
- trbent 11y ago
  There are a lot of web coders who seem to believe in the most outlandish ideas and who act as if coding ever more rickety stacks is progress.
- BrendanEich 11y ago
  Dream on. JS is "obligate, not facultative", as biologists say, for browser implementors. It lives in source form on the web and must load super-fast. We can wager about when it might actually die (I said it might given something like wasm, at Strange Loop 2012), but that's beyond the horizon by years if not decades. Gary Bernhardt knows!
  - JoshTriplett 11y ago
    People build latest-ECMAScript polyfills today. Future such implementations will likely use WebAssembly. And anything caring about performance can start targeting WebAssembly directly rather than JavaScript. CPU-bound JavaScript performance will start mattering a lot less. (DOM-access performance will still be critical, but it will be for WebAssembly too.)
    - BrendanEich 11y ago
      You moved the goal post from dropping JS (again, dream on) to (in the future) using wasm as compiler and polyfill target. S'ok, I'm obv. a supporter of the latter, although it'll take some time to make win for smaller programs.
      - JoshTriplett 11y ago
        > You moved the goal post from dropping JS (again, dream on) to (in the future) using wasm as compiler and polyfill target. I'm not suggesting dropping JS; that's too much to hope for. If nothing else, backward compatibility with existing sites will require supporting it approximately forever. I never intended to imply dropping it, just that WebAssembly becomes the interoperable baseline, with JavaScript and other languages being peers on that common baseline. I disagreed with the statement that "JS isn't going anywhere"; I don't think it's going away, but it's clearly going to evolve and go new places.
        megaman821 11y ago
        This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser.
        JoshTriplett 11y ago
        > This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, It won't have zero performance overhead, since unfortunately it will still require translation to native code. But it'll be far higher-performance than asm.js, and precompiling JavaScript to WebAssembly could produce higher performance than a JavaScript JIT. > and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser. You don't need to do the compilation in the browser; do the compilation ahead of time and ship wasm bytecode. The DOM and all other web APIs will still be provided by the browser, so I don't see any obvious reason why wasm needs to have substantial size overhead compared to JavaScript.
- pcwalton 11y ago
  No browser is going to implement JS in Web Assembly anytime soon. You have no idea how tight the performance margins are on SunSpider and the V8 benchmarks, for example. The entire compilation pipeline has to be lightning fast; adding another IR will kill you. Web sites move to new technology at a glacial pace. You're posting this comment on a Web site that, by and large, hasn't even adopted CSS 1.0 for layout yet.

BrendanEich 11y ago

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.