4 ms·

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why thi

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? 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?).

palmfacehn 3y ago
To let us know we are not alone with our disdain. Too many JS enthusiasts paper over this insanity. The remnant lives on. "But JS is the biggest developer ecosystem in the world!"
- StressedDev 3y ago
  This is not a JavaScript issue. It’s a software enginner/people issue. The question is how do you get people to care about performance, security, reliability, etc.? How do you get organizations to care about these issues? 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.
  - balls187 3y ago
    > The question is how do you get people to care about performance, security, reliability, etc...How do you get organizations to care about these issues? 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"
YuukiRey 3y ago
I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?id=39315585 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.
- guappa 3y ago
  > This code likely makes life hard for the developers as well. Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.
- matthewhammond 3y ago
  It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. 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?). 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?). Or maybe compare these web application sizes to mobile or desktop equivalents too (where it's surely easier to optimise amount of code shipped). 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.
shiomiru 3y ago
> What's the alternative? 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, ...
- iamsaitam 3y ago
  You're confounding using Javascript for web development and "loading megabytes of tracking code". They are not mutual exclusive, nor have anything to do with the development side of it. Advertising and tracking are a business decision, not technical one. 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.
xk_id 3y ago
> What's the point of it? What's the alternative? 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.

palmfacehn 3y ago

To let us know we are not alone with our disdain. Too many JS enthusiasts paper over this insanity. The remnant lives on. "But JS is the biggest developer ecosystem in the world!"

StressedDev 3y ago
This is not a JavaScript issue. It’s a software enginner/people issue. The question is how do you get people to care about performance, security, reliability, etc.? How do you get organizations to care about these issues? 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.
- balls187 3y ago
  > The question is how do you get people to care about performance, security, reliability, etc...How do you get organizations to care about these issues? 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"

YuukiRey 3y ago

I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?id=39315585 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.

guappa 3y ago
> This code likely makes life hard for the developers as well. Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.
matthewhammond 3y ago
It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. 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?). 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?). Or maybe compare these web application sizes to mobile or desktop equivalents too (where it's surely easier to optimise amount of code shipped). 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.

shiomiru 3y ago

> What's the alternative? 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, ...

iamsaitam 3y ago
You're confounding using Javascript for web development and "loading megabytes of tracking code". They are not mutual exclusive, nor have anything to do with the development side of it. Advertising and tracking are a business decision, not technical one. 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.

xk_id 3y ago

> What's the point of it? What's the alternative? 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.