3 ms·

Well, if you look at the design goals of WebAssembly [1], you'll see very different high-level goals. Sure, there is some intersection, but not nearly as much a

by Yoric 9y ago

Well, if you look at the design goals of WebAssembly [1], you'll see very different high-level goals. Sure, there is some intersection, but not nearly as much as you seem to believe. Now, there are very good reasons to not ship bytecode (e.g. because once you standardize the bytecode on which your VM runs, you're dead in the water and your VM stops evolving). The binary AST was carefully designed to avoid this issue. Indeed, as written in the proposal, there is no guarantee that sending bytecode would be any faster to transmit/parse/start. Moreover, experiments suggest that it wouldn't. On the other hand, if you have read the proposal, you have seen that experiments with binary AST suggest that it is faster to transmit/parse/start. As for committees, well, that's how the web works. It is certainly not perfect, but it beats single-vendor-decides-everything. [1] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...

dmitriid 9y ago
> Well, if you look at the design goals of WebAssembly [1], you'll see very different high-level goals. Sure, there is some intersection, but not nearly as much as you seem to believe. Yes. Because it's not tied into a single programming language > Now, there are very good reasons to not ship bytecode (e.g. because once you standardize the bytecode on which your VM runs, you're dead in the water and your VM stops evolving). The binary AST was carefully designed to avoid this issue. Oh. Right. Because binary AST is not something that will be standardized on, and once you're set on a particular version of the AST, you're not dead in the water? Oh. Wait. Let me quote the proposal: --- quote --- The grammar provides the set of all possible node kinds and their ordered properties, which we expect to be monotonically growing. However, not all vendors will support all nodes at any given time. ... parsing a correctly formatted file fails if a parser encounters a feature that the engine does not implement --- end quote --- Same problems > Indeed, as written in the proposal, there is no guarantee that sending bytecode would be any faster to transmit/parse/start. Moreover, experiments suggest that it wouldn't. Let me quote the WebAssemply READMEs --- quote --- Wasm bytecode is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms. The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience. --- end quote ---
- 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

by Yoric 9y ago

dmitriid 9y ago

> Well, if you look at the design goals of WebAssembly [1], you'll see very different high-level goals. Sure, there is some intersection, but not nearly as much as you seem to believe. Yes. Because it's not tied into a single programming language > Now, there are very good reasons to not ship bytecode (e.g. because once you standardize the bytecode on which your VM runs, you're dead in the water and your VM stops evolving). The binary AST was carefully designed to avoid this issue. Oh. Right. Because binary AST is not something that will be standardized on, and once you're set on a particular version of the AST, you're not dead in the water? Oh. Wait. Let me quote the proposal: --- quote --- The grammar provides the set of all possible node kinds and their ordered properties, which we expect to be monotonically growing. However, not all vendors will support all nodes at any given time. ... parsing a correctly formatted file fails if a parser encounters a feature that the engine does not implement --- end quote --- Same problems > Indeed, as written in the proposal, there is no guarantee that sending bytecode would be any faster to transmit/parse/start. Moreover, experiments suggest that it wouldn't. Let me quote the WebAssemply READMEs --- quote --- Wasm bytecode is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms. The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience. --- end quote ---

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