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!
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?".
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.
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.
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.
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".
"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.
I'm talking about the meta-problem here: APIs designed today have to care about today's JavaScript semantics, which are high-level JavaScript-specific constraints. APIs designed for browsers with native wasm support care about the semantics of wasm, but those semantics are language-agnostic. APIs should be designed based on a language-agnostic ABI, not based on JavaScript. That's the world I'm looking forward to.
Even the planned future ABI for interoperable dynamic linking is a guideline; any caller and callee that agree can use a different, extended ABI.
> 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.
Of course, and that's exactly the world I'm talking about.
> But it'll be a managed standards, so don't expect a huge iteration-time win.
WebAssembly is in a very critical way smaller than JavaScript, so its iteration time is less important. wasm iterations will be important for performance (to provide constructs that will efficiently translate to the native machine code you or a compiler would have written), and we'll need new APIs for things like thread-spawning, but new language features and functions using those features won't require any changes to wasm.
> Are we done yet?
By all means let's stop violently agreeing with each other. :) Thanks for working on WebAssembly; I look forward to using it.
Regardless of the timing and the specific example of int64/uint64, isn't the benefit being discussed by JoshTriplett the same thing you are talking about with divergence? If the low-level language of the web is divorced from JS so that each can evolve independently, future web APIs that are designed to be consumed from multiple (high-level) languages can be specified in terms of structures that can be represented in the low-level language, and high-level language-specific bindings to the low-level APIs can present an interface customized to the type systems and idioms of the specific high-level language with the appropriate low-level shims to convert to the low-level representation.
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.
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.
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.
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!
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.)
I predict that, five years from now, people will still be caring a great deal about JavaScript's CPU-bound performance. Even if all new code switched en masse to Web Assembly tomorrow (which won't happen) people would still want existing content to run as fast as possible.
> 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.
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.
> 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.
So much in this thread suggests that influence will be exerted to permanently weld wasm's semantics to Javascript's from day one, so that there will never be a viable compile target that isn't just Javascript. In that case, wasm will be nothing but a Coffeescript-like facade over Javascript semantics, and anyone targeting wasm is really only writing Javascript in an inefficient way, and Javascript is the only first-class language, forever.
If wasm is already intended to be crippled relative to Javascript, it really throws into question why wasm should exist at all. When the response to eventually implementing Javascript on top of browser wasm support is "dream on," like because Javascript on top of wasm will suck because it leaves too much performance on the table, that raises the question of why we think building on top of wasm will be acceptable for languages other than Javascript. If building on top of wasm is unacceptable for Javascript, why isn't it unacceptable for everyone else?
Maybe this also throws into question whether any discussions supposedly shaping the development of a new cross-vendor standard are really in good faith, if the reality will be that nothing new is made other than a new spelling of Javascript, and that wasm will be forever steered by Javascript and incapable of meaningfully hosting an implementation of Javascript because it has been intentionally crippled to require an implementation of Javascript.
Anyone who wants wasm to become a real thing has to be cautious that it is not crippled in order to prevent it from being capable of replacing Javascript (whether it actually does replace Javascript is another issue which can really only be asked if we assume wasm is not already sabotaged to be incapable of that).
Ironic that Eich is the one to pull the trigger on JS.