Haha, I remember when that site was released, and a few of our developers jumped right on it without actually reading the text - namely the second paragraph.
> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.
Back then, you were 100% correct that if you were writing a library that you intend to use in other places, having jQuery as a hard requirement was a bad idea. However, one developer managed to convince their PM's to completely strip out jQuery for an upcoming project, despite the fact that this website was for a major charity that had huge accessibility requirements AND required legacy browser support. The devs on that project learned a ton about vanilla JS, but that project was an absolute disaster.
We did get a solid library out of it, though, and at least that didn't have jQuery as a dependency!
That's more telling about problematic mechanics in your org than about jQuery itself.
Did that convincing developer have more influence than the rest of the team? Why the PM was involved in implementation minutiae?
From what I've seen people tend to complain about office politics usually when they don't grok them. The not grokking part is often a choice stemming from a conviction that code monkeys > managers because "engineering". Following your example, who then has more influence over technical decisions? (at least in your somewhat disfunctional org?)
At that company (small agency), at that particular time, the structure was flat, and this was isolated to a project he was leading. It was raised in a developer meeting, where I said the point was that libraries shouldn't have hard dependencies, not that (in 2014) we should be ditching jQuery and writing vanilla JS, especially on projects that needed legacy browser support. He ignored me, and the project ran over by months and causing the company to make a loss.
Company issues aside, he wasn't the only developer to not RTFM at the time, and the site was shared across the web by people calling for the death of jQuery when it still had a very legitimate use.
It is a little irritating when libraries that really shouldn't need jQuery had it as a dep. I don't mind using jQuery, but I'd rather not add it to a project just as a dep.
> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.
Back then, you were 100% correct that if you were writing a library that you intend to use in other places, having jQuery as a hard requirement was a bad idea. However, one developer managed to convince their PM's to completely strip out jQuery for an upcoming project, despite the fact that this website was for a major charity that had huge accessibility requirements AND required legacy browser support. The devs on that project learned a ton about vanilla JS, but that project was an absolute disaster.
We did get a solid library out of it, though, and at least that didn't have jQuery as a dependency!