They do care, they've just gotten used to bloated software and therefore don't have high expectations. I submit that this is indicative of our failings as an industry.

Not a single non tech person I know has ever complained about the size of an app on download. Not one. They don't even look at the size its not relevant to them. They want to do something that some app enables. Besides how well it lets them do it no one cares about the size until they are out of space, which is usually because they have so many videos and photos stored.

You're kidding yourself if you think the average person looks at the size of an app.

The only case I can think of is mobile apps on slow connections. Even on a fast connection waiting a minute to download an app seems a bit annoying.

I don't see much evidence that they care until it notably impacts their free disk space, which at current storage sizes is when you reach about 1GB (or even much later, depending on your target demographic)

> Very few users care at all about the size of an app

That depends on the target audience. IME the target audience of console/CLI programs are more likely to care about size. CLI apps tend to cater more to power users. And many users do definitely care about resource usage, and smaller size apps do in fact tend to use less resources.

All users definitely care about performance. A fast app feels nicer. Smaller-sized software tends to be faster. Weird correlation? I think not.

I agree. Your points about size and speed are valid.

I think what made me defensive was the implication that these CLI libraries can be easily replaced with some small hand-coded solution. This particular library adds color coding, a structured help message based on the configuration, and some building blocks for DI, etc. Getting that stuff right in a hand-coded solution that isn't thousands of lines would take most developers a lot more time and effort.

> these CLI libraries can be easily replaced with some small hand-coded solution.

If that was your takeaway from what I wrote that was definitely not my intention. I do not think that.

I am sure several of these libraries are well-crafted, the developer(s) behind them might be excellent and have cared a great deal about performance and did their best to optimize every function. My point was more: people tend to pull in a lot more functionality/features than they need, and the few things you do need, it is often better to write yourself (you may disagree again).

This will often give you the most optimized solution, and the one with the smallest binary.

In another HN thread, someone mentioned Unity and the size of the binary required just to display a pixel, a square, or whatever their example was--although their example was not an apple-for-apple comparison and not quite fair, the point still stands, that Unity is a general solution, and if your only requirement is drawing a pixel, of course Unity is not the correct solution.

I deeply care about performant and small apps. I definitely don't want to have 100GB+ games on my disk, 150MB+ Electron based messaging apps, Docker images with 1GB+ node_modules/ folders, or even worse, Docker images with 600MB+ of binaries (looking at Terraform and it's plugins.)

However, I care even more about having apps/tools that help me achieve the desired goals, in an easy, clear, and elegant way.

If having bigger apps means that developers have more time to implement or improve features, and solve bugs, I'm all for it.

On a tangentially related note. Apparently the huge game sizes are on purpose these days. With downloads and storage so fast and cheap the developers ship assets in a format optimized for the in-game experience instead of space savings. Better to use more space and reduce the initial startup and loading times.

Contrast this with a game like Detroit.. It took my system(5700 XT and 3950x) what seemed like nearly 30 minutes to arrive at the menu screen due to having to compile all the shaders and who knows what else. I'm sure there were other considerations there, but still..