Hundreds of lines of ugly vanilla JS which duplicate jQuery features which aren't as well tested and probably don't handle all the edge cases.

> On the web, user experience should really be a higher priority than developer experience.

Those aren't disconnected. The more time I spend on technical implementation details, the less time I have to think about UX and/or implement things that improve UX.

If you're not seeing jQuery - as with every third party library - as something that now needs a mitigation plan in case it ever vanishes, and a security monitoring process to keep up upgraded, you're doing it wrong.

Why do I need a migration plan? I have jquery.js saved on my disk; that's never going to vanish, and it's not going to stop working if upstream decides to stop supporting it. And if I discover a bug then I can just fix it myself, just like any code saved on my disk.

jQuery rarely has security issues anyway; and the issues that do exist are usually low-impact. It certainly won't have any more than any code I'll write myself.

You just have to chose the right tool for the job and the limitations. You get something in return for doing the extra work and you get something in return for glue coding some libs. Also keep an eye on the experience points.

If your website has two non thumbnail images in it, the 30KB library is gonna become a rounding error in the load time

if the 30KB library is already cached because everyone else is using it too, then isn't it technically smaller than however many hundreds of lines of code you had to custobuild?

Most modern browsers don't really have global caches any more, and it's now all partitioned per-origin.

I do agree 30k is hardly worth thinking about.

I think they are referring to loading it from a global CDN.

Yes, those aren't cached globally any more.

https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp...

https://developers.google.com/web/updates/2020/10/http-cache...

Thanks, I didn't know that!