Towards a JavaScript Binary AST

https://yoric.github.io/post/binary-ast-newsletter-1/

by Yoric • 9 years ago

310 198 9 years ago

yoric.github.io

bigato• 9 years ago

Trying to catch up with webassembly, huh?

ryanong2• 9 years ago

This is some amazing progress, but reading this and hearing how difficult JavaScript is as a language to design around makes me wonder how many hours have we spent optimizing a language designed in 2 weeks and living with those consequences. I wish we could version our JavaScript within a tag somehow so we could slowly deprecate code. I guess that would mean though browsers would have to support two languages that would suck..... this really is unfortunately the path of least resistance.

(I understand I could use elm, cjs, emscriptem or any other transpirer but I was thinking of ours spent around improving the js vm.

exikyut• 9 years ago

I wish we could version our JavaScript within a tag somehow

Behold one of the implementational details that emerged out of this language that was indeed "designed in 2 weeks":

  <script type="text/javascript1.0">...</script>

  <script type="text/javascript1.1">...</script>

  <script type="text/javascript1.2">...</script>

  <script type="text/javascript1.3">...</script>

  <script type="text/javascript1.4">...</script>

  <script type="text/javascript1.5">...</script>

https://tools.ietf.org/html/rfc4329:

  3.  Deployed Scripting Media Types and Compatibility

    Various unregistered media types have been used in an ad-hoc fashion
    to label and exchange programs written in ECMAScript and JavaScript.
    These include:

      +-----------------------------------------------------+
      | text/javascript          | text/ecmascript          |
      | text/javascript1.0       | text/javascript1.1       |
      | text/javascript1.2       | text/javascript1.3       |
      | text/javascript1.4       | text/javascript1.5       |
      | text/jscript             | text/livescript          |
      | text/x-javascript        | text/x-ecmascript        |
      | application/x-javascript | application/x-ecmascript |
      | application/javascript   | application/ecmascript   |
      +-----------------------------------------------------+

https://www.quirksmode.org/js/intro.html (from circa 2007, when it was trendy to NOT date webpages shakes fist):

JavaScript versions
There have been several formal versions of JavaScript.
1.0: Netscape 2
1.1: Netscape 3 and Explorer 3 (the latter has bad JavaScript support, regardless of its version)
1.2: Early Version 4 browsers
1.3: Later Version 4 browsers and Version 5 browsers
1.4: Not used in browsers, only on Netscape servers
1.5: Current version.
2.0: Currently under development by Brendan Eich and others.

The link above points to a bit of interesting general discussion about versioning, and isn't as dense as the RFC.

ryanong2• 9 years ago

Yea I remember that versioning but few browsers implemented it.

bryanlarsen2• 9 years ago

Another mechanism created to do something similar to versioning was strict mode.

goatlover5• 9 years ago

Brendan Eich was on a podcast in 2016 talking about the origins and evolution of JS. At one point he and the ECMA team wanted to make == strict equality, but then that would have required specifying the JS version, and Microsoft didn't like that, so they decided to go with === and leave == non-strict.

It's one of several cases where backward compatibility on the web trumped cleaning up the language.

cabaalis2• 9 years ago

So, compiled Javascript then? "We meet again, at last. The circle is now complete."

The more I see interpreted languages being compiled for speed purposes, and compiled languages being interpreted for ease-of-use purposes, desktop applications becoming subscription web applications (remember mainframe programs? ), and then web applications becoming desktop applications (electron) the more I realize that computing is closer to clothing fads than anything else. Can't wait to pickup some bellbottoms at my local target.

Yoric37• 9 years ago

Well, it's more "compressed JavaScript" than "compiled JavaScript".

dmitriid7• 9 years ago

It's not. It's a binary representation of JS. Basically directly competing with WebAssembly.

What happens a year from now when WebAssembl gets support for GC and modules?

cabaalis2• 9 years ago

Something we badly need, I greatly appreciate the effort!

MadcapJake3• 9 years ago

How can you say it's "compressed" over "compiled" when you are actually parsing it into an AST and then (iiuc) converting that to binary? That's exactly what compilers do. You are in fact going to a new source format (whatever syntax/semantics your binary AST is encoded with) so you really are compiling.

To be fair, these two concepts are similar and I may be totally misunderstanding what this project is about. In the spirit of fairness, let me test my understanding. You are saying wasm bytecode is one step too early and a true "machine code" format would be better able to improve performance (especially startup time). I'm not following wasm development, but from comments here I am gathering that wasm is too level and you want something that works on V8. Is that what this project is about?

On a side note, it's truly a testament to human nature that the minute we get close to standardizing on something (wasm), someone's gotta step up with another approach.

JulienSchmidt• 9 years ago

parsed (+compressed), not compiled.

Parsing is unavoidable, regardless if the code is interpreted or compiled. This proposal seems to further compress the AST somehow.

Basically the idea is to already preprocess the text source, so that the client can skip two steps on execution: lexical analysis and the parsing of the text source resulting in the AST. The post explains why the authors believe that this is a good idea.

jnty• 9 years ago

You seem to assume that there is One True Way of doing things and we're just circling round trying to find it. In fact, as you point out, there are benefits and tradeoffs to every approach. People compile interpreted languages to make them run faster, but are using them in the first place because they're easier to use. People who have come to compiled languages for speed are now naturally looking to make them easier to develop with as well.

Compiled C is not going to go away any sooner than interpreted Javascript - but a widening of the options available is great as it allows us to focus on developing things quickly and correctly, rather than making decisions based on which particular annoyance you're happy to put up with.

msla• 9 years ago

People try to move CS both towards and away from engineering: We want the dependability engineering seems to provide in, say, Civil Engineering, but we don't want to acknowledge that engineering is about trade-offs, which are compromises, and that the nature of those trade-offs changes as the world surrounding a specific tool or program changes.

Maybe they think there is a One True Way. Maybe they think every building needs to be reinforced concrete and structural steel, now and forever, in every possible context.

pjmlp5• 9 years ago

The JIT/AOT approach was already there in Xerox PARC systems in the 70's, oh well.

goatlover5• 9 years ago

Imagine if Xerox Parc happened in the early 90s and we ended up with a Smalltalk web browser environment.

slackingoff20172• 9 years ago

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 the best of both worlds. Easy to compile, easy to decompile, platform agnostic, compact code, and fast if it needs to be

goatlover5• 9 years ago

It's not optimal for things like embedded, device drivers, high performance computing, etc. So I doubt everything will settle there. There will always be situations where C/Rust/Fortran are better choices.

lj37• 9 years ago

The Design of Everyday Things is instructive here. You don't design for the middle or the average. You design for the extreme edges. If you have a programming language that can be used both by absolute beginners who just want to learn enough programming to script their excel spreadsheet AND HFT traders who need to ring out every cycle of performance they can on every core they have at their disposal, then the middle will take care of itself.

pjmlp5• 9 years ago

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 IBM AS/400's TIMI is the best known example.

le-mark2• 9 years ago

Software development is fad driven, I think a lot or most people would agree with this. I myself find this to be lamentable. But over the years I've asked myself, why is this the case? I mean it has been faddish for years, this isn't new in the current era.

I think there are two main drivers for fad-ism in software. One is we as developers, are required to chase the popular languages and frameworks to stay current, marketable, and employable. So there is always a sense of "what do I have to learn next, so I can switch jobs succesfully when I need to". Another driver is, developers seek to gain experience by re-doing things from the past. Example, creating new languages, or compiler for an existing language, provides inexperience developers with fantastic new experiences and knowledge. This is desirable.

So yeah, we got fads, and us old timers, or not so old timers with a historical perspective, watch our lawns, but everyone has to learn somehow. Ideally a lot of this would come from an apprenticeship/journeyman system, or a University degree of some sort. But for now it's all we have.

rpeden3• 9 years ago

To me, software development seems as tribal as politics. People tend to like and agree with those in their own tribe, and tend to see criticism of their tribe's preferred ideology as an attack on their identity.

There's a lot of pressure to be part of a popular tribe, and so you see situations where even a mild criticism of, for example, the a piece of the JavaScript tribe's technology (like, say, npm or Webpack) tends to elicit vitriolic responses and counter arguments.

You can sometimes get away with this kind of criticism if you choose your words carefully and make it very clear (or at least pretend to) that you're actually a member of the tribe you're criticizing, and that your criticism is meant to be constructive. So you say something like 'I use npm, and I like it, but here's where I struggle with it and here's how I'd improve it'. But if you just write about why you dislike it, you're likely to be flamed and criticized, even if everything you wrote verifiably correct.

So I find that watching programmers argue in blogs and on HN and Reddit feels a lot like reading political arguments on Reddit, or Facebook. And maybe that's why programming tends to be faddish. Each tribe is mostly only aware of its own history; there's no real shared sense of culture, or much awareness of the rich shared history that got us to where we are today. And so you see lots of wheel reinvention, as people poorly re-solve problems that were already solved long ago by other programming tribes.

These are just my personal observations, though. I could very well be completely wrong. :)

lj37• 9 years ago

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 decade's worth of JVM R&D to get to this point.

romaniv3• 9 years ago

There is a serious problem when every new generations of a technology fixates on some problem of its choice and ignores all the others. The issue of binary blobs didn't go away. What changed is that a lot of developers today don't care about the open nature of the web and are perfectly fine with sacrificing it for faster load times of their JS-saturated websites.

I think a much better approach to this pronblem would be a compression format that's designed specifically for JavaScript. It could still be negotiable, like GZIP, so anyone wanting to see the source would be able to see it. It could also be designed in a way that allows direct parsing without (full?) decompression.

goatlover5• 9 years ago

But there has been Java Applets, Active X, Flash, and Silverlight.

mintplant• 9 years ago

This isn't driven by a "fad", rather by the simple fact that any trace of JS engine performance will show a sizable chunk at the beginning dedicated to just parsing scripts. Heck, we even have "lazy parsing", where we put off doing as much parsing work as possible until a piece of code is needed. Replacing that with a quick binary deserialization pass is a straightforward win.

I wouldn't call this "compiled JavaScript". In broad strokes what's happening is you take the result of parsing JavaScript source to an AST and serialize that; then next time you deserialize the AST and can skip the parsing stage.

(Source: I spent a summer working on JS engine and JIT performance at Mozilla.)

chriswarbo• 9 years ago

I don't think the point was that this project is a fad.

Instead, I think the point was that Javascript is a fad (we'll see whether this is true by watching how popular compile-to-WASM languages become compared to JS, once WASM becomes widespread and stable).

Alternatively, we might say that JS was created (in 10 days, yadda yadda) at a time when the fads were dynamic typing over static typing; interpreters over compilers; GC over manual or static memory management; OOP over, say, module systems; imperative over logic/relational/rewriting/etc.; and so on. JS's role as the Web language has tied developers' hands w.r.t. these tradeoffs for 20 years; long enough that a significant chunk of the developer population hasn't experienced anything else, and may not really be aware of some of these tradeoffs; some devs may have more varied experience, but have developed Stockholm Syndrome to combat their nostalgia ;)

As an example, one of the benefits of an interpreter is that it can run human-readable code; this is a sensible choice for JS since it fits nicely with the "View Source" nature of the Web, but it comes at a cost of code size and startup latency. The invention of JS obfuscation and minifiers shows us that many devs would prefer to pick a different balance between readability and code size than Eich made in the 90s. This project brings the same option w.r.t. startup latency. WASM opens up a whole lot more of these tradeoffs to developers.

aidos• 9 years ago

Haha, I did enjoy this comment. It's kinda fair, but also kinda not.

At each step developers are trying to create the best thing they can with the tools at their disposal. There will always be a tradeoff between flexibility and ease of use. There's a reason Electron exists — the browser has limitations that are easier to work around in Electron. There's a reason we moved to putting stuff online, we could write it once and distribute it everywhere.

majewsky2• 9 years ago

At each step developers are trying to create the best thing they can with the tools at their disposal.

Well, yeah. The point is that we don't have a consistent definition of "best" that's constant over time. Only by changing your direction all the time can you end up walking in circles.

rpeden3• 9 years ago

You're not the only one to observe that computing tends to be fad-driven. I enjoy Alan Kay's take on it:

In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were.

So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.

...

I don’t spend time complaining about this stuff, because what happened in the last 20 years is quite normal, even though it was unfortunate. Once you have something that grows faster than education grows, you’re always going to get a pop culture.

...

But pop culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

sources:

http://queue.acm.org/detail.cfm?id=1039523

http://www.drdobbs.com/architecture-and-design/interview-wit...

romaniv3• 9 years ago

I wish I've heard/seen some of the Alan Kay talks/articles earlier in my career. The more I work in IT, the more I see the wisdom in how he sees the industry. (And I don't just mean these pop culture comments.)

paradite• 9 years ago

Well the complete circle has a major benefit, flexibility:

You develop one app, and it can run as both web and desktop application, or even on mobile with some extra efforts.

Say you want to quickly edit something like a document, you don't need to install Word, just open browser and load Google Docs or Office 365.

And if you find yourself constantly using one web app or website (travis CI, Trello), you can wrap it with nativefier [1] and use it as a desktop app.

[1] https://github.com/jiahaog/nativefier

rattray• 9 years ago

Fads, or steadfast pursuit of balancing tradeoffs and finding clever ways to improve tools?

Compilation and interpretation both have distinct advantages. It's hard to do both (read: it took a while) and each has tradeoffs.

I'm impressed and grateful that I can get compile time errors for interpreted languages, and I'd feel the same about being able to use a compiled lang in a repl.

Regarding the actual topic at hand, this isn't compiled JavaScript, just parsed JavaScript. They're shipping an AST, not bytecode/machine code.

FrancoisBosun• 9 years ago

I feel like this may become some kind of reimplementation of Java's byte code. We already have a "write once, run anywhere" system. Good luck!

Yoric37• 9 years ago

Not really. The reimplementation of something like Java's bytecode is Wasm. This one is more of a compression format than a bytecode.

jlebrech3• 9 years ago

with an AST you can visualise code in ways other than text, and also reformat code like in go-fmt.

Yoric37• 9 years ago

Indeed. That's not one of the main goals of the project, but I hope that standardizing the AST will help a lot with JS tooling, including code visualisation.

jlebrech3• 9 years ago

I want to see a code editor that represent common programming language concepts such as classes, functions (OO) in a graphical way and displays the rest in text.

onion2k• 9 years ago

This is a really interesting project from a browser technology point of view. It makes me wonder how much code you'd need to be deploying to for this to be useful in a production environment. Admittedly I don't make particularly big applications but I've yet to see parsing the JS code as a problem, even when there's 20MB of libraries included.

Yoric37• 9 years ago

We're working towards experimenting this. For the moment, benchmarks suggest that this will be noticeable after 1 or 2Mb of code.

We'll only know for sure once we can start testing in real conditions, though.

Yoric37• 9 years ago

I should have mentioned "1 or 2Mb of code on an average-ish computer".

nfriedly4• 9 years ago

On a decently fast computer, you're right. On a low-end cell phone, 20MB of libraries will take a noticeable amount of time to parse.

kevinb7• 9 years ago

Does anyone know the actual spec for this binary AST can be found? In particular I'm curious about the format of each node type.

Yoric37• 9 years ago

The specifications are not nearly stable enough to be publicized yet. In particular, there are several possibilities for file layout, compression, etc. and we have barely started toying with some of them, so any kind of spec we publish at this stage would be deprecated within a few weeks.

If you wish to follow the development of the reference implementation, you can find it here: https://github.com/Yoric/binjs-ref/ . It's very early and the format will change often as we

1/ fix bugs;

2/ remove debugging info;

3/ start working seriously on compression;

4/ optimize.

le-mark2• 9 years ago

Here's some perspective for where this project is coming from:

So, a joint team from Mozilla and Facebook decided to get started working on a novel mechanism that we believe can dramatically improve the speed at which an application can start executing its JavaScript: the Binary AST.

I really like the organization of the present article, the author really answered all the questions I had, in an orderly manner. I'll use this format as a template for my own writing. Thanks!

Personally, I don't see the appeal for such a thing, and seems unlikely all browsers would implement it. It will be interesting to see how it works out.

lj37• 9 years ago

All they have to do is convince Google. Chrome's the king of the castle right now.

markdog123• 9 years ago

Native Client

majewsky2• 9 years ago

Personally, I don't see the appeal for such a thing, and seems unlikely all browsers would implement it.

Facebook can just run a feature detection JS snippet to see if your browser supports the Binary AST, and select the URLs of the other JS assets accordingly. If Binary AST is a thing, I can easily see web frameworks implementing such a format selection transparently.

And hey, if it contributes to people perceiving Firefox as faster than Chrome, I'm all for it. :)

alangpierce• 9 years ago

seems unlikely all browsers would implement it

It's going through TC39 (the committee that decides how the JavaScript language should evolve) and recently reached stage 1 (proposals advance from stage 0 to stage 4). I believe that if it reaches stage 4, then that means that all browser vendors have agreed to implement it, so it certainly seems to be their goal.

nikita2206• 9 years ago

In this thread: people not understanding the difference between byte code (representing code in the form of instructions) and AST.

apaprocki2• 9 years ago

From an alternate "not the web" viewpoint, I am interested in this because we have a desktop application that bootstraps a lot of JS for each view inside the application. There is a non-insignificant chunk of this time spent in parsing and the existing methods that engines expose (V8 in this case) for snapshotting / caching are not ideal. Given the initial reported gains, this could significantly ratchet down the parsing portion of perceived load time and provide a nice boost for such desktop apps. When presented at TC39, many wanted to see a bit more robust / scientific benchmarks to show that the gains were really there.

Yoric37• 9 years ago

Yep, working on it.

kannanvijayan3• 9 years ago

Yoric is working on a "proper" implementation and I'll be assisting in the design work, and if needs be some implementation. I think the next milestone here is a working demo in Firefox with Facebook page load.

At a personal level, I feel pretty confident that BinaryJS will help your case. The theory behind the gains was pretty solid before we designed the prototype. The prototype, for me, basically proved the theory.

My personal hope is that by the time we're done squeezing all we can out of this - which includes zero-costing lazy function parsing, and on-line bytecode generation, we can cut the "prepare for execution" time by 80%.

hashseed2• 9 years ago

Do you have any details on what could be improved wrt V8's snapshotting? We have recently extended the feature set a lot in order to be able to snapshot full Blink contexts, and there are some efforts on-going to implement that in Node.js as well. Soon crutches like electron-link won't be necessary anymore.

Some context:

https://v8project.blogspot.com/2017/05/energizing-atom-with-...

https://github.com/nodejs/node/issues/13877

nfriedly4• 9 years ago

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

Yoric37• 9 years ago

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

syg5• 9 years 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

sjrd5• 9 years 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

dmitriid7• 9 years 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• 9 years 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.

pier252• 9 years ago

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

Akkuma2• 9 years 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.

nfriedly4• 9 years 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.

stcredzero2• 9 years 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.

Yoric37• 9 years ago

Do you have a link? I'd be interested in reading how they proposed to do so.

bgirard• 9 years 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.

vvanders3• 9 years ago

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.

Yoric37• 9 years ago

I'm interested. Do you have a link?

vvanders3• 9 years ago

Yup, from the docs(there's also a little bit describing how it's interpreted in the "load()" main docs as well): https://www.lua.org/manual/5.1/luac.html

spc476• 9 years ago

There's a problem---you can break out of Lua with malformed bytecode [1] and the Lua team don't want to spend the time trying to validate Lua byte code [2]. That's why the latest Lua version has an option to ignore precompiled Lua scripts.

And sadly, I can see the same happening here.

[1] https://www.corsix.org/content/malicious-luajit-bytecode

[2] The overhead will eat any performance gained by using precompiled Lua code in the first place.

vvanders3• 9 years ago

Sure, if you're loading scripts from an untrusted source then don't use bytecode. They're pretty clear about that in the docs. However probably about 90% of Lua's use cases are embedded and so in that case it works just fine.

agumonkey• 9 years ago

hehe, reminds me of emacs byte-compilation..

Laaas• 9 years ago

Why does this guy use bits instead of bytes everywhere?

malts3• 9 years ago

Yoric - the Binary AST size comparisons in the blog - was the original javascript already minified?

Yoric37• 9 years ago

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.

malts3• 9 years ago

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?

mnarayan012• 9 years ago

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]".

_wmd• 9 years ago

It seems this would break a number of libraries (can't name one, but certain I've seen it), although per the article it would be a simple affair for the browser to reify the encoded AST into a compatible representation, especially if comments are also eventually preserved (per article its on the roadmap)

Yoric37• 9 years ago

It would be interesting to find any library that actually depends on that. There used to be some, but I haven't seen any in years.

If you do find one, please feel free to add a comment on the blog or one of the trackers :)

TazeTSchnitzel• 9 years ago

It's really exciting that this would mean smaller files that parse faster, but also more readable!

megamindbrian• 9 years ago

Can you work on webpack instead?

Yoric37• 9 years ago

I personally hope that webpack can eventually support this format. But we're not there yet.

nine_k• 9 years ago

This is what BASIC interpreters on 8-bit systems did from the very beginning. Some BASIC interpreters did not even allow you to type the keywords. Storing a trivially serialized binary form of the source code is a painfully obvious way to reduce RAM usage and improve execution speed. You can also trivially produce the human-readable source back.

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.

thanatropism• 9 years ago

Ha, great memories of the ZX Spectrum programming-keyword keyboard!

d--b• 9 years ago

I am puzzled by how an binary AST makes the code significantly smaller than a minified+gziped version.

A JavaScript expression such as:

var mystuff = blah + 45

Gets minified as var a=b+45

And then what is costly in there is the "var " and character overhead which you'd hope would be much reduced by compression.

The AST would replace the keywords by binary tokens, but then would still contain function names and so on.

I mean I appreciate the effort that shipping an AST will cut an awful lot of parsing, but I don't understand why it would make such a difference in size.

Can someone comment?

bryanlarsen2• 9 years ago

According to a comment by Yoric, they're seeing a 5% improvement in size over minified+gzip.

https://news.ycombinator.com/item?id=15046750

infogulch• 9 years ago

I would be more excited by the possible reduction in parse time since the grammar should be less ambiguous.

AriaMinaei• 9 years ago

Afaik, improving parse time is the big goal here. Parsing is a significant stage of the compile pipeline, perf-wise. Some engines (Chakara at least), defer part of the parsing of the body of a function until the function itself is called, just to save precious milliseconds and not block the first render.

kannanvijayan3• 9 years ago

It's actually hard to get smaller than compressed minified JS. Source code is actually a very excellent high-level, compact representation of program text.

The space optimizations in BinaryJS are to get us back down to the point where we are as good or better than minified compressed JS.

The main goal is to allow for much faster parse times, but to do that without compromising other things like compressed source size.

Existenceblinks• 9 years ago

These are random thought I just wrote on twitter in the morning(UTC+7):

"I kinda think that there were no front-end languages actually. It's kinda all about web platform & browsers can't do things out of the box."

"Graphic interface shouldn't execute program on its own rather than rendering string on _platform_ which won't bother more."

"This is partly why people delegate js rendering to server. At the end of the day all script should be just WebAssembly bytecodes sent down."

"Browser should act as physical rendering object like pure monitor screen. User shouldn't have to inspect photon or write photon generators."

"SPA or PWA is just that about network request reduction, and how much string wanted to send at a time & today http/2 can help that a lot."

"Project like Drab https://github.com/grych/drab 's been doing quite well to move computation back to "server" (opposite to self-service client)"

"WebAssembly compromise (to complement js) to implement the platform. JS api and WebAssembly should be merged or united."

"VirtualDom as if it is a right way should be built-in just like DOM get constructed from html _string_ from server. All JS works must die."

"That's how WebComponent went almost a half way of fulfilling web platform. It is unfortunate js has gone far, tools are actively building on"

"I'd end this now before some thought of individualism-ruining-the-platform take over. That's not gonna be something i'd like to write (now)"

-----

Not a complete version though. Kind of general speaking but I've been thinking in detail a bit. Then hours later I found this thread.

kyle-rb• 9 years ago

The linked article somehow avoids ever stating the meaning of the acronym, and I had to Google it myself, so I imagine some other people might not know: AST stands for "abstract syntax tree".

https://en.wikipedia.org/wiki/Abstract_syntax_tree

Yoric37• 9 years ago

Good point, I'll add this to the article.

tolmasky3• 9 years ago

One of my main concerns with this proposal, is the increasing complexity of what was once a very accessible web platform. You have this ever increasing tooling knowledge you need to develop, and with something like this it would certainly increase as "fast JS" would require you to know what a compiler is. Sure, a good counterpoint is that it may be incremental knowledge you can pick up, but I still think a no-work make everything faster solution would be better.

I believe there exists such a no-work alternative to the first-run problem, which I attempted to explain on Twitter, but its not really the greatest platform to do so, so I'll attempt to do so again here. Basically, given a script tag:

    <script src = "abc.com/script.js" integrity="sha256-123"></script>

A browser, such as Chrome, would kick off two requests, one to abc.com/script.js, and another to cdn.chrome.com/sha256-123/abc.com/script.js. The second request is for a pre-compiled and cached version of the script (the binary ast). If it doesn't exist yet, the cdn itself will download it, compile it, and cache it. For everyone except the first person to ever load this script, the second request returns before the time it takes for the first to finish + parse. Basically, the FIRST person to ever see this script online, takes the hit for everyone, since it alerts the "compile server" of its existence, afterwards its cached forever and fast for every other visitor on the web (that uses chrome). (I have later expanded on this to have interesting security additions as well -- there's a way this can be done such that the browser does the first compile and saves an encrypted version on the chrome cdn, such that google never sees the initial script and only people with access to the initial script can decrypt it). To clarify, this solution addresses the exact same concerns as the binary AST issue. The pros to this approach in my opinion are:

1. No extra work on the side of the developer. All the benefits described in the above article are just free without any new tooling.

2. It might actually be FASTER than the above example, since cdn.chrome.com may be way faster than wherever the user is hosting their binary AST.

3. The cdn can initially use the same sort of binary AST as the "compile result", but this gives the browser flexibility to do a full compile to JIT code instead, allowing different browsers to test different levels of compiles to cache globally.

4. This would be an excellent way to generate lots of data before deciding to create another public facing technology people have to learn - real world results have proven to be hard to predict in JS performance.

5. Much less complex to do things like dynamically assembling scripts (like for dynamic loading of SPA pages) - since the user doesn't also have to put a binary ast compiler in their pipeline: you get binary-ification for free.

The main con is that it makes browser development even harder to break into, since if this is done right it would be a large competitive advantage and requires a browser vendor to now host a cdn essentially. I don't think this is that big a deal given how hard it already is to get a new browser out there, and the advantages from getting browsers to compete on compile targets makes up for it in my opinion.

tomdale2• 9 years ago

I don't think the binary AST proposal changes the accessibility status quo. In my mind, the best analogy is to gzip, Brotli, etc.

If you had to have a complicated toolchain to produce gzipped output to get the performance boost, that would create a performance gap between beginners and more experienced developers.

But today, almost every CDN worth its salt will automatically gzip your content because it's a stateless, static transformation that can be done on-demand and is easily cached. I don't see how going from JavaScript -> binary AST is any different.

tolmasky3• 9 years ago

I actually think gzip serves as a good example of this issue: this comment alone is daunting to a beginner programmer and it really shouldn't. This chrome/cdn thing could ALSO be auto-gzipping for you so that a beginner throwing files on a random server wouldn't need to know whether it supports gzip or not. I think we really take for granted the amount of stuff completely unrelated to programming we've now had to learn. If our goal is to make the web fast by default, I think we should aim for solutions that work by default.

It's definitely the case that once a technology (such as gzip) gets popular enough it can get to "by default"-feeling status: express can auto-gzip, you can imagine express auto-binary-ast-ing. It's slightly more complicated because you still need to rely on convention of where the binary-ast lives if you want to get around the dual script tag issue for older browsers that don't support binary ast yet (or I suppose have a header that specifies it support binary ast results for js files?). Similarly, at some point CDN's may also do this for you, but this assumes you know what a CDN is and can afford one. The goal I'm after is it would be nice to have improvements that work by default on day 1, not after they've disseminated enough. Additionally, I think its really dangerous to create performance-targeted standards this high in the stack (gzip pretty much makes everything faster, binary ast one kind of file, and introduces a "third" script target of the browser). The chrome/cdn solution means that firefox/cdn might try caching at a different level of compilation, meaning we get actual real world comparisons for a year before settling on a standard (if necessary at all).

Edit: another thing to take into account, is that it now becomes very difficult to add new syntax features to JavaScript, if its no longer just the browser that needs to support it, but also the version of the Binary AST compiler than your CDN is using.

Yoric37• 9 years ago

Interesting idea, which could be built on top of the Binary AST.

I would personally prefer it being handled transparently by the middleware or the cdn, which would neatly separate the responsibilities between the browser, the cache+compressor and the http server.

Anyway, one of the reasons this project is only about a file format is so that we can have this kind of conversation about what the browsers and other tools can do once we have with a compressed JS file.

tolmasky3• 9 years ago

One of my fears about doing this at the CDN level is that now introducing a new syntax feature means you need the browser to support it AND the version of the Binary AST compiler on your CDN. Imagine using a new JS keyword and all of a sudden all your code gets slower because its a syntax error at the CDN level. It would just slower the rate of introduction of new syntax features I think by needing a lot more coordination: its already a bit messy with different browsers having different support, now caniuse.com may need to include CDN's too.

AgentME2• 9 years ago

This suggestion has a problem similar to the reason that browsers don't globally cache scripts based on integrity values: with your suggestion, if a domain temporarily hosts a .js file with a CSP-bypass vulnerability (ie. `eval(document.querySelector('.inline-javascript').textContent)` is a simple example; many popular javascript frameworks exist that do the equivalent of this), and then later removes it and starts using CSP, an attacker who knows an XSS vulnerability (which would otherwise be useless because of CSP) could inject a script tag with the integrity set equal to the CSP-vulnerable script that used to be hosted at the domain, and Chrome would find the script at the cdn.chrome.com cache.

(You might be thinking someone could set CSP to disable eval on their pages, but eval is reasonably safe even in the presence of otherwise-CSP-protected XSS attacks as long as you aren't using code that goes out of its way to eval things from the DOM, and it's more than annoying that the only way to protect yourself from this cache issue would be to disable eval. ... Also, there are some libraries that interpret script commands from the DOM without using eval, so disabling eval doesn't even protect you if you previously hosted one of those javascript files.)

You could have the cdn.chrome.com cache aggressively drop the cache of things greater than a certain amount of time like a day. But then there's a question of whether the requests to the cache are all just wasted bandwidth for the many requests by users to scripts that hadn't been loaded in a day. And the whole system means that website security can be dependent on cdn.chrome.com in some cases. I'd rather just build and host the processed binary AST myself. I already use a minifier; for most people, the binary AST tool would just replace their minifier.

mannschott• 9 years ago

This is reminiscent of the technique used by some versions of ETH Oberon to generate native code on module loading from a compressed encoding of the parse tree. Michael Franz described the technique as "Semantic-Dictionary Encoding":

«SDE is a dense representation. It encodes syntactically correct source program by a succession of indices into a semantic dictionary, which in turn contains the information necessary for generating native code. The dictionary itself is not part of the SDE representation, but is constructed dynamically during the translation of a source program to SDE form, and reconstructed before (or during) the decoding process. This method bears some resemblance to commonly used data compression schemes.»

See also "Code-Generation On-the-Fly: A Key to Portable Software" https://pdfs.semanticscholar.org/6acf/85e7e8eab7c9089ca1ff24...

This same technique also was used by JUICE, a short-lived browser plugin for running software written in Oberon in a browser. It was presented as an alternative to Java byte code that was both more compact and easier to generate reasonable native code for.

https://github.com/Spirit-of-Oberon/Juice/blob/master/JUICE....

I seem to recall that the particular implementation was quite tied to the intermediate representation of the OP2 family of Oberon compilers making backward compatibility in the face of changes to the compiler challenging and I recall a conversation with someone hacking on Oberon that indicated that he'd chosen to address (trans)portable code by the simple expedient of just compressing the source and shipping that across the wire as the Oberon compiler was very fast even when just compiling from source.

I'm guessing the hard parts are: (0) Support in enough browsers to make it worth using this format. (1) Coming up with a binary format that's actually significantly faster to parse than plain text. (SDE managed this.) (2) Designing the format to not be brittle in the face of change.

Yoric37• 9 years ago

Very interesting, thanks.

Indeed, one of the challenges was designing a format that will nicely support changes to the language. I believe that we have mostly succeeded there, and I'll blog about it once I find a little time. Now, of course, the next challenge is making sure that the file is still small enough even though we are using this future-proof format. We haven't measured this yet, but I expect that this will need additional work.

iamleppert• 9 years ago

I'd like to see some real-world performance numbers when compared with gzip. The article is a little overzealous in its claims that simply don't add up.

My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique.

This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's needed by their application, not on trying to optimize their fat JavaScript bundles. It's so lazy engineering.

apaprocki2• 9 years ago

It's specifically not trying to reduce size. It's trying to reduce time spent parsing in the JS engine.

Yoric37• 9 years ago

I'm guilty here: I described this format as "compression technique" because early feedback indicated that many people assumed this was a new bytecode. However, the main objective is indeed to speed up parsing. Compressing the file is a secondary goal.

My suspicion is it's going to be marginal and not worth the added complexity for what essential is a compression technique.

In terms of raw file size and according to early benchmarks (which may, of course, be proved wrong as we progress), Binary AST + gzip affords us a compression that is a little bit better than minification + gzip. By opposition to minification, Binary AST does not obfuscate the code.

The real gain is in terms of parsing speed, in which we get considerable speedups. I do not want to advertise detailed numbers yet because people might believe them, and we are so early in the development process that they are bound to change dozens of time.

This project is a prime example of incorrect optimization. Developers should be focused on loading the correct amount of JavaScript that's needed by their application, not on trying to optimize their fat JavaScript bundles. It's so lazy engineering.

Well, you are comparing optimizing the language vs. optimizing the code written in that language. These two approaches are and always will be complementary.

syg5• 9 years ago

The gzip point aside (which is not an apples-to-apples comparison as gzipping a big source does not diminish its parse time), I see the response of "JS devs need to stop shipping so much JS" often. My issue with this response is that multiple parties are all trying to work towards making JS apps load faster and run faster. It is easy enough to say "developers should do better", but that can be an umbrella response to any source of performance issues.

The browser and platform vendors do not have the luxury of fiat: they cannot will away the size of modern JS apps simply because they are causing slowdown. There can be engineering advocacy, to be sure, but that certainly shouldn't preclude those vendors from attempting technical solutions.

s3th2• 9 years ago

i'm very skeptical about the benefits of a binary JavaScript AST. The claim is that a binary AST would save on JS parsing costs. however, JS parse time is not just tokenization. For many large apps, the bottleneck in parsing is instead in actually validating that the JS code is well-formed and does not contain early errors. The binary AST format proposes to skip this step [0] which is equivalent to wrapping function bodies with eval… This would be a major semantic change to the language that should be decoupled from anything related to a binary format. So IMO proposal conflates tokenization with changing early error semantics. I’m skeptical the former has any benefits and the later should be considered on its own terms.

Also, there’s immense value in text formats over binary formats in general, especially for open, extendable web standards. Text formats are more easily extendable as the language evolves because they typically have some amount of redundancy built in. The W3C outlines the value here (https://www.w3.org/People/Bos/DesignGuide/implementability.h...). JS text format in general also means engines/interpreters/browsers are simpler to implement and therefore that JS code has better longevity.

Finally, although WebAssembly is a different beast and a different language, it provides an escape hatch for large apps (e.g. Facebook) to go to extreme lengths in the name of speed. We don’t need complicate JavaScript with such a powerful mechanism already tuned to perfectly complement it.

[0] https://github.com/syg/ecmascript-binary-ast/#-2-early-error...

syg5• 9 years ago

Early error behavior is proposed to be deferred (i.e. made lazy), not skipped. Additionally, it is one of many things that require frontends to look at every character of the source.

I contend that the text format for JS is no way easy to implement or extend, though I can only offer my personal experience as an engine hacker.

s3th2• 9 years ago

If early error is deferred then it's no longer early... that's all I meant by skipped. It still is a semantic change that's unrelated to a binary AST.

Yoric37• 9 years ago

Early benchmarks seem to support the claim that we can save a lot on JS parsing costs.

We are currently working on a more advanced prototype on which we will be able to accurately measure the performance impact, so we should have more hard data soon.

iainmerrick5• 9 years ago

It seems like one big benefit of the binary format will be the ability to skip sections until they're needed, so the compilation can be done lazily.

But isn't it possible to get most of that benefit from the text format already? Is it really very expensive to scan through 10-20MB of text looking for block delimiters? You have to check for string escapes and the like, but it still doesn't seem very complicated.

kannanvijayan3• 9 years ago

Our goal is not to complicate Javascript, but to improve parse times. Fundamentally that boils down to one issue: engines spend too much time chewing on every byte they load. The proposal then is to design a syntax that allows two things:

1. Allow the parser to skip looking at parts of code entirely.

2. Speed up parsing of the bits that DO need to be parsed and executed.

We want to turn "syntax parsing" into a no-op, and make "full parsing" faster than syntax parsing currently is - and our prototype has basically accomplished both on limited examples.

JS text format in general also means engines/interpreters/browsers are simpler to implement and therefore that JS code has better longevity.

As an implementor, I have to strongly disagree with this claim. The JS grammar is quite complex compared to a encoded pre-order tree traversal. It's littered with tons of productions and ambiguities. It's also impossible to do one-pass codegeneration with the current syntax.

An encoding of a pre-order tree traversal is not even context-free (it can be implemented on top of a deterministic PDA). It literally falls into a simpler class of parsing problems.

The binary AST format proposes to skip this step [0] which is equivalent to wrapping function bodies with eval…

This really overstates the issue. One can equally rephrase that statement as: if you are shipping JS files without syntax errors, then the behaviour is exactly identical.

That serves to bring to focus the real user-impact of this: developers who are shipping syntactically incorrect javascript to their users will have their pages fail slightly differently than their pages are failing currently.

Furthermore, the toolchain will simply prevent JS with syntax errors from being converted to BinaryJS, because the syntactic conversion is only specified for correct syntax - not incorrect syntax.

The only way you get a "syntax" error in BinaryJS is if your file gets corrupted after generation by the toolchain. But that failure scenario exists just the same for plaintext JS: a post-build corruption can silently change a variable name and raise a runtime exception.

So when you trace the failure paths, you realize that there's really no new failure surface area being introduced. BinaryJS can get corrupted in the exactly the same way with the same outcomes as plaintext JS can get corrupted right now.

Nothing to worry about.

We don’t need complicate JavaScript with such a powerful mechanism already tuned to perfectly complement it.

We need to speed up Javascript more, and parsing is one of the longest standing problems, and it's time to fix it so we can be fast at it.

Wasm is not going to make regular JS go away. Codebases in JS are also going to grow. As they grow, the parsing and load-time problem will become more severe. It's our onus to address it for our users.

svat• 9 years ago

However this technology pans out, thank for a really well-written post. It is a model of clarity.

(And yet many people seem to have misunderstood: perhaps an example or a caricature of the binary representation might have helped make it concrete, though then there is the danger that people will start commenting about the quality of the example.)

iainmerrick5• 9 years ago

This article says "Wouldn’t it be nice if we could just make the parser faster? Unfortunately, while JS parsers have improved considerably, we are long past the point of diminishing returns."

I'm gobsmacked that parsing is such a major part of the JS startup time, compared to compiling and optimizing the code. Parsing isn't slow! Or at least it shouldn't be. How many MBs of Javascript is Facebook shipping?

Does anyone have a link to some measurements? Time spent parsing versus compilation?

sltkr• 9 years ago

I think the main issue with parsing is that you probably need to parse all JavaScript before you can start executing any of it. That might lead to a high delay before you can start running scripts.

Compiling and optimizing code can be slow, too, but JIT compilers don't optimize all code that's on a page. At least at first, the code gets interpreted, and only hot code paths are JIT compiled, probably in a background threads. That means that compiling/optimizing doesn't really add to the page load latency.

But I agree with you that this is a strange suggestion. If parsing is so slow, maybe browsers should be caching the parsed representation of javascript sources to speed up page loading, or even better: the bytecode/JIT-generated code.

sjrd5• 9 years ago

If parsing is so slow, maybe browsers should be caching the parsed representation of javascript sources to speed up page loading, or even better: the bytecode/JIT-generated code.

This is addressed in the article: https://yoric.github.io/post/binary-ast-newsletter-1/#improv...

hashseed2• 9 years ago

Chrome already caches compile result for previously visited pages to bypass the initial parsing/compiling.

z3t4• 9 years ago

I wish for something like evalUrl() to run code that has already been parsed "in the background" so a module loader can be implemented in userland. It would be great if scripts that are prefetched or http2 pushed could be parsed in parallel and not have to be reparsed when running eval.

c-smile3• 9 years ago

To be honest I (as an author of the Sciter [1]) do not expect too much gain from that.

Sciter contains source code to bytecode compiler. Those bytecodes can be stored to files and loaded bypassing compilation phase. There is not too much gain as JS alike grammar is pretty simple.

In principle original ECMA-262 grammar was so simple that you can parse it without need of AST - direct parser with one symbol lookahead that produces bytecodes is quite adequate.

JavaScript use cases require fast compilation anyway. As for source files as for eval() and alike cases like onclick="..." in markup.

[1] https://sciter.com And JS parsers used to be damn fast indeed, until introduction of arrow functions. Their syntax is what requires AST.

timdorr• 9 years ago

How do you do one-symbol-lookahead with things like function hoisting?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

c-smile3• 9 years ago

Not clear how hoisting is related to parsing really ...

Compiler builds table of variables (registers map) of the function to generate proper bytecodes to access registers. At this point hoisting has some effect. But it has nothing with parse/AST phase.

limeblack2• 9 years ago

I have never been a fan of the => syntax. Although that really isn't the point. What about the syntax slows parsing?

c-smile3• 9 years ago

As I said original JS syntax is pretty simple - parsing is comparable with just scanning source buffer char by char.

Not too much different from HTML and CSS. Where 99% of time takes actual DOM creation.

Like this XML/HTML scanner that I did while ago: https://www.codeproject.com/Articles/14076/Fast-and-Compact-... - it as fast as access to memory of HTML source. It even does not allocate any memory while parsing.

limeblack2• 9 years ago

Could the AST be made an extension of the language similar to how it works in Mathematica?

Yoric37• 9 years ago

What do you mean? How does it work in Mathematica?

chr1• 9 years ago

Mathematica has several representations for the code the main one is the inputForm, the thing that users type in, and there is a fullForm which is the full ast, and there is a way to manipulate it to create new functions on the fly (or really any other objects, like graphic or sound, since everything in Mathematica is represented in a uniform way)

For instance if in input form you have {1 + 1, 2 *3 }, in fullForm this becomes List[Plus[1,1], Times[2, 3]], which is the readable version of lisp and internally represented the same way [List [Plus 1 1] [Times 2 3]].

The fullForm is accessible from the language, and can be manipulated using standard language feature, kind of like eval but better.

It would be really cool to have something like this in javascript, but unfortunately looks like javascript tools tend to create nonuniform ast, that is hard to traverse and manipulate

mnemotronic• 9 years ago

Yea! A whole new attack surface. A hacked AST file could cause memory corruption and other faults in the browser-side binary expander.

Yoric37• 9 years ago

Sure, a new file format always introduces a new risk. This has never prevented browsers from adding support for new image formats or compression schemes, though.

Towards a JavaScript Binary AST

Related Stories