> Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage.

I don't understand that sentiment ... Of course you can "manage" without JQuery. JQuery itself doesn't use JQuery (D'oh) and somehow it can do all these things, so it is possible. The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations of <whatever> in each browser version, but can just use one lib call and be done with it.

JQuery to me is like using a car instead of running to another city. Yes, I could run, but why would I do that ..?

jQuery to me is like riding a bike with training wheels attached after you've been riding for ten years. You don't need them, but unless you try taking them off you'll never know that.

Browser incompatibilities are basically a non-issue these days for 95% of projects. Animations etc are far better done with CSS than jQuery (particularly when it comes to hardware acceleration). The Fetch API works in every browser. So on and so forth.

I think the OP wasn't suggesting that "managing" without jQuery is difficult. Certainly, I can say that I haven't touched jQuery in years and haven't looked back once. There's nothing I miss.

> jQuery to me is like riding a bike with training wheels attached after you've been riding for ten years. You don't need them, but unless you try taking them off you'll never know that.

Why even use wheels when you can reinvent them? I'm not saying there are no reasons to go "bare metal", but satisfying your developer ego is not one of them. Unless you need every inch of performance or control, jQuery (or alternatives) is probably the more reasonable choice.

Why would it be the reasonable choice when it was created to solve a problem that largely doesn't exist any more?

jQuery wouldn't be created today in anything like its current form. It still lives on largely because of inertia. Using the APIs provided by the browser is in no way reinventing the wheel!

There is now a whole generation of FE developers for whom "JavaScript" is synonymous with "JQuery", as evidenced by endless questions on StackOverflow which use the terms interchangeable.

I agree with this sentiment wholeheartedly.

A lot of the commenters here have a very old school view of jQuery. They seem to believe that if you're using jQuery, then you must also be employing manual DOM manipulations, manual state management, etc.

You can implement modern component-ized front-end architecture while still using jQuery. My company built an in-house front-end framework heavily inspired by React and Vue. But instead of abstracting away from the DOM, we've embraced the DOM by utilizing DocumentFragments for highly performant rendering. When our components render, they return regular ole HTMLElements.

The components built using our framework work with or without jQuery. No manual DOM manipulations, one-way data binding, sane state management, templating, child components, state triggers, etc. A lot of us use jQuery simply because we prefer it's compact and expressive syntax.

Because the wheels are proprietary and full of quirks. For instance, $('.foo') returns an array of jquery objects and not HTMLElements that you can act directly upon using the standard API that was made for replacing it.

>The Fetch API works in every browser

As long as you're using recent versions. The whole point of jQuery is that you can write some code and be sure that it will run correctly in older versions of the browsers.

That's not the whole point of jQuery, it's just one advantage.

Well XMLHttpRequest has support going back to IE7.

> The Fetch API works in every browser.

No it doesn't.

> The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations

Sure when jQuery was released in 2006, but browsers have had 12 years to improve their compatibility, and they have. Javascript has also had 12 years to improve and simplify its api, and it has.

Your analogy was perfect for jQuery 2006 but in 2018 its more like buying a car to drive around the city or you can just take an Uber, you don't have to walk anymore.

Tell that to those enterprise customers holding to IE 11, not allowing Chrome and doing their own timely releases of FF ESR.

Where I work we only just upgraded to IE11 - it was a decent-sized project, involving a lot of people and manhours.

I really wish we'd of just ditched it and moved to Chrome or Firefox :(

So you would have a decent sized project involving lots of people and manhours, but without support from your vendor?

If someone is developing web applications in such a way that they need support from their browser vendor to make them work properly ... they're doing it wrong.

I was assuming that the upgrade was more of an IT thing, that all the company computers are now on IE11.

Yes, that's correct.

We have a portfolio of hundreds of applications, and needed to make sure every one worked OK on IE 11 before upgrading from IE 9.

Also don't forget mobile browsers. I ran into a strange problem where Samsung's "Internet" didn't support something and could not find any online mention of this fact.

(I wish I could remember what it was. Perhaps an array method).

Haha, I remember when that site was released, and a few of our developers jumped right on it without actually reading the text - namely the second paragraph.

> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.

Back then, you were 100% correct that if you were writing a library that you intend to use in other places, having jQuery as a hard requirement was a bad idea. However, one developer managed to convince their PM's to completely strip out jQuery for an upcoming project, despite the fact that this website was for a major charity that had huge accessibility requirements AND required legacy browser support. The devs on that project learned a ton about vanilla JS, but that project was an absolute disaster.

We did get a solid library out of it, though, and at least that didn't have jQuery as a dependency!

That's more telling about problematic mechanics in your org than about jQuery itself.

Did that convincing developer have more influence than the rest of the team? Why the PM was involved in implementation minutiae?

From what I've seen people tend to complain about office politics usually when they don't grok them. The not grokking part is often a choice stemming from a conviction that code monkeys > managers because "engineering". Following your example, who then has more influence over technical decisions? (at least in your somewhat disfunctional org?)

I think you're reading into it a bit too heavily.

At that company (small agency), at that particular time, the structure was flat, and this was isolated to a project he was leading. It was raised in a developer meeting, where I said the point was that libraries shouldn't have hard dependencies, not that (in 2014) we should be ditching jQuery and writing vanilla JS, especially on projects that needed legacy browser support. He ignored me, and the project ran over by months and causing the company to make a loss.

Company issues aside, he wasn't the only developer to not RTFM at the time, and the site was shared across the web by people calling for the death of jQuery when it still had a very legitimate use.

It is a little irritating when libraries that really shouldn't need jQuery had it as a dep. I don't mind using jQuery, but I'd rather not add it to a project just as a dep.

Absolutely. In the case of libraries it was absolutely solid advice.

Sadly, a lot of people didn't actually read the site, and they decided that jQuery was evil and shouldn't be used on websites at all.

It is not about the possibility. We can achieve anything with native browser's APIs without custom/polyfill layers these days.

Point is:

$('#somediv').removeClass('class-to-be-removed')

is so much better than

document.querySelector("#somediv").className = document.querySelector("#somediv").className.replace(/\class-to-be-removed\b/,'');

Broadly speaking I agree with you, but even IE11 supports classList so the "native" version of your bit is really

    document.getElementById('somediv').classList.remove('class-to-be-removed')

Where the native APIs fall down is that

1. they tend not to be chainable/expression-oriented, you can't just `classList.add('foo').remove('bar').toggle('qux')` because the first two methods return `undefined` and the last one a boolean

2. they don't support set-oriented operations at all, it's a chore of manual iterations

Spot on! Those are probably the two most important blunt-sides of native APIs.

The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days"

I'd be happy if there's a jquery like polyfill library for DOM manipulation, but again - why not just custom jQuery builds and sizzle.js instead of re-inventing jQuery?

P.S I'm not sure IE11 supports classList. Source: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

> P.S I'm not sure IE11 supports classList. Source: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla....

It provides basic support for classlist, add/remove/toggle exist and work as you'd expect. It does not have complete supports of all bits of the API:

* it doesn't support the second argument to toggle so you have to use a conditional/ternary with add/remove

* it doesn't support passing multiple classes to add/remove

* it doesn't support replace

IE11 supports classList just fine, except for an argument to toggle. Nothing a little DOMTokenList.prototype change can't fix.

> The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days"

That will only happen if you're incompetent and will not write a few simple helper functions. And probably not even then. Plain DOM API is not that verbose over jQuery. Anyway, just look at what subset of jQuery you use the most and write helpers for that.

Your codebase is already grown by 1000s of lines by using jQuery, so you have quite a head start sizewise if you drop jQuery.

Another tweet says that removing chaining improved readability...

https://twitter.com/mislav/status/1022409388013834240

But this I'd say is very close to BS territory..

It was me, who asked him the question. The answer though isn't satisfactory enough. But again 140 chars is not a good bandwidth for meaningful conversations.

The claim is interesting, but isn't evident enough.

For example, how exactly is

    var element = document.querySelectorAll('.container') 
    element.style.paddingTop = "50px"; 
    element.className = element.className + 'header';

communicating intent better than:

    $('.container').css('padding-top','50').addClass('header')

While I do agree in your comparison the second version looks better. At the same time, and this might be a tad too subjective to have much merit, it feels out of place to me.

Instead, I'd use one of the various approaches where I can create a style = {} object and then apply it to the element, which would just fit better within the rest of my javascript.

(which particular approach to use, .cssText, looping through props, or Object.assign, I'm not sure, but my point is any approach that applies a POJO to the node instead of chaining strikes me as more idiomatic. this is not a hill I'd die on though...)

I wonder how many people will notice that your non-jQuery example actually contains a subtle bug.

Re 2.:

el.querySelectorAll('abc').map(el => ...)...

You may need to copy some methods you'd like to use from Array.prototype to NodeList.prototype though, or use .values() from NodeList everywhere.

That's manual iteration even if it's done via HoF.

Many of jQuery's operations implicitly apply to the entire nodeset regardless of the nodeset's arity.

Fair point, though for dynamic and large DOMs I dislike having to go and check whether I’m touching more than one element sometimes — not always though, sometimes it great to just $(‘#bleh’).hide() or what have you! Depends really

That's completely fair, and there are cases where unknowingly selecting and applying complex operations to many nodes is problematic but I think it's a great baseline/default regardless.

I usually add: const qs = (selector) => [...document.querySelectorAll(selector)]

so that I can tread my results as a normal array.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla... ;)

[Same Link] You can see how poor the browser support is and how big the polyfill is. There's a chance that the polyfill could be bigger than jQuery's removeClass/addClass implementations.

FWIW, a few of the non-jQuery alternatives documented on http://youmightnotneedjquery.com are not equivalent -- they lack some of the functionality that jQuery offers. For example, take a look at $.replaceWith(). If you use $.replaceWith() you can supply an element that has event handlers bound to it and those event handlers will persist after the replacement. But in your alternative code ( el.outerHTML = string; ) you can only pass in a string which of course cannot have event handlers bound to it.

Is it time to make that site open source and update it, then? Maybe make a version that targets IE 11+ or even discards Edge, that way you can show promises / async/await for just the ajax one, as well as the straight CSS solutions.

It is open source. Repo: https://github.com/HubSpot/YouMightNotNeedjQuery

License is MIT.

Unfortunately it seems to be unmaintained.

I kind of imagine we will one day have a basic poly fill for all the cross platform issues jQuery actually excels at, and then we truly won’t need jQuery since that’s all it’s really good at these days. Things like chaining are an anti pattern and lead to brittle code!

Oh, but we already do have that, over there: https://jquery.com/

What's with the trend "jQ is old, old is bad! We need something that does the same thing, and most importantly is not named jQuery"?

Most DOM manipulation in jQuery goes through jQuery.globalEval, which uses eval(). Meaning if you want to have a CSP, you have to allow unsafe-eval if you need to support jQuery.

CSP is an incredibly useful tool, and it’s close to impossible to use it properly with jQuery.

First concrete, legitimate reason I've seen all thread. Is there something fundamental about jQuery's design that forces it to use eval(), or is it possible a new version could avoids that?

Performing evals is a core part of the design. Take a look at the additional notes section on this documentation of the .html method.

http://api.jquery.com/html/

>By design, any jQuery constructor or method that accepts an HTML string — jQuery(), .append(), .after(), etc. — can potentially execute code

This makes jQuery less safe in general, but I think the CSP restrictions this puts in place are probably a greater issue for most people. I’ve been involved in retro-fitting strict CSPs into a few projects, and more than once I’ve been thwarted by very minor use of jQuery in a couple of places.

It's part of the design of the creation of new elements. But that's just one part of jQuery, and a part I would be completely okay with jQuery getting rid of.

I don't think I can agree with that idea about chaining.

I think those are some broad generalizations that I can't agree with, but Sizzle might be what you're looking for.

https://github.com/jquery/sizzle/wiki

Sizzle is ancient history at this point. It's the selector engine jQuery used before querySelector became available everywhere.

Yes, that was the point. What did you think I thought Sizzle was?

"might be what you're looking for", when that person was looking for a "basic poly fill for all the cross platform issues jQuery actually excels at"

Exactly rice. A possible answer to a somewhat ambiguous desire.

It would be cool if that website was updated then.