91–100 of 211 posts
Lua has something very similar(bytecode vs AST) via luac for a long while now. We've used to to speed up parse times in the past and it helps a ton in that area.
I'm interested. Do you have a link?
Earlier quoted context omitted.
I think everything will eventually settle in the middle where Java and C# currently live. They have an "intermediate code" that they somewhat compile down to. But this is really a more compact version of the source than a binary though. You can see this easily by running a decompiler. Often times the decompiled IL is almost identical to the source. And before the JIT kicks in the IL is typically interpreted. You get…
On .NET's case the IL is never interpreted, it is only a portable executable format. It is either AOT compiled to native code via NGEN, Mono AOT, MDIL or .NET Native. Or JITed on file load before actually executing the code. The only .NET toolchain, from Microsoft, that actually does interpret IL it is .NET Micro Framework. The idea of using bytecodes as portable execution formats goes back to mainframes, of which IB…
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 in…
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 f…
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.
Earlier quoted context omitted.
On our sample, x0.95 for minified code (so that's a 5% improvement) and ~x0.3 for non-minified code. As usual, read these numbers with a pinch of salt, they are bound to change many times before we are done.
Does BinJS perform AST transforms like `!0` to `true` which would be shorter in binary AST encoding? Or does it faithfully model the original code?
For those curious about how this would deal with Function.prototype.toSource, via https://github.com/syg/ecmascript-binary-ast#functionprototy... : > This method would return something like "[sourceless code]".
Earlier quoted context omitted.
Does BinJS perform AST transforms like `!0` to `true` which would be shorter in binary AST encoding? Or does it faithfully model the original code?
It faithfully models the original code. The idea is that if you want to transform `!0` to `true`, or if you want to obfuscate, etc. you can always plug an additional tool.
The BinJS prototype will be written in pure javascript I assume to speed its adoption?
It's of course not compilation (though parsing is the first thing a compiler would do, too). It's not generation of machine code, or VM bytecode. it's mere compression.
This is great news because you got to see the source if you want, likely nicely formatted. You can also get rid of the minifiers, and thus likely see reasonable variable names in the debugger.
Earlier quoted context omitted.
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 f…
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 lon…
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.
Earlier quoted context omitted.
Firefox had a much higher market share than Chrome back then. Context matters.
Mozilla and others had pretty strong technical objections to Native Client. Context matters (sometimes :))
Earlier quoted context omitted.
Part of this is fad driven, but part of this is also driven by other human concerns. For example, had the early web been binary (like we're pushing for now) instead of plain text it would have died in its crib. Executing binary code sent blindly from a remote server without a sandbox is a security nightmare. Now that we have robust sandboxes, remote binary execution becomes a viable option again. But, it took a decad…
But there has been Java Applets, Active X, Flash, and Silverlight.
[1]: Except maybe Silverlight. From what I remember, it didn't see enough success to be a tempting target for hackers.