Rather than "lazy" or "don't know", how about:
- it's fast enough
- have other priorities (security, stability, usability, functionality)
- optimize developer time
...
It's fast enough for people with as good computers and Internet connections as me, who are also employed at the same company as I am, and so do not use anything but the product on their computer at the same time.
> optimize developer time
Saving 1h for a developer for each 30min wasted over the lifetime of the application * number of users. Yeah, that scales right. Electricity is free too.
If improving performance is not a significant concern to your customers or benefit to you, further optimizing performance should probably not be a significant concern for you.
Your time is the least scalable thing you've got - you're not getting any more of it.
The problem here is lack of effective feedback on the market. You may be writing your application totally bloated, and due to the nature of software, you might not notice any significant impact on your business. It turns out that your application may be lagging just enough to make it unusable for the 1% of your userbase that has shitty connection... that's basically an accessibility problem.
But then that "accessibility problem" actually impacts your customers too, just not in a way most of them can tie back to you. It's your app, plus that other app, plus that third app, and suddenly their stupidly powerful[1] computer becomes sluggish, and they can't get any work done.
Performance is commons. Unless you're writing bare-metal embedded, your software is not running alone on the machine. By producing bloated code, you're implicitly taking away your users' productivity beyond what you could with little extra care. It's something that I try to keep in mind when writing software, too.
(Also, RE developer time tradeoff - people seem to not appreciate how software scales. If you save 100 man hours of development time at the expense of 1h per user over their whole use of the application, with 1M user you just wasted the world 1Mh - 100h = 999.9k man hours. Something to keep in mind, too.)
Related: http://idlewords.com/talks/website_obesity.htm.
--
[0] - It's usually entirely possible to write code both fast and clean, if you don't overdo abstractions. As a bonus, the code is usually simple.
[1] - Compared to what they had 5 years ago. User-facing software seems to be not gaining useful features, but rather constantly losing them. And yet it becomes only ever slower, for no actually good reason, just accumulation of bloat at every level of the stack.
Also, you fail to consider the opportunity cost of developer time. It's not free. Your business needs you to do other things. Also, like GP said, there are factors to performance beyond payload size. Do you actually develop web applications for a job where someone else decides the priorities?
Yes! But the current trends around software - and in particular web stuff, both in-browser and in-browser-but-pretending-to-be-native - very, very far from that point.
Look, I know that business has its priorities. But I have a right to dislike a business based on its priorities, and I believe chasing ultra-short-term gains by resorting to shitty engineering is a bad thing, and I do avoid using products of such companies, and I do call it out when I see it. Ultimately, business priorities are determined by the market, and I'm doing what little I can to create market pressures towards user-respecting solutions.
And yes, I've been doing webdev as a regular employee, and I always pushed against both needless inefficiency and user-hostile "features", with quite a good success.
Maybe you can share some advice about how you get your boss or PM to care about performance. Because I've tried your arguments, and it's not like by explaining the amortized cost of performance I'll get an extra week or sprint to improve performance.
