For what it's worth, I do think this. It's easy to just drag another JS library into your code without thinking of how long it's going to take to load.
I don't doubt that there are junior web developers who don't know much better. But I don't really meet anyone who says that they just don't care about performance.
I see competent devs reach for libraries all the time when a simple solution already exists within the language. It's easy to feel like you're doing the right thing by not reinventing the wheel.
Areas I see this happening a lot in are anything dealing with file systems, HTTP request/responses, database connections, DOM/string manipulation/parsing/validation. The common theme among all these things is usually a lack of understanding of what the library/package does well enough to implement the specific use case needed.
> I don't doubt that there are junior web developers who don't know much better.
I just think it's very... puritanical the way that people bemoan the state of websites as a personal failing of web developers as a profession rather than the a result of what kind of deliverables their employers care about and are willing to pay for.
I think the web is currently terrible and I think modern web-development is to blame, but that includes the people behind the web-devs making the decisions that are being pushed onto the web-devs.
There are a lot of things to blame for the current state of the web, but ultimately the current practice of web-development (and whatever behind-the-scenes processes that involves) is clearly the biggest reason why.
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.
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.
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.
This is one of the reasons I got out of actually writing software as a profession. My interests as a developer rarely aligned with my employers' business goals. I got tired of the whole "Cram features as fast as you can, quality be damned" mode of development and bailed.