Oh yes. Everyday. Still love it.

>…Javascript document api via document.querySelector, and document.querySelectorAll

The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc).

>…smaller footprint libraries like lodash

jQuery is ≈30k gziped and most likely already cached from CDN.

>…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)

Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice.

If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.

This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.

1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

A single retina hero banner is larger than most JavaScript libraries/frameworks.

Ahem https://preactjs.com/

Preact [0] came before Vue [1].

[0] https://github.com/preactjs/preact/commits/master?after=605b... [1] https://github.com/vuejs/vue/commits/dev?after=5255841aaff44...

https://zeptojs.com/

https://github.com/fabiospampinato/cash/blob/master/docs/par...

In the last five years, the release schedule has slowed, so there was a convergence onto fewer versions in the wild, but at the same time, users were visiting fewer sites that used CDN versions (and fewer sites in general.)

Unfortunately not. There is no benefit to leaving your critical files on anyone else’s infrastructure: https://csswizardry.com/2019/05/self-host-your-static-assets...

Back then we decided it's just better to self host. Less things can go wrong.

Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.

Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.

While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.

If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework.

If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back? Not to mention JSX.

It all seems so crazy to me, but this ship has long sailed.

Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me.

Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.

The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.

I rather like Svelte.

But honesty requires that we recognize that Svelte also uses Webpack/Rollup + TS + Svelte etc etc.

I like the idea of Snowpack. But if A.svelte and B.svelte both use C.svelte, Snowpack has to do a lot of redundant work to provide A.js and B.js with Svelte.js and C.js all converted again and again from ts then baked into both A.js and B.js. That's a lot of server work and a lot of client work and a lot of network work.

So you still want a webpack or rollup or what have you to bundle and tree-shake and codesplit for production. I don't know why this irritates me more than running any of my other code through a compiler. But it always has.

Mileage will vary =)

Unfortunately it hasn't caught on, though it maybe be too early to call.

https://2020.stateofjs.com/en-US/technologies/front-end-fram...

Wait until Typescript is properly supported.

[0] https://svelte.dev/blog/svelte-and-typescript

I can't think of a single framework that does this, (its neigh impossible, actually, it'll just lock up your browser)

Svelte is cool, but this statement needs some serious proof

Also, what‘s bad about typescript?

If 400 people are accessing 10,000 static pages, don't use any js at all.

But we've been doing projects with millions of pages way before React :)

Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.

>Also, what‘s bad about typescript?

It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.

The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.

Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.

Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.

Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.

For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.

But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.

For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.

But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut.

As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.

The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc).

The script started out really small. I've slowly added more and more as I need more functionality for some projects.

https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

so... like jQuery?

I don't believe any major browser allows sites to share 3rd party caches anymore.

Previous HN discussion: https://news.ycombinator.com/item?id=24894135

edit: why the dowvotes? are we not allowed to share our experiences now?

I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch.

JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.

Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.

Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.

Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.

Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.

Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.

I'm honestly confused about why jQuery is considered 'bad'.

It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.

A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.

The lovely world of enterprise software.

By using Word as a viewer the email is broken right on delivery and users now complain "The email you sent me is broken!"

At least it's still better than Notes

IE, and now Edge, is a different business unit.

Not inexplicable at all. NIH doesn't only apply at corporate boundaries.

jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.

Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.

One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.

Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.

It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.

When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.

There's a current trend to complicate things with a JAM stack that really don't need to be complicated.

I've seen people propose something like

    [NodeJS/Ruby/PHP backend] 
      -> GraphQL API 
      -> React Frontend 
      -> static html

    [NodeJS/Ruby/PHP backend] 
      -> static html

For very small amounts, perhaps, but honestly, even then I think it has limitations. As an anecdote, about six months ago, I needed to add a couple of dynamic forms to a static site. The forms were a simple contact us, and a mailing list sign up form, and only needed to handle the states of Open->Submitting->Thanks|Failed->Open, while preventing double submissions, etc.

I wrote the first one in jQuery (site was already using it due to the theming), and making sure handled all the various edge cases, and fixing one bug didn't cause another was far harder and time consuming than it should be.

Out of frustration, I wrote the other form in VueJS, and hacked the whole form in about an hour or two. My take away was that anything involving state in jQuery can get overly complicated very quickly.

Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.

You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.

https://htmx.org/

I mean, all you really need is a Turing Machine, but they're not very pleasant to program.

Same thing with vanilla JS and jQuery.

Well, yes. Every JS library can be written in vanilla JS. The point of jQuery, React, etc. is to make it easier for the programmer to reason about what is going on while avoiding bugs.

I recently had to rewrite a bunch of vanilla promise-based code to use jQuery promises once I realized IE11 didn't work.

- The API is still more concise than what is built into the browser (Compare the number of lines used here: http://youmightnotneedjquery.com/)

- It is still useful for older browsers that might not support something.

- The API is burned into my brain, it speaks jQuery.

- If I have any issues, Google will usually surface how to use the API faster than the (standards compliant API * can I use it?)

I do use React for UI, but sometimes you have to interact with the DOM; in those cases for larger programs I find jQuery easier to read and write.

Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.

The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.

When I learned that it was simply a function invocation that returned a jQuery object so you could chain it, I was absolutely shocked about the simplicity of that statement.

Beginning developers sure like to project their cognitive insecurities onto programming. Or at least, I did :)

``` $('.container-element') .addClass('active');

// vs

document.querySelectorAll('.my-class-selector') .classList.add('active') ```

I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.

    document.querySelectorAll('.my-class-selector').forEach(el => el.classList.add('active'))

https://megous.com/dl/tmp/basic.js

1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platform APIs. That was before FF killed all the joy in writing userscripts for me, because I was no longer able to install and update them just by copying them to mozilla folder and had to invoke a lot of clicking ceremony to just get my 20 scripts or so from git into firefox past the webextension limitations on storage/access to mozilla folder.

So you need to be careful about writing code like that if you want to avoid jQuery.

Another jQuery advantage is pseudo-selectors which don't exist in CSS.

There are plenty of convenient one-liners in jQuery which will expand to plenty of lines in native API. That said, with modern API and JS features it's not that bad either.

This can bite at times, for example IE supports Array.forEach, but not NodeList.forEach

https://www.npmjs.com/package/request

Can't say I've ever heard that as an issue before..

Also I think the main point was there are so many better frameworks that manage the DOM better than jQuery as the need has evolved. I'll always have fond memories of jQuery but I don't see it as my go-to anymore, by a long shot.

  $ = document.querySelector.bind(document)
  $$ = document.querySelectorAll.bind(document)

  function $$(sel, parent) {
    var nodes = (parent || document).querySelectorAll(sel);
    return Array.prototype.slice.call(nodes, 0);
  }

So if your selector is wrong, you won’t actually know, because your code will pretend to run along just fine.

I personally consider that a con, not a pro, and one of my (many) reasons not to use jQuery.

If you just want to add simple interactivity to a web page, jQuery provides a really nice API to do just that. Sure it's not the ideal thing to build a whole SPA on, but it has its place.

In a world without jQuery every site / devshop uses their own little set of conventions and polyfills (analogous to macros) to add useful abstractions.

In isolation, these are neat. En masse though it means that each site has their own meta language (conventions) which have to be memorized before you can contribute to the code base. Languages like Ruby and Lisp suffer from this too: there are so many minute variants across code based that it becomes hard to truly view them as the same language. jQuery, in the context of JavaScript, is a standardisation track for all those little language additions.

Personally, I just use the native APIs. I don’t work with enough people across enough sites to benefit from standardisation. You will probably find a big overlap between proponents of jQuery and professionals — especially contractors — who work with many other people on many different codebases.

Ironically, http://youmightnotneedjquery.com/ makes a pretty good case in favour of jQuery.

If they just add $ notation, then there will be redundancy / inconsistency with existing api. Furthermore it will break / confuse apps which use jquery.

Then it's far easier to just include minified jquery into your apps when you want to use it, and you have more control about it's version, etc.

    ['map', 'find'].forEach(f => NodeList.prototype[f] = Array.prototype[f]);

    document.querySelectorAll('bla').map(el => whatever)

  ['map', 'find', 'filter', 'reduce'].forEach(f => NodeList.prototype[f] = Array.prototype[f])
  // this is for for..of, cannot be above 'map', 'filter' etc.
  NodeList.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator]
  document.querySelectorAll('span').map(el => console.log(el))
  document.querySelectorAll('span').filter(el => el.className === 'fc-black-500').reduce((acc, el) => (acc += el.className, acc), '')
  for(let p of document.querySelectorAll('p')) { console.log(p) }

    document.querySelectorAll('div')._.some(...)

Why replace what's not broken?

When I need a to write a small web service, I usually just grab a python micro-framework and do the work. Not much complexity and not a lot of setup required. When I need to do something more elaborate that needs structure because it will get extended over time, I will take my time to setup something like Django... but it would be too much unnecessary work do to that for small web services.

The same applies to front-end.

When I need a few quick HTML pages that need some quick DOM manipulation, I usually just grab jQuery and do what we have been doing for years. Whenever I know that something will get extended over time and needs structure, that is when I take the time to setup React/Redux and all the build scripts necessary to make it work.

Just personal preference, but I am sure I am not alone...

As for why I'm not using the native DOM api's...I could, but haven't gotten around to learning that syntax since I'm very used to jquery (being specific, if I want to do things that are more complicated than selecting an element + changing its properties, the native API is more complicated). jquery is just a nice default.

It's not el.parentNode.insertBefore(new, el) and el.parentNode.removeChild(el) days anymore.

I still see it used for file upload/download, as the fetch api doesn't provide a reasonable way to show progress if the channel is using gzip or deflate. The ajax functionality is also still popular for a compact way to deal with different types of errors (app errors vs connectivity errors).

But then, I'm not a front-end web developer, so I optimize for different type of projects.

> keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS

Not everything needs a whole reactive templating library. There's absolutely still a usecase for mostly-static sites to do imperative DOM manipulation.

The usecase for jQuery itself these days is dodgier, since as you point out most of its big features are native now. It should still help with browser compatibility (not necessary for modern-ish browsers, but many sites don't want to limit themselves to modern-ish browsers), its APIs are arguably still a little nicer in some places, and it does have a significant ecosystem of plugins so there's probably some value in having that stuff integrate together. But personally I would have a hard time justifying a whole library just for slightly nicer APIs unless I was doing something significantly complicated, and at that point I would just use React.

When you have a vast, mature ecosystem and a decade and a half of community knowledge to draw upon, even the most obscure use cases tend to have a precedent somewhere. Being able to jump right to a StackOverflow answer to exactly what you're trying to do is, in my opinion, a highly underrated feature of legacy web technology.

I won’t even speak of the ecosystem built on the above principles.

All I can say is that a 1-click install does translate to popularity :)

A ton.

jQuery is still holding up the client side code of a lot of projects I've worked on and doing a pretty decent job at it.

Sure they could be rewritten to not use it but there really hasn't been a business reason to do it.

Though I personally wouldn't use it on a new project moving forward that's for sure.

All the time.

> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.

The official replacements for the stuff jQuery does tend to be verbose and non-orthogonal, as compared to the much more unified and consistent API of jQuery.

It is not necessary to use jQuery when you build site but tons of tutorials on the web is using it so people does.

Plus wp-admin still loads jQuery for itself so it is in use even unnoticed.

Lots of other vanilla JS table plugins out there but I can't find one with all of those features that work when they are all on.

Oh yes. Very much so.

Granted I don't so much as use it as I fix it / change it.

Anything new is just vanilla as far as the legacy systems go. But those legacy systems pay the bills...

In my opinion using React / Redux combo for state management is a poor choice. So to each their own. The arguments like: everyone else including my cat does that do not make really it any better in my eyes.

Current browser support[1] isn't really _that_ great. I know it used to be, but I'm not sure that's a legit selling point these days. Not that it's bad, but I hear that argument come up a lot.

[1]: https://jquery.com/browser-support/

I've really forgetten how to do things without jQuery. If anyone knows a framework that is less verbose than jQuery please tell me!

I would not start a greenfield project based on it today, sure, but it is used by a truly staggering amount of sites today, so having it get updates in the form of security fixes and some additional functionality benefits a large part of the web.

WordPress ships with it, so using jQuery often doesn't require any extra footprint. I still prefer vanilla calls for admin-only code, but jQuery has better compatibility for user-facing pages.

The use case: a small CraftCMS-driven site using a bunch of long-lived jquery plugins and almost no custom JS.

Also, no need for transpiring or bundling.

It is wonderful.

I read, Ember.js would depend on it.