Proposal for a Binary Encoding of the JavaScript AST

I feel like this is an unfair criticism unless you know what the page is doing.

People are building entire vector editing programs on the web. How can you be fine with Photoshop being several hundred megs but not with this person having less than 10 megs of code to achieve something similar?

The web isn't just Hacker News and CNN. People write real programs on it.

Obviously shipping less code is Good(TM). But isn't an across the board improvement also good?

This is quite mean.

There is nothing wrong with doing both this and cutting down on bloat.

As you probably know, building a sophisticated application can easily become quite complex. This is the case even if the application is designed to look non-sophisticated, as Twitter or Facebook, for instance. Now, when we are discussing desktop applications or mobile applications, people typically do not care all that much about the codesize, because it is essentially invisible to the user. For instance, who cares that the Steam binary (just the binary, without resources or dynamic dependencies) weighs 3.1Mb or that the Gimp binary (again, without resources or dynamic dependencies) weighs ~9Mb or that the Telegram binary weighs ~11Mb?

On the web, of course, since the application is downloaded dynamically, rather than being installed, people don't expect to wait and they start noticing. In some cases, web developers can fine tune their JS to make sure that less of it is shipped. Very quickly, however, this becomes horribly expensive, because it's a complicated problem with any language and JS is really not suited to static analysis and static code optimizations.

Of course, another part of the problem is that the delivery format of JS (i.e. the source code) is optimized for small files. For larger files, we can do much better. This is the objective of this project.

We're not stopping until facebook.com is the same 240 MB download that Facebook for iOS is.

...but service workers so users will love it!!! ...right?

It's also possible to dynamically, lazily load some parts of the JS code. Surely not all the code is needed all the time. For example, you may not need to load the code for the settings page until the user actually goes to edit the settings.

This is kind of a noob question, but do you have any idea if Javascript actually gets fully parsed on the client side every time it's used, or if the AST gets cached? (Let's assume the "client side" is a newish version of Chrome.)

Honest question: isn’t this problem already addressed by WebAssembly’s binary encoding?

Just 7.1MB of source? That's smaller than some desktop chat applications used to be, even when they basically just use the default windows styles.

Do you think that Google Sheets should cut back on their 6 MB of code?

Facebook already only ships code that is needed to render the current page. It even goes further and it streams the code in phases so that the browser renders the UI incrementally and the page becomes interactive as soon as possible. It then pulls in code dynamically for any secondary feature only if the user interacts with that feature.

Some of the design is documented here https://www.facebook.com/notes/facebook-engineering/bigpipe-...

Facebook has done a TON of optimization. The fundamental issue is that Facebook is not a webpage, it's a full application. And the Web as an application platform lags behind native platforms with respect to startup performance.

I explained why Facebook.com is really an app in this comment https://news.ycombinator.com/item?id=14912393

Now compare the functionality of the Facebook Android app vs Facebook desktop webpage (nearly identical) and look at their respective installed sizes (~7MB vs ~180MB).

This proposal will benefit both web apps and web documents. And more importantly, it will allow people to build richer, more sophisticated applications on the web without sweating over extra kilobytes in their JS code size.

This seems pretty easy though.

When you parse, you parse to the same JS AST.

When you show it in the browser, you show the text form of the JS AST. Source maps like normal.

It's a reasonably lightweight proposal, though IDK if it will be compelling enough.

I don't know of anyone who actually audits the JS they run. I know people (like Richard Stallman) who don't run JS at all, and people (like my roommate) who use NoScript with exceptions for websites they trust—which is a trust by website, not by code; they'll trust any JS that origin produces in the future. I suppose there are people running GNU LibreJS and running any JS that claims to be freely licensed, but again without looking at the code to see if it's heavily obfuscated. And then there's the rest of us, the vast majority, who just run all the JS we se.

If we already had people who audit JS before running it, preserving auditability would be worth doing, but keeping the ability to do something that (I think) literally nobody has done in over 20 years of JavaScript isn't worth trading off actual technical improvements for.

Fortunately we have something very different and (IMO) more practical, that makes this very different from an "index.exe" model: we have isolation between websites enforced at the browser level. aim.exe can read my saved quicken.exe documents. hangouts.google.com cannot interact with my bankofamerica.com account; it can't even know that I have one.

I think I have a right to see source to all the code that runs on my device with full privilege. I also think I have a right to limit the powers of code to which I don't have source, including both limiting what sorts of things it has access to and how much CPU, memory, etc. it's allowed to consume. I don't really know that insisting on the right to see source to code that runs confined is actually going to measurably improve my computing freedom.

it just feels like putting lipstick on a pig, use binary to solve the problem of bloated utf8 files.

This is an encoding of the JS AST, so it has a 1-to-1 mapping to JS (modulo whitespace, but the JS would probably be minified anyway). It would be trivial to build a tool to convert this back into JS, and browser devtools will probably do that automatically.

It seems that you (like a great number of other people) assume that an ordinary person without special skills cannot comprehend what some code does once it is compiled. But that assumption is fortunately wrong. It is easier than you think to learn to read disassembly of machine code. It would be much easier to read higher level bytecode such as Android VM's smali.

So don't fear compilation. What is truly worrying is any attempt to restrict access to code that is run by a computer. Even a highly skilled reverse engineer cannot do anything if there is no way to access code.

Nowadays, most JS is uglified/minified on build anyway. I believe that times when after-build JS code was readable for the end user are long gone.

Slow parsing speed is due to several things:

- encoding issues;

- ambiguous stuff (for instance, `/` can be the start of a comment, the start of a regexp or a division, `()` or `{}` can have several meanings, etc.);

- odd behavior (variables can be used before they are declared, double-declaring variables is sometimes valid but not always, etc.);

- plenty of information that is necessary for execution is only available after you need it (sometimes much later, e.g. determining free variables, determining whether `eval` can affect local variables, etc).

Also, this syntax makes it impossible to perform concurrent parsing (at least not without extremely costly non-concurrent pre-parsing) and makes it basically impossible to perform lazy parsing (at least not without this same extremely costly pre-parsing).

If I understand correctly, your suggestion would have been to:

1. provide a "better" developer-facing text syntax;

2. if necessary, move to binary parsing.

Your suggestion makes sense but I believe that it underestimates seriously the ability to:

a. come up with an alternative, easier to parse, text syntax;

b. make sure that your text syntax has the same semantics as the original syntax;

c. get everybody to agree on that text syntax;

d. maintain this text syntax through successive versions of JavaScript, without losing its desirable properties;

e. have every browser maintain two text parsers.

Also, note that b. most likely means standardizing upon an AST, which is roughly half of the difficulty of the current proposal.

Finally, unless I am missing something, your suggestion does not improve concurrent or lazy parsing. One of the core benchmarks behind the current proposal is that lazy parsing can be made extremely faster than non-lazy parsing, as soon as you the expensive pre-parsing phase has been abolished.

Does this answer your questions?

I wrote https://news.ycombinator.com/item?id=14908903 in answer to a different question. Does it answer your points, by any chance?

Out of curiosity: do you actually use `Function.prototype.toString()`? I haven't seen any use of this method in years. Plus the few uses that I have seen were libraries that attempted to rewrite other libraries and broke at pretty much each update of their dependencies.

There may be legitimate uses of this method in production code, but I can't think of any from the top of my mind. If you can think of one, don't hesitate to file it as an issue in the linked tracker.

> don't break other people's code for your own profit.

How is adding a new kind of function (created from the AST encoding instead of source) with it's own definition of .toString() going to break other people's code?

If you don't use binary ASTs you will never even see the new behavior. Unless you are the one mucking around with other people's code, in which case

  >> Function.prototype.toString.toString()
     "function toString() {
        [native code]
     }"

Function.protoype.toString is already broken for functions without available source.

Breaking Function.prototype.toString() might actually be a good idea because now the engine has to keep the source code in memory and most of the times it is absolutely unnecessary. It would be better to free this memory.

For what it's worth, I'm currently implementing the Binary AST parser (using the current candidate AST) in SpiderMonkey (which uses its own AST, of course) and that doesn't cause any issue so far.

The AST used in the file is a convenient abstraction but doesn't need to match the AST used in-memory.

Yes and no.

You are right, after the initial fetch, everything should be cached locally. However, caching traditionally does not affect parsing speed. While size gains are a nice side-benefit of this proposal, the main benefit is parsing speed.

Now, both Chromium and Firefox have introduced smarter caching that caches post-parsing data for websites that you have already visit (or visit often, I don't remember the heuristics). This is very useful for all the sites that you visit regularly and that do not update their JS code between your visits. However, for all the sites that do update their JS code between your visits, including Facebook (which updates several times per day), Google Docs, etc. and every random website that you read because of a link on Hacker News but will never revisit again, there is a potentially pretty large size benefit.

Does this answer your question?

People are downvoting my comment for some reason.

The whole premise of "binary javascript AST" is "compile JavaScript into binary representation because bundle sizes are just too big and takes too much time to parse".

Isn't WebAssembly designed to kinda solve that and many other problems presented in the Readme among other things? Instead of parsing JS (or whatever language) you just download binary (which has been compiled, optimised etc.).

So, instead of designing webassembly to support the most important language on the web, the committee (as always, there's an effing committee to committee the hell out of things) designs webassembly with just one single language in mind: C++. Because reasons.

Hence, this ridiculous proposal: oh, let's create a binary representation of Javascript AST because reasons. Because "oh, we can't compile to webassembly because webassembly hasn't even been designed to support the main language on the web and many other major languages".

Instead, we're just going for the lame excuse of "no vendor would agree to ship bytecode." (why would they agree to ship binary ASTs?) and "there is no guarantee that it would be any faster to transmit/parse/start" (where's the guarantee with binary AST?).

WebAssembly is well suited for statically typed codebases written in C++ etc. You can't compile JavaScript to WebAssembly. Yes, you could do Web development in a statically typed language, but would you want to?