Which results in much less js code shipped and better perf. Browsers have caught up to (almost) everything jquery does. Thanks jquery, you served us very well!
I agree the API and the chaining are nice in some cases. And I agree that native JS is less pretty.
But I personally don't use it anymore since a while now. I either use React/Next + Redux if they are a good fit, or just plain native JS otherwise. JQuery doesn't solve enough of a problem (anymore) for me to be worth loading and adhere to.
If I do the latter then my code is often structured the same (per module).
- defining some utility functions
- setting up state and state-transformation / "top-level" functions
- getting the DOM elements (once)
- defining DOM mutations on those elements based on the state, usually call these "render" functions.
- registering event handlers on those elements which call the top-level functions and pass the new state to the render functions.
I know this is kind of a dumb/rigid approach, but it suits me well. There is not much obvious use for jQuery here. The only place where the nice chaining API would be useful are the DOM mutations (sometimes) but I haven't found this to be a huge deal.
As soon as I need to do more AJAX, inserting/removing whole Nodes/NodeLists, have more involved state management and policy then jQuery doesn't help anyways and a more sophisticated framework is more fitting (like React/Next + Redux).
It's debateable whether jQuery is a library or a framework. It's definitely at the frameworkey end of libraries of the libraryish end of frameworks.
But if you'll admit the terms get murky in the middle then I think it's not controversial to assert that a framework can depend on a library without it offending the gods.
So we're very quickly in the territory of "things reasonable people could disagree about" and quite far away from "glibly asserting that something isn't even up for debate".
