HN Explorer

73 comments

[ 3.1 ms ] story [ 66.6 ms ] thread
rationably
Unbelievably, still supports IE 11 which is scheduled to be deprecated in jQuery 5.0
b3ing
Nice to see it still around and updated. The sad part is I guess this means React will be around in 2060.
MarkdownConvert
Long-time user here. It served me well for years, though I haven't really touched it since the 3.0 days. Glad to see it's still being maintained.
netbioserror
I was surprised that for most of my smaller use cases, Zepto.js was a drop-in replacement that worked well. I do need to try the jQuery slim builds, I've never explored that.
karim79
Still one of my favourite libs on the whole planet. I will always love jQuery. It is responsible for my career in (real) companies.

Live on jQuery! Go forth and multiply!

alexchantavy
I love tech hype cycles haha, I remember when you got laughed at for using jquery and now it seems everyone’s burned out and happy to go back to a simpler time
jusonchan81
The first time I truly enjoyed web development was when I got the hang of jQuery. Made everything so much simple and usable!
blakewatson
Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks.

https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...

davidzweig
MobX autoruns happily call jQuery functions.
augusto-moura
In ol'times people used BackboneJS[1] for that purpose. And surprisingly enough, it is still being actively supported[2].

If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp

[1]: https://backbonejs.org/

[2]: https://github.com/jashkenas/backbone/tags

insin
This is still the way - jQuery or not - for UI where you can't/don't want to use a component library. I use the same approach for my browser extensions, both for page scripts and options pages. Writing features so you update state then re-render also means you get things like automatically applying option changes live in page scripts, rather than having to reload the page, for free. Just receive the updated options and re-run everything.

Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a <form> wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements (<body> classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.

My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.

My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.

    <h3 id="communityNoteHeading">
      Readers added context they thought people might want to know
    </h3>
    <div>
      <textarea id="communityNote" placeholder="Note" rows="5" style="width: 400px"></textarea>
    </div>
    <button id="communityNoteCopyButton" type="button">Copy</button>
    <script>
      communityNoteCopyButton.addEventListener('click', () => {
        navigator.clipboard.writeText([
          communityNoteHeading.innerText,
          communityNote.value,
        ].join('\n\n'))
        communityNoteCopyButton.innerText = 'Copied'
        setTimeout(() => communityNoteCopyButton.innerText = 'Copy', 1000)
      })
    </script>
kccqzy
But if you do that, you'll also find it easy to write plain JS without any libraries or frameworks. document.querySelectorAll is just slightly more verbose than $(). I have personally done this: for simple web pages, I just eschew all dependencies and write plain JS.
gocsjess
jQuery is v4 now, but a lot of sites esp. wordpress still have 1.11 or 1.12 and only uses them to either doing modals(popover), show/hide(display), or ajax(fetch).
NetOpWibby
I remember being scared of jQuery and then being scared of vanilla JS. My, how time flies.

Incredible it's still being maintained.

giancarlostoro
Same experience I had! Impostor syndrome is a pain.
indolering
I love that they support ES6 modules, Trusted Types, and CSP! The clearing out of old APIs that have platform replacements is nice to see too!
madduci
This is huge. jQuery is still my way to go for any website requiring some custom interaction that isn't available in vanilla js.
chao-
I cannot express how much I admire the amount of effort jQuery puts into their upgrade tools.
phatskat
I’ve found similar quality in the more recent Storybook upgrade tools - clean CLI wizard, clear error messages, and it does a good job of examining your setup and letting you know what it can and can’t upgrade automatically, with clear instructions on the parts you need to handle yourself.
maxpert
jQuery is the last time I felt a library doing magic! Nothing has matched the feelings since then.
yread
Hmm maybe i can finally move on from 2.x
ulrischa
I still love the simplicity a ajax call can be done in Jquery
gethly
jQuery was peak JavaScript.

Good times, I'm glad it is still around.

flomo
Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?"

Anyway, jQuery always did the job, use it forever if it solves your problems.

lrvick
Everything I ever used jquery for 15 years ago, I found myself able to do with the CSS and the JS standard library maybe 10 years ago. I honestly am confused when I see jquery used today for anything.

Is there still anything jquery does you cannot easily do with a couple lines of stdlib?

hypnot
It's amazing how much jQuery is still used today. Even on modern websites you can often find it included (browser devtools -> jQuery in the console, and see). And not just on hobbyist sites, but on serious company websites and their web tools as well.
johanyc
is there any reason to use jquery if you've never used it before
thunderfork
Generally speaking, no, since a lot of what it does is now available natively, the odds that you'll need something from it are much lower.

There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.

hu3
if you need to sprinkle interactivity, jQuery is much more approachable than spa libraries like react.

maybe use Vue or something like mithril which doesn't require build. But jQuery is short and easy to grasp.