Comment by KronisLV

2 years ago

A lot of what is written in the article holds true, despite its age. For example, let's take the tweet as an example:

> If you open that tweet in a browser, you'll see the page is 900 KB big.

If you look at how big the page is now you'll get something along the lines of this: https://gtmetrix.com/reports/twitter.com/aJKMCxUq/

  2.00 MB (7.56 MB uncompressed)
  1.68 MB of JavaScript
  0.18 MB of fonts
  0.08 MB of HTML
  0.04 MB of images
  ... (some other requests)
  (185 total page requests)

On other sites you see similar amounts of data, though sometimes more custom fonts, or images, or other media.

I used to think that this was because the developers just don't care, or that designers and product managers go wild (which I still do, admittedly), but in the recent years I've felt more and more that this is because the way browsers work is flawed. Nobody seems to complain (much) that browser X install size is Y MB, yet for whatever reason each site is treated as its unique universe where you often re-download what is mostly the same thing over and over, the wasted bandwidth accumulating over time.

Here's a slightly crazy thought experiment:

  - what if all of the frameworks/libraries decoupled the framework/library code from the application code (e.g. React, Angular, Vue), essentially you'd have react-version-X.js and my-site-com-app.js
  - maybe even do this for the most popular libraries and component frameworks, like react-primevue-version-X.js
  - what if browsers shipped the most popular framework/library code versions in them, so those would never need to be downloaded from the visited sites, but would be available locally already
  - what if browsers did the same for most of the popular freely available fonts, too - enough to placate the designers, say, the top 100 of the most popular fonts under each category (serif, sans serif, monospace, ...)
  - everything else can be downloaded the old way, or maybe browsers can provide a package manager of sorts (e.g. site requested Alpine version X, this will be downloaded and re-used for other sites)
  - maybe mandate that only X updates per year are allowed per framework/library or other resource type, to fight off bloat due to trigger happy teams who want to release often

A little bit like a CDN, except that baked into the browser (or selectable as an install option). Of course, this will never happen, because it would require a lot of work on the part of the browsers, would create an "in crowd" of supported resources with everything else having lower chances of becoming as popular, nor could people ever agree upon what are the most popular resources out there to pre-install. But my argument is that we're stuck with the same popular Google Fonts in most sites anyways, as well as a few large JavaScript frameworks that everyone uses regardless, so a lot of the current bloat makes little sense anyways.

Then again, one can feasibly also imagine a world where the user is given a choice to only view downscaled images on all the sites that they visit (which, IIRC, was the case with the Opera Mobile browsers a while back) if they want, or a bunch of other simple to use options, like never downloading custom (non-icon) fonts, should they choose to. But that's not quite the world that we live in - especially in regards to JavaScript, which you often cannot disable and hope that the site will keep working, because it won't.

Worse yet, optimizations that are cool and useful, like how Google Fonts splits up fonts into multiple files based on the character sets, so only the ones needed actually are downloaded, are hard to pull off yourself for arbitrary fonts and so on, for example: https://fonts.googleapis.com/css2?family=Open+Sans&display=s... This last bit is also why my own site is unreasonably bloated (aside from the fact that I chose a non-web-safe font in the first place, to look more like the fancy sites): https://gtmetrix.com/reports/kronis.dev/l0nIApXL/

If you take your plan (sans the final point) and replace "shipped with the browser download" with "only downloaded once the first time it is needed" then you basically describe how pre-webpack websites all worked. Everyone was putting the CDN url for jquery in their html head and browsers were reading from their local cache for every site after the 1st.

I think it's still perfectly possible to do that with React but everyone wants to write JSX and transpile it instead of doing this procedurally so it gets webpacked anyway. Caveat, I haven't touched React in about 4 years so I don't know if that's still true.

Your final point about disallowing more than X updates per year is unworkable due to the unpredictability of security patches.