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.
