Towards a JavaScript Binary AST

From an alternate "not the web" viewpoint, I am interested in this because we have a desktop application that bootstraps a lot of JS for each view inside the application. There is a non-insignificant chunk of this time spent in parsing and the existing methods that engines expose (V8 in this case) for snapshotting / caching are not ideal. Given the initial reported gains, this could significantly ratchet down the parsing portion of perceived load time and provide a nice boost for such desktop apps. When presented at TC39, many wanted to see a bit more robust / scientific benchmarks to show that the gains were really there.

Haha, I did enjoy this comment. It's kinda fair, but also kinda not.

At each step developers are trying to create the best thing they can with the tools at their disposal. There will always be a tradeoff between flexibility and ease of use. There's a reason Electron exists — the browser has limitations that are easier to work around in Electron. There's a reason we moved to putting stuff online, we could write it once and distribute it everywhere.

To clarify how this is not related to WebAssembly, this is for code written in JavaScript, while WASM is for code written in other languages.

It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed.

WASM doesn't currently have built-in garbage collection, so to use it to compress/speed up/whatever JavaScript, you would have to compile an entire JavaScript Virtual Machine into WASM, which is almost certainly going to be slower than just running regular JavaScript in the browser's built-in JS engine.

(This is true for the time being, anyway. WASM should eventually support GC at which point it might make sense to compile JS to WASM in some cases.)

Let me clarify things one last time.

You are obviously very passionate and I believe that nothing I can write will convince you, so I will not pursue this conversation with you after this post.

For the same reason, my answers here are for people who have not followed the original HN thread in which we have already had most of this conversation.

I also believe that the best way for you to demonstrate that another approach is better than the JavaScript Binary AST would be for you to work on demonstrating your approach, rather than criticizing this ongoing work.

> - WebAssembly does not support JS hence we need binary AST

> WebAssembly is on track to support dynamic and GC-ed languages

If/when WebAssembly gains the ability to interact with non-trivial JS objects, JS libraries, etc. we will be able to compare the WebAssembly approach with the Binary AST approach. GC support and dynamic dispatch are prerequisites but are not nearly sufficient to allow interaction with non-trivial JS objects and libraries.

So let's meet again and rediscuss this if/when this happens.

> - WebAssembly will be slower than binary AST

> You've provided zero support for this statement. Meanwhile experiments with real apps (like Figma) show significant improvements with WebAssembly

If you recall, we are only talking about loading speed. I believe that there is no disagreement on execution speed: once WebAssembly implementations are sufficiently optimized, it is very likely that well-tuned WebAssembly code will almost always beat well-tuned JS code on execution.

The argument exposed on the blog is that:

- attempting to compile JavaScript to existing WebAssembly is very hard (hard enough that nobody does it to the best of my knowledge);

- the specifications of JavaScript are complex enough that every single object access, every single array access, every single operator, etc. is actually a very complex operation, which often translates to hundreds of low-level opcodes. Consequently, should such a compilation take place, I suspect that this would considerably increase the size of the file and the parsing duration;

- by opposition, we have actual (preliminary) numbers showing that compressing to JavaScript Binary AST improves both file size and parse time.

While I may of course be wrong, the only way to be sure would be to actually develop such a compiler. I have no intention of doing so, as I am already working on what I feel is a more realistic solution, but if you wish to do so, or if you wish to point me to a project already doing so, I would be interested.

You refer to the experiments by Figma. While Figma has very encouraging numbers, I seem to recall that Figma measured the speedup of switching from asm.js to WebAssembly. In other words, they were measuring speedups for starting native code, rather than JS code. Also a valid experiment, but definitely not the same target.

> - No one wants to ship bytecode

> False

Are we talking about the same blog entry?

What I claimed is that if we ended up with one-bytecode-per-browser or worse, one-bytecode-per-browser-version, the web would be much worse than it is. I stand by that claim.

> - it's hard to align browsers on bytecode

> See WebAssembly

I wrote the following things:

- as far as I know, browser vendors are not working together on standardizing a bytecode for the JavaScript language;

- coming up with a bytecode for a language that keeps changing is really hard;

- keeping the language-as-bytecode and the language-as-interpreted in sync is really hard;

- because of the last two points, I do not think that anybody will start working on standardizing a bytecode for the JavaScript language.

In case of ambiguity, let me mention that I am part of these "browser vendors". I can, of course, be wrong, but once again, let's reconvene if/when this happens.

> - you can't change bytecode once it's shipped

> You can, eventually. Same argument can be applied to binary AST

I claimed that no browser vendor seriously contemplates exposing their internal bytecode format because this would make the maintenance of their VM a disaster.

Indeed, there is an order of magnitude of difference between the difficulty of maintaining several bytecode-level interpreters that need to interact together in the same VM (hard) and maintaining several parsers for different syntaxes of the same language (much easier). If you know of examples of the former, I'd be interested in hearing about them. The latter, on the other hand, is pretty common.

Additionally, the JavaScript Binary AST is designed in such a manner that evolutions of the JavaScript language should not break existing parsers. I will post more about this in a future entry, so please bear with me until I have time to write it down.

> - WebAssembly not supported by tools

> Neither is binary AST. Meanwhile one of the goals of WebAssembly is tool support, readability etc.

I'm pretty sure I never said that.

> So. What are you going to do with JS AST when WebAssembly gets support for JS?

If/when that day arrives, I'll compare both approaches.

Well the complete circle has a major benefit, flexibility:

You develop one app, and it can run as both web and desktop application, or even on mobile with some extra efforts.

Say you want to quickly edit something like a document, you don't need to install Word, just open browser and load Google Docs or Office 365.

And if you find yourself constantly using one web app or website (travis CI, Trello), you can wrap it with nativefier [1] and use it as a desktop app.

[1] https://github.com/jiahaog/nativefier