SoylentNews is people
SoylentNews
from the things-expand-to-exceed-the-space-provided dept.
A couple years ago, I took a road trip from Wisconsin to Washington and mostly stayed in rural hotels on the way. I expected the internet in rural areas too sparse to have cable internet to be slow, but I was still surprised that a large fraction of the web was inaccessible. Some blogs with lightweight styling were readable, as were pages by academics who hadn't updated the styling on their website since 1995. But very few commercial websites were usable (other than Google). When I measured my connection, I found that the bandwidth was roughly comparable to what I got with a 56k modem in the 90s. The latency and packetloss were significantly worse than the average day on dialup: latency varied between 500ms and 1000ms and packetloss varied between 1% and 10%. Those numbers are comparable to what I'd see on dialup on a bad day.
Despite my connection being only a bit worse than it was in the 90s, the vast majority of the web wouldn't load. Why shouldn't the web work with dialup or a dialup-like connection? It would be one thing if I tried to watch youtube and read pinterest. It's hard to serve videos and images without bandwidth. But my online interests are quite boring from a media standpoint. Pretty much everything I consume online is plain text, even if it happens to be styled with images and fancy javascript. In fact, I recently tried using w3m (a terminal-based web browser that, by default, doesn't support css, javascript, or even images) for a week and it turns out there are only two websites I regularly visit that don't really work in w3m (twitter and zulip, both fundamentally text based sites, at least as I use them)[1].
More recently, I was reminded of how poorly the web works for people on slow connections when I tried to read a joelonsoftware post while using a flaky mobile connection. The HTML loaded but either one of the five CSS requests or one of the thirteen javascript requests timed out, leaving me with a broken page. Instead of seeing the article, I saw three entire pages of sidebar, menu, and ads before getting to the title because the page required some kind of layout modification to display reasonably. Pages are often designed so that they're hard or impossible to read if some dependency fails to load. On a slow connection, it's quite common for at least one depedency to fail. After refreshing the page twice, the page loaded as it was supposed to and I was able to read the blog post, a fairly compelling post on eliminating dependencies.
[1] excluding internal Microsoft stuff that's required for work. Many of the sites are IE only and don't even work in edge. I didn't try those sites in w3m but I doubt they'd work! In fact, I doubt that even half of the non-IE specific internal sites would work in w3m.
(Score: 4, Insightful) by Thexalon on Monday September 16 2019, @11:31PM
JS is an incredibly dynamic language. Any variable can be literally anything, defined anywhere. And of course libraries can come from anywhere, potentially not even really available on the local server prior to browser execution because you know how that marketing tracker needs to know the page has been hit.
All that is in some ways extremely convenient for developers who want to copy some whizbang from somebody's public and permissively licensed Github or something, but has the problem of making it extremely difficult to trace execution of code from all possible user inputs and server-side conditions in response to AJAX calls. Which means that the 15Kb thingamabob that you're really only using 1Kb of, which in turn relies on 3 other libraries that come in at 2 Mb each but you really only need a few functions from each of them, and those libraries rely on several more Mb of libraries even though those aren't really needed for the original thingamabob but it says in the documentation you need them and the libraries check for the existence of the other libraries ...
The upshot is that until there's a consistent and easy way to prune JS on the server side to what's actually needed (and cache the pruned version of course so this only needs to be done after a code update), we're going to continue to see ever-increasing JS bloat. After all, for nearly all organizations, their developer time is more valuable than your CPU time.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.