Isn't there some overlap between BinaryAST and WebAssembly?
They aren't equivalent right now – there is a lot of stuff you can do in JavaScript you can't do in wasm yet. But, I thought the plan was to add a lot of those features (GC support, support for calling browser DOM APIs) to wasm at some point in the future. Once wasm gets those features, is BinaryAST really necessary? Couldn't a JS-to-wasm compiler work just as well?
a JS-to-wasm compiler would work, but probably not in the way that you are thinking.
Naively compiling static JS to wasm would produce extremely slow code. This is because there is almost no runtime type information to rely on to generate specialized code. Almost all of your operations are going to be compiled down to something like:
```
// impl of ADD operator on x, y.
if (isInt(x)) { // isInt is an AND and ADD.
if (isInt(y)) { // AND and ADD
let result = UnboxInt(x) + UnboxInt(y));
if result >= INT32_MAX { // handle overflow into double. }
else { return Box(result) }
} else {
let y2 = numberify(y);
let x2 = numberify(x);
...
} else if (isDouble(x)) { // also, AND and ADD
...
} else if (isString(x)) {
...
}
```
As you can see, this is horrid, large, and extremely slow. Some cases can be optimized based on static analysis and constant propagation, but the vast majority of executed operations cannot be predicted.
Executing JS with speed requires a runtime observation of the types that are showing up at different parts of the program, as well as the types that are stored in various heap slots, an infrastructure to track them and update them as the heap mutates and the program runs, and an infrastructure to query this information to speculatively compile optimized code for all the operations in the program.
This requires a runtime, and will always require a runtime. This means that if you want remotely fast javascript execution, then even a wasm-based solution will necessarily require shipping a JS-on-wasm runtime VM infrastructure along with your code, or for browsers to standardize on such a VM being bundled on distribution.
And all of this will have to happen after the feature support you mention in your comment (GC, DOM APIs), and at least one more (ability to hotpatch calls within wasm - this would allow us to introduce entry-points to jit-generated code in already-existing code).
Isn't there some overlap between BinaryAST and WebAssembly?
They aren't equivalent right now – there is a lot of stuff you can do in JavaScript you can't do in wasm yet. But, I thought the plan was to add a lot of those features (GC support, support for calling browser DOM APIs) to wasm at some point in the future. Once wasm gets those features, is BinaryAST really necessary? Couldn't a JS-to-wasm compiler work just as well?
a JS-to-wasm compiler would work, but probably not in the way that you are thinking.
Naively compiling static JS to wasm would produce extremely slow code. This is because there is almost no runtime type information to rely on to generate specialized code. Almost all of your operations are going to be compiled down to something like:
``` // impl of ADD operator on x, y. if (isInt(x)) { // isInt is an AND and ADD. if (isInt(y)) { // AND and ADD let result = UnboxInt(x) + UnboxInt(y)); if result >= INT32_MAX { // handle overflow into double. } else { return Box(result) } } else { let y2 = numberify(y); let x2 = numberify(x);
} else if (isDouble(x)) { // also, AND and ADD ... } else if (isString(x)) { ... } ```As you can see, this is horrid, large, and extremely slow. Some cases can be optimized based on static analysis and constant propagation, but the vast majority of executed operations cannot be predicted.
Executing JS with speed requires a runtime observation of the types that are showing up at different parts of the program, as well as the types that are stored in various heap slots, an infrastructure to track them and update them as the heap mutates and the program runs, and an infrastructure to query this information to speculatively compile optimized code for all the operations in the program.
This requires a runtime, and will always require a runtime. This means that if you want remotely fast javascript execution, then even a wasm-based solution will necessarily require shipping a JS-on-wasm runtime VM infrastructure along with your code, or for browsers to standardize on such a VM being bundled on distribution.
And all of this will have to happen after the feature support you mention in your comment (GC, DOM APIs), and at least one more (ability to hotpatch calls within wasm - this would allow us to introduce entry-points to jit-generated code in already-existing code).