I don't understand why you'd consider this "low hanging fruit". What could the author have done to make it a high quality submission in your eyes?
The alternative is to have more awareness of the amount of dependencies you really need, of when you actually need a framework with a runtime, and so on. He mentioned a fair share of essentially static landing pages that really have no reason to ship so much crap. And even though it's not explicitly mentioned: this isn't just a potential issue for end users. This code likely makes life hard for the developers as well. With every dependency you get more potential for breaking changes. With every layer it gets harder to understand what's going on. The default shouldn't be to just add whatever you want and figure it out later, the default should be to ask yourself what really needs to be added. Both in terms of actual code, but also layers, technologies, frameworks, libraries.
Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.
The article is just a lot of vague pointing at sites and insinuating (not even asserting) that they're too bloated or not. I don't get a sense of whether it's worse that Medium ships 3mb of code or Soundcloud ships 12. There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
No. No it wouldn't. It's not the job of strangers on the internet to do the job of incompetent developers.
> Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?)
How does being a landing page for a web app excuse downloading 6-10 MB of javascript to show two pages of static text and images?
> Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?).
Here's a holistic overview of performance: The Performance Inequality Gap, 2024 https://infrequently.org/2024/01/performance-inequality-gap-...
> There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
Not clearly. Not clearly at all.
---
Edit: note on the incompetence.
If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube.
Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed.
They know. They either are so incompetent that they cannot do the job themselves, or they don't care.
[1] https://developer.chrome.com/docs/lighthouse/performance/thi...
[2] Over at webdev: https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed
BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles
"But JS is the biggest developer ecosystem in the world!"
These are hard problems and people have been complaining about software size forever. Back in the early 90s, it was bloated C++ code.
You will also see that all software continues to use more ram, more disk space, more network bandwidth etc. This trend has been going on for decades.
For example, why do we use JSON as an interchange format? It’s relatively slow (i.e. creating it and parsing it is slow), nor is it is not space efficient. Back in the 1980s, the Unix community created RPC and the RPC wire formats were much more efficient because they were binary formats. The reason we use JSON is it makes the developer’s life easier and because developers prefer ease of use to performance.
It's very hard to, unless there is a risk to the bottom line.
Let me pose it differently--apparently ZED is ridiculously fast code editor. Do I want to switch from my vscode investment? Or will I deal with the "bloat"
Many websites listed on the page don't even need JS.[0]
Consider how just a few years ago there used to be an entire suite of alternative frontends to major "web apps"/"social media platforms", which generally worked without any JS, and were created & ran by volunteers. In general, they all provided superior UX by just not loading megabytes and megabytes of tracking code; this would be the alternative.[1]
Now they are slowly evaporating: not because of lack of interest, but because it was affecting the margins of these companies, and they actively blocked the frontends.[2]
So I think of it this way: these megabytes and megabytes of JS do not serve me, the user. It's just code designed to fill the pockets of giant corporations that is running on my computer. Which is, indeed, quite infuriating.
OK, maybe not even that; after all, you get what you pay for. It's just sad that despite the technological possibilities, this is the norm we have arrived at.
[0]: Of course, there is valid use of JS, it's a wonderful technology. I'm talking about cases where you could pretty much write the whole thing in pure HTML without losing core functionality.
[1]: Well, only if there existed a viable financing model besides "selling user data to the highest bidder" :( technologically at least, it's possible.
[2]: See cases of bibliogram, teddit, libreddit, nitter, ...
Well, you're entitled to not visit/use those websites if the megabytes of JS don't serve you. That would be the cost of the decision made to use Javascript by those websites, to have people that share your opinion not using them. And cost is a subjective factor dependent on multiple things and hidden from the user, so when you judge a website to be using Javascript without need, you're basically saying that you know better the cost to the developer than the developer itself.
An absurd, idiotic situation that is endemic to the whole industry deserves every bit of scorn and ridicule. Developers need to be educated about this so they can make the right choices, instead of remaining complacent agents of a shameful situation. It also strengthens my own resolve to support (through my use) those websites that abide by the original principles of the web: they either deliver actual documents (instead of javascript apps), or offer public APIs to access the plaintext data. There is always an alternative out there.
The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hint: look at how big games have become, is it only textures though?).