4 ms·
Mmmhhh... I believe that I am starting to understand your point. If I understand correctly, you regret that WebAssembly does not offer a set of opcodes that wou
by Yoric 9y ago
Mmmhhh... I believe that I am starting to understand your point. If I understand correctly, you regret that WebAssembly does not offer a set of opcodes that would let it trivially (or at least simply) compile JavaScript, right?
If so, let's reset the discussion, because we were actually talking past each other.
Yes, such opcodes might essentially solve the issues that the binary AST is attempting to solve, albeit probably at the cost of losing the source code of JavaScript.
I have not been part of the debates on Wasm, but I believe that I can extrapolate some of the reasons why this wasn't done:
1. Coming up with a decent target for statically compiled languages whose compilation is basically well-known is much easier than coming up (and maintaining) a decent target for a dynamic compiled language whose specifications are amended roughly once per year.
2. Each browser vendor has its own JS-specific bytecode format. Transpiling a neutral bytecode to a vendor-specific bytecode isn't particularly easy.
3. If a vendor decides to expose their own bytecode format and let third-parties ship to this format, they suddenly get a low-level compatibility burden that will be extremely damaging to their own work on the JS VM.
4. If the JS opcodes are high-level, suddenly, Ecma needs to maintain two different specifications for the semantics of the same language: specifications by interpretation and specifications by compilation. On the other hand, if the JS opcodes are low-level, there is a pretty large burden for developers on maintaining a JS-to-bytecode compiler and making sure that it has the exact same semantics as JavaScript. In the latter case, there is also a pretty good chance (and some early experiments) that the compiled files will be much larger and much slower to parse.
In comparison with these issues, coming up with a simple Binary AST format is rather simple, hence has much higher chances of achieving success and consensus. Additionally, we have encouraging numbers that indicate that Binary AST can speed up things a lot. Finally, the Binary AST has several interesting side-benefits, including the fact that it maintains source code readability.
- dmitriid 9y ago> Mmmhhh... I believe that I am starting to understand your point. If I understand correctly, you regret that WebAssembly does not offer a set of opcodes that would let it trivially (or at least simply) compile JavaScript, right? Yes. Because SURPRISE it's called webassembly > Each browser vendor has its own JS-specific bytecode format. Transpiling a neutral bytecode to a vendor-specific bytecode isn't particularly easy. Newsflash: webassembly is: 1. based on asm.js 2. supported (eventually) by all browser vendors 3. is specifically targeting the web 4. is already shown to be a significant improvement (see, for example, https://blog.figma.com/webassembly-cut-figmas-load-time-by-3x-76f3f2395164 https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...) > If a vendor decides to expose their own bytecode format Why would the want to expose their own bytecode format? The entire point of webassembly was to be a crossplatform format > If the JS opcodes are high-level, suddenly, Ecma needs to maintain two different specifications for the semantics of the same language: specifications by interpretation and specifications by compilation. Why? No one maintains two different specifications for C++ just because it compiles to JavaScript (via EcmaScripten) and to WebAssembly. Meanwhile, with binary AST, Ecma will indeed need to maintain two different specifications > In comparison with these issues, coming up with a simple Binary AST format is rather simple, hence has much higher chances of achieving success and consensus. Issues that you pulled out of nowhere, frankly > Additionally, we have encouraging numbers that indicate that Binary AST can speed up things a lot. We have encouraging numbers that WebAssembly speeds up things a lot. Yet, you insist "oh, we don't know, it might, or it might not". > Finally, the Binary AST has several interesting side-benefits, including the fact that it maintains source code readability. Quoting WebAssembly FAQs: --- quote --- WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. The textual format will be used when viewing the source of wasm modules on the web. --- end quote --- I strongly suggest you 1. read up on WebAssembly 2. Possibly apply efforts to bring JavaScript to WebAssembly
- Yoric 9y agoI'm afraid that we are on vastly different wavelengths. If you feel that you can improve WebAssembly, then by all means, please do so. I am convinced that I can do good by making Binary AST a reality, so I will focus my energy on that. Thanks for the conversation.
- dmitriid 9y agoSo, basically, all your "arguments" for binary AST resolve to: - binary AST will not have versioning problems unlike WASM (this is false) - binary AST is better than ASM, because as soon as you standardize on bytecode, "your VM will not evolve" (this is false) - binary AST can be used to view/debug source code, while WASM can't (this is false) - binary AST is faster to load and parse than WASM (neither false nor true, because there are no comparisons or experiments) - supporting WASm means supporting two versions of ECMA standard unlike binary AST (which is false) and so on and so on However, Javascript is already a dumpster fire, so this effort will neither improve nor worsen the situation