6 ms·

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 si

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

Yoric 9y ago
Let me add a second emphasis on "might" and "some cases".
syg 9y ago
This is important, as there seems to be a lot of misunderstanding in this thread. What's proposed is structural compression of JS with JS-specific bits to speed things up even more. What's proposed is not compiled JS, in that the original JS is not meaningfully transformed at all. There is a very explicit design goal to retain the original syntactic structure. OTOH WebAssembly is like a new low-level ISA accessible from web browsers. To use wasm, one does have to compile to it. As the parent here says, compiling JS -> wasm currently requires at least a GC but also much more. To engineer a performant VM and runtime for a dynamic programming language like JS is a time-consuming thing. It is curious to see so many folks think that JS can straightforwardly be compiled to wasm. Currently wasm and JS serve very different needs; and I also don't think JS will be going anywhere for many, many years. Edit: formatting
- sjrd 9y ago
  This is a very good point. I would also add that there are a lot of languages compiling to JavaScript that would similarly not benefit from wasm. Right now, pretty much all GC-ed languages compiling to JS (such as ClosureScript, Elm, Scala.js, BuckleScript, PureScript, etc.) are in that category. Even if/when wasm supports GC in the future, I expect that dynamically typed languages compiling to JS will still be a long way from benefiting from wasm. However, all these languages can benefit from the Binary AST right away. Just like any codebase directly written in JavaScript. If the Binary AST has some decent story about position mapping (see [1] which I just filed), they might even get somewhat better tooling/debugging support going through the Binary AST than going through .js source files, out of the box. [1] https://github.com/syg/ecmascript-binary-ast/issues/17 https://github.com/syg/ecmascript-binary-ast/issues/17
  - Yoric 9y ago
    For context: position mapping is somewhere on our radar, but we haven't reached a stage at which it would make sense to start working on it yet. If you have ideas and/or spare cycles, of course, they are welcome :) As a side-note: I believe that we could build upon the (very early) proposed mechanism for comments to also store positions. Size-optimized BinAST files would drop both comments and positions, while debugging-optimized BinAST files would keep both at the end of the file so as to not slow down parsing until they are needed.
    - sjrd 9y ago
      That seems awesome. I'm glad that it's on your radar. If you can point me to the best place to suggest ideas or spend my spare cycles, I would gladly do so. At the very least, I can comment on how we serialize positions in the (tree-based) Scala.js IR, which is size-optimized.
      - Yoric 9y ago
        The tracker on which you're posting is a good place, thanks a lot :)
        lomnakkus 9y ago
        Off-topic: I'm sorry to go a little squishy, but I thought I should say that I appreciate the work both of you do very much... though sjrd's work is a little bit more "direct-impact-for-me" at the moment, I must admit. :p Of course, as you just both said, your work is kind of complementary... which is always nice. :) Anyway, thanks for the long-term thinking to the both of you.
        Yoric 9y ago
        thanks :)
  - human-factor 9y ago
    A lot of the languages you mentioned have different enough memory allocation characteristics than JavaScript due to immutability and functional style that they would probably benefit from having a garbage collector tuned to their purposes in webassembly. There's a reason we don't have one common garbage collector for all the managed languages. I do recognize that this is a side point, but I think it's worth mentioning.
dmitriid 9y ago
Keywords: currently doesn't have GC, currently is for other languages. Because, surprise, it's an MVP, and wok has already started to bring other languages (including JavaScript) to it. So. The question is: one-two years from now, when there's support for wasm in javascript, where does it leave binary AST?
- cheapsteak 9y ago
  > one-two years from now, when there's support for wasm in javascript How likely is this to happen in the next 2 years? I thought it'd be a lot more difficult.
  - dmitriid 9y ago
    Probably unlikely. Watch binary AST blaze through whatever passes for "process" at TC39 though.
    - syg 9y ago
      Please do not disparage an entire committee because you disagree philosophically with one proposal in it.
      - dmitriid 9y ago
        I don't disagree with just one proposal. I disagree with multiple proposals and the committee's approach to the "process".
  - Yoric 9y ago
    I don't know of anyone working on it, exactly because it is so difficult. So, while it might happen eventually, I don't think that anyone can provide an ETA at this stage.
pier25 9y ago
But couldn't other languages also compile to this binary AST too?
- Akkuma 9y ago
  Sure, why not? The difference is that WASM is aiming for near native performance of code, while the binary JS would still be limited to JS performance.
  - pier25 9y ago
    Yes, but it would have access to DOM, GC, etc.
    - Akkuma 9y ago
      But that's what languages that compile to JavaScript support already today. The binary JS shouldn't prevent this behaviour if it is just a binary representation of a text version.
- nfriedly 9y ago
  Yes, and for anything that already compiles to JS, adding this as an additional target shouldn't be too much work. However, for anything that doesn't already compile to JS, this is essentially the same amount of work as targeting regular JavaScript. In that case, the work might be better spent making it compile to WASM. But, that's not a hard and fast rule, it really depends on the situation. And, of course, it could always target both.
stcredzero 9y ago
It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. The author of Smalltalk/X proposed this for Smalltalk at one of the Camp Smalltalk meetups about 17 years ago. Doing this for Javascript would also facilitate the running of other languages which use Javascript as a compiler target, providing 1st class debugging support for other languages as a side effect.
- Yoric 9y ago
  Do you have a link? I'd be interested in reading how they proposed to do so.
  - stcredzero 9y ago
    No link. We were all stuffed into a La Quinta Inn in San Diego, running ethernet between the balconies. There was just a bunch of us crowded into a motel room, and he just started talking about it.
bgirard 9y ago
Thank you for clarifying. Plain text source code is just not a good way to ship code. Browsers have a warm shared copy of a highly tuned VM. However to make use of it sites have to talk to it via plain text source code heavily penalizing startup. A JS binary AST has the potential to transparently benefits all websites without any effort on their part if it's handled by a web server module, like GZIP, or a build step. This can remove redundant work that's done for billions of page load for all web sites.

Yoric 9y ago

Let me add a second emphasis on "might" and "some cases".

syg 9y ago

This is important, as there seems to be a lot of misunderstanding in this thread. What's proposed is structural compression of JS with JS-specific bits to speed things up even more. What's proposed is not compiled JS, in that the original JS is not meaningfully transformed at all. There is a very explicit design goal to retain the original syntactic structure. OTOH WebAssembly is like a new low-level ISA accessible from web browsers. To use wasm, one does have to compile to it. As the parent here says, compiling JS -> wasm currently requires at least a GC but also much more. To engineer a performant VM and runtime for a dynamic programming language like JS is a time-consuming thing. It is curious to see so many folks think that JS can straightforwardly be compiled to wasm. Currently wasm and JS serve very different needs; and I also don't think JS will be going anywhere for many, many years. Edit: formatting

sjrd 9y ago
This is a very good point. I would also add that there are a lot of languages compiling to JavaScript that would similarly not benefit from wasm. Right now, pretty much all GC-ed languages compiling to JS (such as ClosureScript, Elm, Scala.js, BuckleScript, PureScript, etc.) are in that category. Even if/when wasm supports GC in the future, I expect that dynamically typed languages compiling to JS will still be a long way from benefiting from wasm. However, all these languages can benefit from the Binary AST right away. Just like any codebase directly written in JavaScript. If the Binary AST has some decent story about position mapping (see [1] which I just filed), they might even get somewhat better tooling/debugging support going through the Binary AST than going through .js source files, out of the box. [1] https://github.com/syg/ecmascript-binary-ast/issues/17 https://github.com/syg/ecmascript-binary-ast/issues/17
- Yoric 9y ago
  For context: position mapping is somewhere on our radar, but we haven't reached a stage at which it would make sense to start working on it yet. If you have ideas and/or spare cycles, of course, they are welcome :) As a side-note: I believe that we could build upon the (very early) proposed mechanism for comments to also store positions. Size-optimized BinAST files would drop both comments and positions, while debugging-optimized BinAST files would keep both at the end of the file so as to not slow down parsing until they are needed.
  - sjrd 9y ago
    That seems awesome. I'm glad that it's on your radar. If you can point me to the best place to suggest ideas or spend my spare cycles, I would gladly do so. At the very least, I can comment on how we serialize positions in the (tree-based) Scala.js IR, which is size-optimized.
    - Yoric 9y ago
      The tracker on which you're posting is a good place, thanks a lot :)
      - lomnakkus 9y ago
        Off-topic: I'm sorry to go a little squishy, but I thought I should say that I appreciate the work both of you do very much... though sjrd's work is a little bit more "direct-impact-for-me" at the moment, I must admit. :p Of course, as you just both said, your work is kind of complementary... which is always nice. :) Anyway, thanks for the long-term thinking to the both of you.
        Yoric 9y ago
        thanks :)
- human-factor 9y ago
  A lot of the languages you mentioned have different enough memory allocation characteristics than JavaScript due to immutability and functional style that they would probably benefit from having a garbage collector tuned to their purposes in webassembly. There's a reason we don't have one common garbage collector for all the managed languages. I do recognize that this is a side point, but I think it's worth mentioning.

dmitriid 9y ago

Keywords: currently doesn't have GC, currently is for other languages. Because, surprise, it's an MVP, and wok has already started to bring other languages (including JavaScript) to it. So. The question is: one-two years from now, when there's support for wasm in javascript, where does it leave binary AST?

cheapsteak 9y ago
> one-two years from now, when there's support for wasm in javascript How likely is this to happen in the next 2 years? I thought it'd be a lot more difficult.
- dmitriid 9y ago
  Probably unlikely. Watch binary AST blaze through whatever passes for "process" at TC39 though.
  - syg 9y ago
    Please do not disparage an entire committee because you disagree philosophically with one proposal in it.
    - dmitriid 9y ago
      I don't disagree with just one proposal. I disagree with multiple proposals and the committee's approach to the "process".
- Yoric 9y ago
  I don't know of anyone working on it, exactly because it is so difficult. So, while it might happen eventually, I don't think that anyone can provide an ETA at this stage.

pier25 9y ago

But couldn't other languages also compile to this binary AST too?

Akkuma 9y ago
Sure, why not? The difference is that WASM is aiming for near native performance of code, while the binary JS would still be limited to JS performance.
- pier25 9y ago
  Yes, but it would have access to DOM, GC, etc.
  - Akkuma 9y ago
    But that's what languages that compile to JavaScript support already today. The binary JS shouldn't prevent this behaviour if it is just a binary representation of a text version.
nfriedly 9y ago
Yes, and for anything that already compiles to JS, adding this as an additional target shouldn't be too much work. However, for anything that doesn't already compile to JS, this is essentially the same amount of work as targeting regular JavaScript. In that case, the work might be better spent making it compile to WASM. But, that's not a hard and fast rule, it really depends on the situation. And, of course, it could always target both.

stcredzero 9y ago

It's a fairly simple optimization - it's still JavaScript, just compressed and somewhat pre-parsed. The author of Smalltalk/X proposed this for Smalltalk at one of the Camp Smalltalk meetups about 17 years ago. Doing this for Javascript would also facilitate the running of other languages which use Javascript as a compiler target, providing 1st class debugging support for other languages as a side effect.

Yoric 9y ago
Do you have a link? I'd be interested in reading how they proposed to do so.
- stcredzero 9y ago
  No link. We were all stuffed into a La Quinta Inn in San Diego, running ethernet between the balconies. There was just a bunch of us crowded into a motel room, and he just started talking about it.

bgirard 9y ago

Thank you for clarifying. Plain text source code is just not a good way to ship code. Browsers have a warm shared copy of a highly tuned VM. However to make use of it sites have to talk to it via plain text source code heavily penalizing startup. A JS binary AST has the potential to transparently benefits all websites without any effort on their part if it's handled by a web server module, like GZIP, or a build step. This can remove redundant work that's done for billions of page load for all web sites.