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.