5 ms·

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of f

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

mwcampbell 2y ago
False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.
- SpaceNugget 2y ago
  Well, in TFA, if you re-read the section labeled "Detailed, Real-world Example" yes, that is exactly what the person was encountering. So no hyperbole at all actually.
- bayindirh 2y ago
  I just tried some websites: - https://web.whatsapp.com 11.12MB compressed / 26.17MB real. - https://www.arstechnica.com 8.82MB compressed / 16.92MB real. - httsp://www.reddit.com 2.33MB compressed / 5.22 MB real. - https://www.trello.com (logged in) 2.50MB compressed / 10.40MB real. - https://www.notion.so (logged out) 5.20MB compressed / 11.65MB real. - https://www.notion.so (logged in) 19.21MB compressed / 34.97MB real.
- tecleandor 2y ago
  Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed): - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS - Google Calendar: 30% lower, but more or less the same proportions - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. - Jira: Home is ~35MB (~7MB compressed). I see more than 25MB of Javascript - Google Cloud Console: 30MB (~7MB Comp.). I see at least 16MB of JS - AWS Console: 18MB (~4MB Comp.). I think it's at least 12MB of JS - New Relic: 14MB (~3MB Comp.). 11MB of JS. This is funny because even being way more data heavy than the rest, its weight is way lower. - Wiz: 23MB (~6MB Comp.) 10MB of JS and 10MB of CSS - Slack: 60MB (~13MB Compressed). Of that, 48MB of JS. No joke.
  - tonyhart7 2y ago
    too much crap holy and this is worse case scenario with adblock
  - jerf 2y ago
    I sometimes wish I could spare the time just to tear into something like that Slack number and figure out what it is all doing in there. Javascript should even generally be fairly efficient in terms of bytes/capability. Run a basic minimizer on it and compress it and you should be looking at something approaching optimal for what is being done. For instance, a variable reference can amortize down to less than one byte, unlike compiled code where it ends up 8 bytes (64 bits) at the drop of a hat. Imagine how much assembler "a.b=c.d(e)" can compile into to, in what is likely represented in less compressed space than a single 64-bit integer in a compiled language. Yet it still seems like we need 3 megabytes of minified, compressed Javascript on the modern web just to clear our throats. It's kind of bizarre, really.
    - LtWorf 2y ago
      js developers had this idea of "1 function = 1 library" for a really long time, and "NEVER REIMPLEMENT ANYTHING". So they will go and import a library instead of writing a 5 line function, because that's somehow more maintainable in their mind. Then of course every library is allowed to pin its own dependencies. So you can have 15 different versions of the same thing, so they can change API at will. I poked around some electron applications. I've found .h files from openssl, executables for other operating systems, megabytes of large image files that were for some example webpage, in the documentation of one project. They literally have no idea what's in there at all.
    - mike_hearn 2y ago
      That's a good question. I just launched Slack and took a look. Basically: it's doing everything. There's no specialization whatsoever. It's like a desktop app you redownload on every "boot". You talk about minification. The JS isn't minified much. Variable names are single letter, but property names and more aren't renamed, formatting isn't removed. I guess the minifier can't touch property names because it doesn't know what might get turned into JSON or not. There's plenty of logging and span tracing strings as well. Lots of code like this: _n.meta = { name: "createThunk", key: "createThunkaddEphemeralMessageSideEffectHandler", description: "addEphemeralMessageSideEffect side effect handler" }; The JS is completely generic. In many places there are if statements that branch on all languages Slack was translated into. I see checks in there for whether localStorage exists, even though the browser told the server what version it is when the page was loaded. There are many checks and branches for experiments, whether the company is in trial mode, whether the code is executing in Electron, whether this is GovSlack. These combinations could have been compiled server side to a more minimal set of modules but perhaps it's too hard to do that with their JS setup. Everything appears compiled using a coroutines framework, which adds some bloat. Not sure why they aren't using native async/await but maybe it's related to not being specialized based on execution environment. Shooting from the hip, the learnings I'd take from this are: 1. There's a ton of low hanging fruit. A language toolchain that was more static and had more insight into what was being done where could minify much more aggressively. 2. Frameworks that could compile and optimize with way more server-side constants would strip away a lot of stuff. 3. Encoding logs/span labels as message numbers+interpolated strings would help a lot. Of course the code has to be debuggable but hopefully, not on every single user's computer. 4. Demand loading of features could surely be more aggressive. But Slack is very popular and successful without all that, so they're probably right not to over-focus on this stuff. Especially for corporate users on corporate networks does anyone really care? Their competition is Teams after all.
- b3orn 2y ago
  I'm getting almost 2MB (5MB uncompressed) just for a google search.
- ezequiel-garzon 2y ago
  I agree with adding very little JavaScript, say 1kB https://instant.page/ https://instant.page/ to make it snappier.
andrepd 2y ago
Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW.
- LtWorf 2y ago
  The crap is that even themes for static site generators like mkdocs link resources from cloudflare rather than including them in the theme. For typedload I've had to use wget+sed to get rid of that crap after recompiling the website. https://codeberg.org/ltworf/typedload/src/branch/master/Makefile#L132-L139 https://codeberg.org/ltworf/typedload/src/branch/master/Make...
RGamma 2y ago
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
- pgraf 2y ago
  Shouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
- chris_pie 2y ago
  Check this proposal out: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
- jiggawatts 2y ago
  The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!
  - RGamma 2y ago
    Soo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
  - Lex-2008 2y ago
    > "server side rendering" with a GPU instead of sending more JavaScript Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources. For many popular websites, png screenshot of a page indeed was several times less than webpage itself!
mike_hearn 2y ago
Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most people don't know it exists yet/frameworks don't use it. 2. Large download sizes tend to come from frameworks that are featureful and thus widely used. Browsers could allow them to be cached but don't because they're over-aggressive at shutting down theoretical privacy problems, i.e. the browser is afraid that if one site learns you used another site that uses React, that's a privacy leak. A reasonable solution would be to let HTTP responses opt in to being put in the global cache rather than a partitioned cache, that way sites could share frameworks and they'd stay hot in the cache and not have to be downloaded. But browsers compete to satisfy a very noisy minority of people obsessed with "privacy" in the abstract, and don't want to do anything that could kick up a fuss. So every site gets a partitioned cache and things are slow. 3. Browsers often ignore trends in web development. React style vdom diffing could be offered by browsers themselves, where it'd be faster and shipped with browser updates, but it isn't so lots of websites ship it themselves over and over. I think the SCIter embedded browser actually does do this. CSS is a very inefficient way to represent styling logic which is why web devs write dialects like sass that are more compact, but browsers don't adopt it. I think at some pretty foundational level the way this stuff works architecturally is wrong. The web needs a much more modular approach and most JS libraries should be handled more like libraries are in desktop apps. The browser is basically an OS already anyway.
- semi 2y ago
  The privacy issues aren't just hypothetical, but that aside, that caching model unfortunately doesn't mesh well with modern webdev. It requires all dependencies to be shipped in full, no tree shaking to only include the needed functions. And separately as individual files.. and for people to actually stick to the same versions of dependencies
  - mike_hearn 2y ago

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

mwcampbell 2y ago

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

SpaceNugget 2y ago
Well, in TFA, if you re-read the section labeled "Detailed, Real-world Example" yes, that is exactly what the person was encountering. So no hyperbole at all actually.
bayindirh 2y ago
I just tried some websites: - https://web.whatsapp.com 11.12MB compressed / 26.17MB real. - https://www.arstechnica.com 8.82MB compressed / 16.92MB real. - httsp://www.reddit.com 2.33MB compressed / 5.22 MB real. - https://www.trello.com (logged in) 2.50MB compressed / 10.40MB real. - https://www.notion.so (logged out) 5.20MB compressed / 11.65MB real. - https://www.notion.so (logged in) 19.21MB compressed / 34.97MB real.
tecleandor 2y ago
Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed): - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS - Google Calendar: 30% lower, but more or less the same proportions - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. - Jira: Home is ~35MB (~7MB compressed). I see more than 25MB of Javascript - Google Cloud Console: 30MB (~7MB Comp.). I see at least 16MB of JS - AWS Console: 18MB (~4MB Comp.). I think it's at least 12MB of JS - New Relic: 14MB (~3MB Comp.). 11MB of JS. This is funny because even being way more data heavy than the rest, its weight is way lower. - Wiz: 23MB (~6MB Comp.) 10MB of JS and 10MB of CSS - Slack: 60MB (~13MB Compressed). Of that, 48MB of JS. No joke.
- tonyhart7 2y ago
  too much crap holy and this is worse case scenario with adblock
- jerf 2y ago
  I sometimes wish I could spare the time just to tear into something like that Slack number and figure out what it is all doing in there. Javascript should even generally be fairly efficient in terms of bytes/capability. Run a basic minimizer on it and compress it and you should be looking at something approaching optimal for what is being done. For instance, a variable reference can amortize down to less than one byte, unlike compiled code where it ends up 8 bytes (64 bits) at the drop of a hat. Imagine how much assembler "a.b=c.d(e)" can compile into to, in what is likely represented in less compressed space than a single 64-bit integer in a compiled language. Yet it still seems like we need 3 megabytes of minified, compressed Javascript on the modern web just to clear our throats. It's kind of bizarre, really.
  - LtWorf 2y ago
    js developers had this idea of "1 function = 1 library" for a really long time, and "NEVER REIMPLEMENT ANYTHING". So they will go and import a library instead of writing a 5 line function, because that's somehow more maintainable in their mind. Then of course every library is allowed to pin its own dependencies. So you can have 15 different versions of the same thing, so they can change API at will. I poked around some electron applications. I've found .h files from openssl, executables for other operating systems, megabytes of large image files that were for some example webpage, in the documentation of one project. They literally have no idea what's in there at all.
  - mike_hearn 2y ago
    That's a good question. I just launched Slack and took a look. Basically: it's doing everything. There's no specialization whatsoever. It's like a desktop app you redownload on every "boot". You talk about minification. The JS isn't minified much. Variable names are single letter, but property names and more aren't renamed, formatting isn't removed. I guess the minifier can't touch property names because it doesn't know what might get turned into JSON or not. There's plenty of logging and span tracing strings as well. Lots of code like this: _n.meta = { name: "createThunk", key: "createThunkaddEphemeralMessageSideEffectHandler", description: "addEphemeralMessageSideEffect side effect handler" }; The JS is completely generic. In many places there are if statements that branch on all languages Slack was translated into. I see checks in there for whether localStorage exists, even though the browser told the server what version it is when the page was loaded. There are many checks and branches for experiments, whether the company is in trial mode, whether the code is executing in Electron, whether this is GovSlack. These combinations could have been compiled server side to a more minimal set of modules but perhaps it's too hard to do that with their JS setup. Everything appears compiled using a coroutines framework, which adds some bloat. Not sure why they aren't using native async/await but maybe it's related to not being specialized based on execution environment. Shooting from the hip, the learnings I'd take from this are: 1. There's a ton of low hanging fruit. A language toolchain that was more static and had more insight into what was being done where could minify much more aggressively. 2. Frameworks that could compile and optimize with way more server-side constants would strip away a lot of stuff. 3. Encoding logs/span labels as message numbers+interpolated strings would help a lot. Of course the code has to be debuggable but hopefully, not on every single user's computer. 4. Demand loading of features could surely be more aggressive. But Slack is very popular and successful without all that, so they're probably right not to over-focus on this stuff. Especially for corporate users on corporate networks does anyone really care? Their competition is Teams after all.
b3orn 2y ago
I'm getting almost 2MB (5MB uncompressed) just for a google search.
ezequiel-garzon 2y ago
I agree with adding very little JavaScript, say 1kB https://instant.page/ https://instant.page/ to make it snappier.

andrepd 2y ago

Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW.

LtWorf 2y ago
The crap is that even themes for static site generators like mkdocs link resources from cloudflare rather than including them in the theme. For typedload I've had to use wget+sed to get rid of that crap after recompiling the website. https://codeberg.org/ltworf/typedload/src/branch/master/Makefile#L132-L139 https://codeberg.org/ltworf/typedload/src/branch/master/Make...

RGamma 2y ago

Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...

pgraf 2y ago
Shouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
chris_pie 2y ago
Check this proposal out: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
jiggawatts 2y ago
The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!
- RGamma 2y ago
  Soo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
- Lex-2008 2y ago
  > "server side rendering" with a GPU instead of sending more JavaScript Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources. For many popular websites, png screenshot of a page indeed was several times less than webpage itself!

mike_hearn 2y ago

Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most people don't know it exists yet/frameworks don't use it. 2. Large download sizes tend to come from frameworks that are featureful and thus widely used. Browsers could allow them to be cached but don't because they're over-aggressive at shutting down theoretical privacy problems, i.e. the browser is afraid that if one site learns you used another site that uses React, that's a privacy leak. A reasonable solution would be to let HTTP responses opt in to being put in the global cache rather than a partitioned cache, that way sites could share frameworks and they'd stay hot in the cache and not have to be downloaded. But browsers compete to satisfy a very noisy minority of people obsessed with "privacy" in the abstract, and don't want to do anything that could kick up a fuss. So every site gets a partitioned cache and things are slow. 3. Browsers often ignore trends in web development. React style vdom diffing could be offered by browsers themselves, where it'd be faster and shipped with browser updates, but it isn't so lots of websites ship it themselves over and over. I think the SCIter embedded browser actually does do this. CSS is a very inefficient way to represent styling logic which is why web devs write dialects like sass that are more compact, but browsers don't adopt it. I think at some pretty foundational level the way this stuff works architecturally is wrong. The web needs a much more modular approach and most JS libraries should be handled more like libraries are in desktop apps. The browser is basically an OS already anyway.

semi 2y ago
The privacy issues aren't just hypothetical, but that aside, that caching model unfortunately doesn't mesh well with modern webdev. It requires all dependencies to be shipped in full, no tree shaking to only include the needed functions. And separately as individual files.. and for people to actually stick to the same versions of dependencies
- mike_hearn 2y ago