7 ms·

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 s

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.

tachyonbeam 9y ago
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.
- Yoric 9y ago
  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).
- djeric3 9y ago
  Yes, Facebook already lazily loads code for secondary functionality. More details in this comment https://news.ycombinator.com/item?id=14912871 https://news.ycombinator.com/item?id=14912871
  - codedokode 9y ago
    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 https://news.ycombinator.com/item?id=14916177
    - djeric3 9y ago
      Yup, replied above. Thanks for digging into this more :)
13of40 9y ago
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.)
- tachyonbeam 9y ago
  Chrome now caches compiled code: https://v8project.blogspot.ca/2015/07/code-caching.html 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.
  - Yoric 9y ago
    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.
- Yoric 9y ago
  Firefox now caches bytecode, too. https://groups.google.com/forum/#!topic/mozilla.dev.platform/4u6EsaDC7kY 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.
  - Yoric 9y ago
    I meant "several times per day".
- djeric3 9y ago
  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.
colejohnson66 9y ago
Honest question: isn’t this problem already addressed by WebAssembly’s binary encoding?
- ZenPsycho 9y ago
  WebAssembly is a similar idea, but it only encodes the ASM.js subset of javascript, not the full language.
- Yoric 9y ago
  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, ...
true_religion 9y ago
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.
- codedokode 9y ago
  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.
  - djeric3 9y ago
    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.
    - codedokode 9y ago
      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.
      - true_religion 9y ago
        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).
rtpg 9y ago
Do you think that Google Sheets should cut back on their 6 MB of code?
djeric3 9y ago
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-pipelining-web-pages-for-high-performance/389414033919/ 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 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.
- codedokode 9y ago
  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/cb506cee367bdb9e1071bc18657c3fdd https://gist.github.com/codedokode/cb506cee367bdb9e1071bc186...

tachyonbeam 9y ago

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.

Yoric 9y ago
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).
djeric3 9y ago
Yes, Facebook already lazily loads code for secondary functionality. More details in this comment https://news.ycombinator.com/item?id=14912871 https://news.ycombinator.com/item?id=14912871
- codedokode 9y ago
  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 https://news.ycombinator.com/item?id=14916177
  - djeric3 9y ago
    Yup, replied above. Thanks for digging into this more :)

13of40 9y ago

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

tachyonbeam 9y ago
Chrome now caches compiled code: https://v8project.blogspot.ca/2015/07/code-caching.html 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.
- Yoric 9y ago
  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.
Yoric 9y ago
Firefox now caches bytecode, too. https://groups.google.com/forum/#!topic/mozilla.dev.platform/4u6EsaDC7kY 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.
- Yoric 9y ago
  I meant "several times per day".
djeric3 9y ago
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.

colejohnson66 9y ago

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

ZenPsycho 9y ago
WebAssembly is a similar idea, but it only encodes the ASM.js subset of javascript, not the full language.
Yoric 9y ago
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, ...

true_religion 9y ago

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.

codedokode 9y ago
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.
- djeric3 9y ago
  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.
  - codedokode 9y ago
    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.
    - true_religion 9y ago
      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).

rtpg 9y ago

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

djeric3 9y ago

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-pipelining-web-pages-for-high-performance/389414033919/ 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 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.

codedokode 9y ago
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/cb506cee367bdb9e1071bc18657c3fdd https://gist.github.com/codedokode/cb506cee367bdb9e1071bc186...