
Faster Script Loading with BinaryAST? - bzbarsky
https://blog.cloudflare.com/binary-ast/
======
skissane
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?

~~~
kannanvijayan
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).

