As noted by others, jQuery was essential in carving a path between the past of browser incompatibilities and the modern form of mostly reliable and evolving sta

As noted by others, jQuery was essential in carving a path between the past of browser incompatibilities and the modern form of mostly reliable and evolving standards. It was hardly alone - other libraries did their part, evergreen browsers are essential, and the list of people doing a lot of thankless work is long and unassembled - but it was nonetheless an essential piece. I want to clarify a bit about "JA Hate" though: Most of it stemmed not from JQ's limitations or age, but rather as a matter of architecture. While it's cool these days to smugly enjoy the options of vanilla JS, JQ hate was around before those standards were reliably implemented. JQ really stepped in when dynamic web pages (i.e. pages that modify their own HTML without page refreshes) were becoming a thing. AJAX calls were new (to most) and exciting. form validations that didn't require 2-3 seconds to load, etc. All made far, far easier by the APIs JQ had. BUT there were complications: JQ plugins meant that having multiple copies of JQ on the page tended to not work well - and that happened if you were mingling content sources. JQ didn't require it, but many coders would use the DOM to store data (JQ made it so EASY), which worked well short term but caused troubles. Example: If you have a list of items, with every other item shaded, and every item had some metadata in the HTML, and then you wanted to remove some items, what did you do? More importantly, when you wanted to restore them, where did it come from? If you were tracking everything in a JS variables and building the DOM, no problem, but if you were using the DOM to hold your data, you had issues. Even if you WEREN'T using the DOM to track your state, repainting all the DOM got expensive - a table of 10 items worked great, but a table of 1000 could bog down terribly. Ultimately someone would inherit (or create) a convoluted mess of JQ and blame JQ rather than the creator. Much of the JQ hate came not from JQ flaws, but the flaws of coding done in the face of JQ success (as has happened with so many languages/libraries/frameworks before and since). We've learned from those flaws AND successes though - querySelector() basically uses the sizzle syntax; modern virtual dom libraries deal with the DOM pains; be it React's Unidirectional flow or Angular's two-way binding, the goal is not to use the DOM to hold state; and every AJAX library out there tried for a better interface (arguably fetch() beat them all). We're still hashing out how to handle reusable pieces of non-static HTML, but there are many options. So congrats to anyone that doesn't need JQ, and no hate to those that use it if they strive to use it well. I can only hope to write something hated for the results of success that nonetheless leaves the world better off.