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 ..?
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.
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.
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!
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.
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.
No it doesn't.
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.
I really wish we'd of just ditched it and moved to Chrome or Firefox :(
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.
(I wish I could remember what it was. Perhaps an array method).
> 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!
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?)
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.
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.
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/,'');
document.getElementById('somediv').classList.remove('class-to-be-removed')
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
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...
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
> 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.
https://twitter.com/mislav/status/1022409388013834240
But this I'd say is very close to BS territory..
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';
$('.container').css('padding-top','50').addClass('header')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...)
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.
Many of jQuery's operations implicitly apply to the entire nodeset regardless of the nodeset's arity.
so that I can tread my results as a normal array.
License is MIT.
Unfortunately it seems to be unmaintained.
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"?
CSP is an incredibly useful tool, and it’s close to impossible to use it properly with jQuery.
>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.