Hacker News Reader

Comment by codedokode | Hacker News Reader

I don't like the part that explains the motivation for implementing binary encoding:

> A brief survey from July 2017 of the uncompressed JS payload sizes for some popular web applications on desktop and mobile:

> Facebook 7.1 MB

I think Facebook should just remove the code they don't need rather than invent new compression methods. There is no way a social network with a chat needs so much JS code.

View on HN

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.

You forget that Facebook code is executed inside a browser (for example it doesn't have to render UI because HTML/CSS engine does that) while "desktop chat applications" can contain a Webkit engine, Node.JS and a lot of bloated uncompiled libraries.

7Mb of Javascript is too much. 200-300 Kb should be enough to view photos and post comments.

To be fair, pretty much any platform (operating system) provides rich APIs and basic functionality like built-in UI components. So I don't think there's a lot more pre-existing functionality in a browser vs Windows or Android.

I think you are wrong. Windows API compared to HTML APIs are very low-level. For example, there is no automatic layout and you must specify exact size and position of every GUI element like button or input field.

Some apps use a GUI framework, and don't combine it with their app into a single file, which makes for a better comparison (e.g. Paltalk does this).

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

Chrome now caches compiled code: https://v8project.blogspot.ca/2015/07/code-caching.html

In addition to this, browsers do lazy parsing. They do not fully parse the bodies of functions until the functions are executed.

Note that "lazy parsing" means "do most of the parsing, just don't store the result". That's a consequence of the specifications of JavaScript that require all syntax errors to be thrown as early as possible.

This is something that would change with the Binary AST, hence allowing much lazier parsing.

Firefox now caches bytecode, too.

https://groups.google.com/forum/#!topic/mozilla.dev.platform...

Note, however, that caching bytecode solves a different problem. Caching bytecode is great for the second+ load of a website. Making initial parsing faster is great for the first load of a website since its latest update. If you consider that Facebook updates its front-end once per hour, for instance, that's a lot for some (not all) websites.

Also, the size improvements may come in useful for applications written in, say, Cordova/PhoneGap.

I meant "several times per day".

Chrome and Firefox both cache hot code in its compiled (bytecode) form. This proposal addresses cold code loads. Many web apps update frequently (more than once per day) making caching much less effective, and cold code much more common.

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.

Yes, Facebook already lazily loads code for secondary functionality. More details in this comment https://news.ycombinator.com/item?id=14912871

Please also look at my comment that shows the opposite: Facebook is loading a lot of unnecessary modules: https://news.ycombinator.com/item?id=14916177

Yup, replied above. Thanks for digging into this more :)

Still, in my experience, Facebook chats loads several Megabytes (that's gzipped size) of JavaScript upon startup. In this case, lazy loading gets into the way of performance, as Facebook chat ends up lazily loading 102 files (if I recall correctly).

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.

Most of the code doesn't have to be loaded immediately. For example, you write in your comment, that Facebook can play 360 degrees videos, but the player doesn't have to be loaded until the user tries to play such a video.

I decided to look at Facebook code more closely. It is modular and contains several thousand of small modules. For example, on a news feed page the browser has loaded 66 JS files with total size of 5.7Mb containing 3062 modules [1].

But it is clear that many of those modules are not necessary to display a page. For example, a module with a name "XP2PPaymentRequestDeclineController" that is probably related to payments is not necessary. Or a module with a name "MobileSmsActivationController". Obviously Facebook preloads a lot of code for different dialogs that might be unused most of the times the page is loaded.

Of course I understand that it is very difficult to optimize code when a large team is contantly writing new code and everybody has strict deadlines so there is no time for optimizations, especially if they require serious refactoring.

[1] https://gist.github.com/codedokode/cb506cee367bdb9e1071bc186...

Facebook.com today loads functionality dynamically. Open the Network panel, interact with a secondary feature, and you will see it load code on-demand.

With respect to your example of unnecessary modules, sometimes the dependency trees between modules are non-obvious. But more to the point, the code served to a user is NOT personalized for each individual user and to their specific newsfeed and UI contents. This is actually a performance optimization. Facebook looks at which modules are most commonly required across most users based on their recent activity, and then bundles those common modules into large packages and pushes them aggressively to the browser. This actually results in a very large loading-time win, but ends up overserving some % of extra modules that are not needed by a specific user.

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

Here, "the problem" is that parsing JavaScript is very slow (and the second problem is that sending these files can be pretty slow, too). WebAssembly cannot really ship JavaScript code. Well, I guess it could if someone were to write a JavaScript to native compiler and ship it as WebAssembly, but then you would end up with more problems:

- yet another JavaScript target, with possible incompatibilities, security issues, etc;

- you still need to ship the binaries, which will most likely be much larger (and much slower to parse) than your initial source code;

- "interesting" interactions between Wasm-compiled JS and browser-compiled JS, as well as the DOM, garbage-collection, ...

WebAssembly is a similar idea, but it only encodes the ASM.js subset of javascript, not the full language.

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

Reply on news.ycombinator.com