Hacker News Reader

youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems.

I spent all of five minutes glancing through the example list and noticed their `replaceWith` doesn't provide the functionality that jQuery offers -- it doesn't take into account event handlers bound to DOM elements. Also, their `extend` does a shallow merge, not a deep merge. Furthermore, the YMNNJ examples are often far more verbose and less expressive than the jQuery examples.

I don't particularly understand the rush to rip jQuery out of everything. It seems like a lot of people are doing it just because it's the trending thing to do. There are some things that jQuery does very well -- even in today's world where modern web dev is dominated by SPA components.

I'm the maintainer of https://github.com/elliotnb/observable-slim and https://github.com/elliotnb/nimbly -- the latter of which is an SPA component framework whose core requires jQuery. It uses jQuery to update DOM nodes with `replaceWith`, merge deeply nested objects with `extend`, among other things. Nimbly components are not required to use jQuery -- only the framework core uses it. Aside from the eliminating the extra 69KB footprint from adding jQuery slim min, I don't see any reason to rush to rip jQuery out of the Nimbly core. On the contrary, using jQuery helped us get the framework built faster and helped us keep the code expressive and easy-to-follow.

> youmightnotneedjquery.com is often held up as an example of why jQuery is obsolete, but if you look at the examples a bit more closely, you'll notice problems.

Surely that's their entire point? They provide the link as evidence that

> it's intellectually dishonest to claim that all of the non-jQuery techniques are as ergonomic to implement as jQuery idioms

Not as evidence that you don't need jquery.

You could be right... but you're definitely the first person I've seen suggest this. It would be a Sixth Sense twist, given the domain name.

youprobablystillwantjquery.com is still available at the time of this writing.

I took masklinn's comment to mean that your point in sharing the youmightnotneedjquery.com was to show evidence of problems using vanilla JS instead of jQuery, not that that's the point of the site existing.

The site has plenty of examples of vanilla requiring writing multiple lines compared to one jQuery line, which I took to be your point regarding "ergonomics." EB66 seems more focused on a subtler point regarding the site, that their vanilla examples don't do everything the jQuery version does.

I like your reading better than my own. I've re-read a few times and it's still written in an ambiguous way, so I don't feel completely silly.

> Surely that's their entire point? They provide the link as evidence that.

I'm not following your point. The point of YMNNJ is that you can use their examples to quickly replace bits of jQuery code. I've identified that a few of their examples (possibly more) are not equivalent replacements -- demonstrating that jQuery is indeed needed.

Your second quote doesn't come from me. It's misleading the way you quoted it in response to my post.

> I'm not following your point. The point of YMNNJ is that you can use their examples to quickly replace bits of jQuery code.

That doesn't mean that's how the person you responded to uses it.

> Your second quote doesn't come from me.

The second quote comes from the comment you responded to, I'm pointing out that its author specifically used YMNNJ to demonstrate that not using jquery can be significantly less convenient and ergonomic than using it.

For reference, jQuery is bigger than AngularJS - let that sink in.

Your users likely already have jQuery in their browser cache, given it's loaded from one of the public CDNs.

Which version and which CDN? Assuming the user's cache for a non-archival product sounds dubious.

There are only a handful of major CDNs, and jQuery has been at the same version for a very long time.

This gets posted a lot but there are so many versions of jquery on so many different cdns that very rarely is it the case. I saw some research on it and it was in the single digit percentage of times.

This is a bit disingenuous without actual numbers: jQuery minified is 83 KiB, 30 KiB transferred with gzip. The new slim version knocks that down to 70 and 24 KiB, respectively.

For almost any website that has actual use-cases for it, it's not going to be the data bottleneck. Plus most websites have way more severe bloat elsewhere to worry about

> I'm not exactly claiming Carmack-level jQuery proficiency, but comments like yours make me wonder (optimistically) whether you've forgotten all of the amazingly useful things that jQuery can do. Ajax, selectors and CSS transitions are the Nickelback of creative possibility.

It's been several years since I last used jQuery, but what are those other useful things that are hard using Vanilla.js? (Legitimate question, not being sarcastic here)

Dom regex selectors. jQuery has extremely powerful and smart ways of retrieving elements that way.

I feel as though that if you need regex selectors, there is something wrong with the structure of your HTML.

Can you tell me which use case you would need to do this? I don't think there is anything wrong with this functionality, but it seems like if you needed it, that your HTML is needlessly complex.

I'm not the parent poster, and I'm not sure if these are the regex selectors they had in mind, but nonetheless.

An example use case: the person writing the HTML ≠ the person writing the selectors. Browser extensions like Stylus, for example. If the HTML author did not bother to add a specific class you need, you have to resort to ugly methods.

In fact, this is a scenario I deal with regularly. I have a Chrome extension for video download sites that scans the current page for metadata (title, performers, release date, etc.) and decorates the download links with `download="…"` attributes, so that I can download a file with a properly formatted filename. I manually adapt this extension to every site I need, and quite often I need things like `a[href^=/model/]` † to distinguish links to performers from other links to get their text content. It's clearly not a situation the site authors worry about, and that's fine as long as I have a way to do this myself.

† This particular selector can be done without jQuery if you don't care about backcompat. In browser extensions, you usually don't. But it's still an answer to your question about when such selectors are needed.

---

Since I'm talking about this, that same browser extension can demonstrate some other complications brought on by React and CSS-in-JS:

1. CSS-in-JS turns class names into unreliable gobbledygook, so extracting metadata means more regex selectors and abominable DOM hierarchy selectors (`section>div>div:first-child>div` because nobody bothers with semantic <h2> or even .title anymore).

2. React makes DOM elements vanish and reappear instead of just hiding them, so that `download="…"` attribute I want to add has to go through a MutationObserver instead of just running once on page load.

`document.querySelectorAll('a[href*="model"]')`

Your point #2 is one of the main reasons React is far-less creatively flexible than DOM manipulation. I'm surprised that this doesn't come up far more often.

Great question! I hope that I can give a good answer. When I stopped to think about how to answer, I found myself challenged to compose my thoughts because I have to unpack specific features from the context I use them in; the context frequently informs the way I use various patterns and jQ functions together to achieve an end result.

However, there are some jQuery functions that I use all of the time:

$.closest() and less frequently, $.parentsUntil()

Not just $.siblings() and $.next()/$.prev(), but $.nextAll() and $.nextUntil()

$.getJSON()

$.toggleClass()

Deep extend via $.extend(true, {}, objA, objB)

jQuery's custom event triggering is A+

$.delay()

$.end()

Consider this a solid starting point for further exploration.

Great answer likewise! Some of those are really cool indeed!

Deep copy/deep extend is a must in every programming language ever. I have no idea why 90% of the environments I ever programmed with make it so damn hard to deep copy data. In javascript it is kind of comical. [1]

Traversal utilities like closest/parentsUntil/nextAll/nextUntil is something I miss in most standard libraries. No for DOM manipulation, but for traversing lists and such. Until/while idioms are par for course in imperative contexts but I miss them in functional programming contexts. Not that they're that hard to implement with a couple lines :)

Delay is further proof that the jQuery API design is nothing short of amazing. I wish more APIs were like that. The only thing that comes close to me, albeit in a completely different domain, is LINQ.

I had no idea about End. That's point-free programming black magic. [2] Love it.

[1]: https://stackoverflow.com/a/5344074

[2]: https://en.wikipedia.org/wiki/Tacit_programming

Building on what you said, I would love to see more powerful node traversal functions make their way into every environment I work in. It's something worth making a push on. Moving around a tree can be a joy, and it unlocks many solution domains that might not cross your mind if you're not thinking about them.

One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler.

End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining. It'd be even better if ES supported Ruby-style send syntax eg. array.map(&:to_s). And yes, I put it last because I was going for clever.

You know what drives me even more crazy than ES' lack of deep copy/extend? How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.

> One traversal mechanism I'd love to see but I've never seen implemented coherently is... given my relationship to ancestor X, iterate through all my antecedent peers under x. This would make processing some kinds of structured data far simpler.

That sounds really simple to achieve with with a (lazy) function that returns a list containing all ancestors of a tree, and then a "until" or "up to" function that returns everything from that list until a certain condition is met.

Those are things that should be included alongside Map and Reduce :)

> How is it possible that ({k: 1} === {k: 1}) is false? I find this to be maddening. Thank goodness for lodash.

Oh, I strongly agree. And lodash should be the standard library of the language. Not only of Javascript, but most languages out there.

> End really is one of those hats-off bits of magic, and it's one of the first things that come to mind when any of the frothing haters pen statements that preclude anything good coming from method chaining.

About End (and point free style in general), I understand why people might dislike it, but then again, I think it comes down to familiarity. After ten years of exposure to LINQ, Haskell, underscore/lodash and FP in general I also find it super hard to follow code that uses for/do/while in overly clever ways (my own C code comes to mind).

I think I find it easier to see code as a "graph" rather than assigning something to a temporary variable, and that's what End allows me to.

Your object equality example is neither maddening nor unique to JavaScript imo

$ irb2.4.1 :001 > ({k: 1} === {k: 1})

=> true

I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and logical not be maddening? When does the maddening kick in... before or after I have to install lodash for comparing objects?

Are you busting me on semantics? Do I literally have to check into a mental health care facility after not being able to natively compare simple ES objects to satisfy you?

I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.

You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug.

And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter:

a = {k: 1}

b = {k: 1}

a == b # true

a.object_id == b.object_id # false

Of course, this is a lot of typing, so Matz also gave us:

a.equal? b # false

Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.

Don't forget some of the higher-level utilities like $.Deferred (which imho is still easier to use than promises) and $.Callbacks . Those two were always criminally underrated and underused imho.

> http://youmightnotneedjquery.com/

The examples in the site already look quite outdated. We now have `fetch()`, `.attachEvent` is all but dead, plus all the ES6 features like arrow functions, destructuring, spread... and reactive UI means you'll rarely, if ever, need to call DOM tree modifying methods yourself.

The best part, "Reactive UI" being a paradigm, you have many other options besides React+JSX, for example https://github.com/jorgebucaran/hyperapp. At a fraction of the size of jQuery, which one is the 'monster'?

It might be the case that how I use javascript is Nickelback-level coding; however, it pays the bills and to be frank, I don't miss using jQuery. I don't need my day job to validate my creativity.

I don't use React/Vue/Flavor-of-the-month UI library for my day job; however I don't use jQuery either.

I am not trying to shit on what can be accomplished with it; however, I debug a lot of code that adds it in where ES6/vanilla javascript does the same thing. I guess I prefer verbose javascript over using jQuery... not trying to knock on it, but it might be worth looking at other tools for the long term.

Edit: To be clear, I am not advocating to rip out jQuery fron existing apps. In a lot of cases, jQuery and jQuery plugins are helpful, but most of the code that I am paid to debug ends up being rewritten in vanilla js because I feel comfortable using that. I stopped using jQuery a while back because I opted to use a UI library a while back and worked hard to avoid jQuery ever since even though I don't use UI libraries at my current job.

Use whatever tool floats your boat and doesn't piss off the rest of your team. It's possible to ship spaghetti code in any flavor you want. I happen to (currently) work on things where the level of complexity of the UI is simple enough to use vanilla JS and not need a UI framework.

And what do you do about accessibility? Working with jQuery makes sure you have a baseline default that's always accessible. Also, jQuery is not backed by a terrible organization with a questionable record, even evil intent.

I love jQuery and will switch for vanilla JS only when it's okay to do so, like when support on old browsers isn't that much of a priority.

I use vanilla js for WCAG compliance; however, I only need to focus on IE11+ for most work because TLS 1.2 support is mandatory for the sites I support.

I don't understand why this comment was down-voted; this is a completely reasonable perspective. Plus, it reminds me that I'm lucky in the projects I typically get to work on, that they still allow for creative coding in many moments.

If coding is your day job and you work on corporate applications, it's likely that you're on a team big enough to start discussing how things like React might be necessary and valuable.

If you're building a linear CRUD application, you probably still don't need Reactive frameworks, but you're in the right ballpark to be talking about it. Otherwise, history will not be kind.

> Ajax, selectors and CSS transitions are the Nickelback of creative possibility.

And the jQuery Ajax methods are super-handy. POST with the fetch API is long-winded; while the jQuery promise-handling sucks, it was enough to make me use $.post() in the current project.

> while the jQuery promise-handling sucks

You don't need to use that API. Deferred is compatible with Promise, you can just simply `await $.post()` etc.

See last section of http://api.jquery.com/jQuery.Deferred/

Awesome thank you, I didn't know this!