Tools affect how you think. If you have got a hammer then every problem is a nail. If you have got a screwdriver then you don't realise that it might be a chisel you need, or a tyre lever or a paint stirrer.
jQuery is a layer of extra stuff on top of javascript. It was great in the days before standards compliant browsers as it spared you from having to learn the quirks of every different browser and you could get on with the task in hand knowing that your code would work.
But this came at a price of not knowing how to do things with javascript. Javascript has changed. You can now actually select stuff pretty easily and do those animations with CSS instead of with some jQuery. HTML5 means you can use the native form validation things and you don't need to validate on the frontend with some jQuery code. Then when you submit the form you can use fetch instead of the once incredible jQuery ajax wrappers.
Sometimes well meaning tools that make everything easy are only any good if you know how the well meaning tool works. An analogy, a server with a 'cpanel' control panel. Great in principle but there is a sea of icons and you have to know how to do things the special 'cpanel' way. Which is fine, but if you know the command line and what to type on it then you are going to be done before you have found the icon in the intuitive interface of cpanel. Plus, if you don't know what you are doing, things are documented for doing stuff the command line way, they aren't if you are doing it with the special icons. The longer you spend mastering 'cpanel' the less likely you will learn the command line way and therefore not feel comfortable without it.
As mentioned tools are great but they affect how you think and how you solve problems.
So it is not a question of not being hip. We just don't need the arm bands and extra guard rails any more.
>So it is not a question of not being hip. We just don't need the arm bands and extra guard rails any more.
You say that, but the current state of the art is to use a package manager and a workflow with a compilation step to import packages with arbitrarily deep dependency trees just to do simple things like add numbers together or add whitespace to a string, and using frontend frameworks to do the same DOM manipulation JQuery was doing years ago, but with a virtual DOM abstracted over the actual one.
I agree with you in principle, but to me, everyone seems to be moving in the wrong direction, and as a result, the JQuery model (typically "include one library, maybe two for UI and another for the plugin") is starting to look sane.
Absolutely. UI via jQuery involves heavy use of method chains each having loops and possibly nested loops. There are more direct ways to achieve UI code that execute faster, have less code to maintain, and deliver less across the wire. Those are all qualities that can be objectively measured.
Conversely, my own code is battle tested and stable and is any code that is well tested, based upon the standards, and works across supported browsers. When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
> Conversely, my own code is battle tested and stable and is any code that is well tested, based upon the standards, and works across supported browsers. When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
It's less a justification for a large abstraction library and more a statement to its persistence since, what, 1997?
And what's wrong with loops anyway? What kind of programming are they teaching y'all that simple primitives are so out of fashion?
jQuery often breaks in IE, because instead of using a timer to determine long running code IE uses 5 million instruction count. Simple jQuery implementations would blow past 5 million instructions on load in a fraction of a second. I encountered this failure often when I used to work at Travelocity.
>When I read "battle tested" as a justification for a large abstraction library it sounds like you aren't testing your code thoroughly cross-browser.
Most developers nowadays only develop in and test in Chrome, but things still seem to work. Either cross-browser testing really isn't necessary, or whatever they are using instead of jQuery is doing the same work to patch inconsistencies between browsers.
> Most developers nowadays only develop in and test in Chrome
Fail. I have no sympathy for laziness. If you are getting paid to do this work this is a core responsibility. Worse is that it isn’t hard to get right.
Most of its functionality is built into every modern browser. As the 3.4.0 release notes observe, for example:
> "Now that many of these selectors have made their way into modern browsers, it’s almost time to say goodbye to Sizzle. [...] When we remove Sizzle, we’ll replace it with a small wrapper around querySelectorAll"
jQuery does have a nice interface. Fortunately, it's almost exactly the same as the native JS/DOM interface that every browser offers for free these days.
I'm confident that they would appreciate a pull request for your suggested updates. It remains a frequently cited resource for these sorts of discussions; if you feel it no longer reflects the status quo, it's important that you consider being part of the solution.
It's battle tested, stable, does what it says on the tin and has a sane and intuitive interface.
Is there any objective reason not to use it, other than it no longer being hip?