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.
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.
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?
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.
