Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.

Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.

Frameworks are simpler to implement and maintain, that does not make them better for users.

Are JS frameworks really easier than your good ol' fully server-side rendered websites? I doubt that. There are costs for everything, both for using and _not_ using JS. It's silly to think that only using JS adds a cost and nothing else. That's just tunnel vision.

"I did autocomplete using a few carefully crafted lines of code"

Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs.

Not that they have to be stupid, it is just they think differently.

If they were really carefully crafted, then they likely can be carefully repackaged into a solution that could be included in those 10 different places with zero - or close to zero - runtime overhead on the code sharing mechanism.

But it takes actual thinking - and care - to do that. Something that seems to be in short supply with the current web trends.

Users don't care about development. Sure, for us frameworks are great, for them the trade offs look far worse.