5 ms·

Legitimate question (I am not trolling), but is there truly a good reason to stop using jQuery? I get that there are now standard ways to do DOM lookups and so

Legitimate question (I am not trolling), but is there truly a good reason to stop using jQuery? I get that there are now standard ways to do DOM lookups and so on, but what if you simply like jQuery's API? Can't we recognize that as one of the web's most widely installed libraries, it's practically a standard library module for the DOM and for x-browser JavaScript? Why are we so eager to get rid of it?

lisper 8y ago
> is there truly a good reason to stop using jQuery? Nope. If you like it, and you don't have performance problems for which jQuery is a significant contributing factor (which is extremely unlikely), then keep using it.
kyriakos 8y ago
Not really. Especially if you want to support all browsers it still does an excellent job.
asdojasdosadsa 8y ago
External libraries often introduce unused methods, thus expanding the size of your size, which could be problematic on high traffic size. So, if your site is small and has medium to low traffic, there's not really a "good" reason. But if you have high traffic you might want to really squeeze every saving you can
- ddebernardy 8y ago
  If you intend to write ~5-10k of custom JS that users will need to download over some potential high traffic scenario to get rid of a ~29k gzipped dependency that is almost certainly cached already because hosted on Google's CDN or elsewhere, you might want to look at your stats and see how much caching is going on before giving this a go. (The article says: "[...] when you consider that we have over 5 million pageviews to the article content type in any given 30 days, it translates to roughly 150GB of bandwidth saved." But that is utter BS that wouldn't pass a sniff test with a 10-year old who understands a modicum of browser caching and network caching.)
  - stephenr 8y ago
    Your whole rant assumes using jquery from a CDN. While common, it’s not the only way to use it.
    - reaperducer 8y ago
      Yep. We are prohibited from using outside CDNs for security reasons.
z3t4 8y ago
One less thing for new developers to learn. One less thing for each visitor to download. One less thing to maintain. JQuery is probably the least obtrusive framework though, eg you do not have to rewrite all your JQuery code every 3 year due to breaking changes. Also you do not have to compile your JQuery code to JavaScript, it's already JavaScript.
i_made_a_booboo 8y ago
It's just following the laws of Resume Driven Development. 1) If it's not on your resume it needs to be. 2) If it's already on everyone's resume you must seek alternatives 3) Resumes are never finished, only abandoned I'm starting to feel like I should expand this into a manifesto.
- iamdave 8y ago
  I'm starting to feel like I should expand this into a manifesto. <sarc> Yes, let's give the clueless tech recruiters more ammunition to screen out otherwise qualified candidates after someone with a blog stumbles across your site and suddenly recruiters are doing machine learning-matching on resumes against "the manifesto" </sarc>
platz 8y ago
I'm torn as jQuery allows dense code with it's query language, but at the same time it tends to produce brittle code that has high coupling and low cohesion, so that is hard to maintain. I think the trade-off is that you opt for a more wholistic approach or framework that is more costly to bootstrap but easier to maintain, especially as complexity increases.
stefan_ 8y ago
I presume it's hailed as such an unbelievable achievement because the sorry state of frontend development means just answering "what is my exposure to library X" is impossible, so scrubbing a single leaf from a 30 wide 10 deep dependency tree is unheard of.
untog 8y ago
It's an extra dependency that each user has to download, and that their browser has to parse. If you don't need it, and can avoid using it, why not?
verisimilidude 8y ago
You're right, the dogmatic opposition to jQuery tends to be unconvincing. The reason I don't use jQuery these days is because other libraries serve jQuery's functions a little better for me. * If I want a more robust interface for my XHR requests, there are a ton of nice libraries out there. Superagent is a good example. * If I need utility belt stuff, I can get more out of Lodash, Ramda, etc. * If I want animations, there are much better ways to do that nowadays, even with just basic CSS3. * If I need distinct DOM lookup and manipulation...well, this might not be needed at all if I'm doing an SPA (in React, etc.). That said, there are compelling alternatives that I like, such as bonzo. And then there's just the fact that you can now do an awful lot with bare Javascript. So my argument against jQuery is less "jQuery sucks" and more "I prefer using all these other tools that cover the same surface". jQuery is still a marvel for all the conveniences it provides, and I don't think anyone should stop using it just because the cool kid says so.
- ravenstine 8y ago
  That pretty much sums it up. jQuery animation can be pretty atrocious. Granted, CSS transitions/animations can also be atrocious if certain properties are being changed at the wrong times. jQuery is going to select and manipulate elements, but it's not going to compensate for when the developer does moronic things like creating DOM elements a bajillion times with HTML strings in jQuery every time something changes, animating things in improper ways(like animating dimensional properties that cause extra redrawing before postrender), etc. There's nothing wrong with using jQuery. I just find that I don't even need it and would much prefer to just use existing APIs in its place. If there's a compatibility issue, I can install a polyfill that's much smaller than jQuery ever will be.
reaperducer 8y ago
I think a big part of the problem is that jQuery went from a nifty tool to do nifty things to a crutch that is abused by low-end devs. The most recent project I took over had jQuery loading on every page. Even though jQuery was actually only used on maybe 10% of the pages. And the thing the previous developer was trying to accomplish with jQuery can be easily done in CSS. Needless to say, that web site is now jQuery free.
wnevets 8y ago
because its not cool
DonHopkins 8y ago
Have you ever single stepped through the jQuery code and looked at the return stack? shudder There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer. Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc. That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide. But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result. Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name. And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.) https://github.com/cbrandolino/jQuery-basic-arithmetic-plugin https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...
rstuart4133 8y ago
One reason is it should not have been there in the first place. Due to it's age, if you google / stackoverflow something, the odds are very high a jQuery response will be among the top hits. And so you end up with some jQuery dependency. Back in the day when you had to target IE-6 that made sense - the web was so broken you really needed something it jQuery to render it sane. But that time has gone now, and I can't count the number of times the jQuery solution actually used more core than raw js. Doing this is positively harmful. Not only is it slower and creates clashing dependencies because library A wants jQuery version B, but library Y wants version jQuery Z, it forces the programmers to learn the 10'th different way of doing something (there are always at least 10 libraries that do it). It's unnecessary because there is one thing every javascript programmer should know (and it's not jQuery) - it's modern javascript and the standard library provided by a IE9+ browser. If it can be done with a few lines that then that is how you should do it - because it makes like so much easier for those who follow you.

lisper 8y ago

> is there truly a good reason to stop using jQuery? Nope. If you like it, and you don't have performance problems for which jQuery is a significant contributing factor (which is extremely unlikely), then keep using it.

kyriakos 8y ago

Not really. Especially if you want to support all browsers it still does an excellent job.

asdojasdosadsa 8y ago

External libraries often introduce unused methods, thus expanding the size of your size, which could be problematic on high traffic size. So, if your site is small and has medium to low traffic, there's not really a "good" reason. But if you have high traffic you might want to really squeeze every saving you can

ddebernardy 8y ago
If you intend to write ~5-10k of custom JS that users will need to download over some potential high traffic scenario to get rid of a ~29k gzipped dependency that is almost certainly cached already because hosted on Google's CDN or elsewhere, you might want to look at your stats and see how much caching is going on before giving this a go. (The article says: "[...] when you consider that we have over 5 million pageviews to the article content type in any given 30 days, it translates to roughly 150GB of bandwidth saved." But that is utter BS that wouldn't pass a sniff test with a 10-year old who understands a modicum of browser caching and network caching.)
- stephenr 8y ago
  Your whole rant assumes using jquery from a CDN. While common, it’s not the only way to use it.
  - reaperducer 8y ago
    Yep. We are prohibited from using outside CDNs for security reasons.

z3t4 8y ago

One less thing for new developers to learn. One less thing for each visitor to download. One less thing to maintain. JQuery is probably the least obtrusive framework though, eg you do not have to rewrite all your JQuery code every 3 year due to breaking changes. Also you do not have to compile your JQuery code to JavaScript, it's already JavaScript.

i_made_a_booboo 8y ago

It's just following the laws of Resume Driven Development. 1) If it's not on your resume it needs to be. 2) If it's already on everyone's resume you must seek alternatives 3) Resumes are never finished, only abandoned I'm starting to feel like I should expand this into a manifesto.

iamdave 8y ago
I'm starting to feel like I should expand this into a manifesto. <sarc> Yes, let's give the clueless tech recruiters more ammunition to screen out otherwise qualified candidates after someone with a blog stumbles across your site and suddenly recruiters are doing machine learning-matching on resumes against "the manifesto" </sarc>

platz 8y ago

I'm torn as jQuery allows dense code with it's query language, but at the same time it tends to produce brittle code that has high coupling and low cohesion, so that is hard to maintain. I think the trade-off is that you opt for a more wholistic approach or framework that is more costly to bootstrap but easier to maintain, especially as complexity increases.

stefan_ 8y ago

I presume it's hailed as such an unbelievable achievement because the sorry state of frontend development means just answering "what is my exposure to library X" is impossible, so scrubbing a single leaf from a 30 wide 10 deep dependency tree is unheard of.

untog 8y ago

It's an extra dependency that each user has to download, and that their browser has to parse. If you don't need it, and can avoid using it, why not?

verisimilidude 8y ago

You're right, the dogmatic opposition to jQuery tends to be unconvincing. The reason I don't use jQuery these days is because other libraries serve jQuery's functions a little better for me. * If I want a more robust interface for my XHR requests, there are a ton of nice libraries out there. Superagent is a good example. * If I need utility belt stuff, I can get more out of Lodash, Ramda, etc. * If I want animations, there are much better ways to do that nowadays, even with just basic CSS3. * If I need distinct DOM lookup and manipulation...well, this might not be needed at all if I'm doing an SPA (in React, etc.). That said, there are compelling alternatives that I like, such as bonzo. And then there's just the fact that you can now do an awful lot with bare Javascript. So my argument against jQuery is less "jQuery sucks" and more "I prefer using all these other tools that cover the same surface". jQuery is still a marvel for all the conveniences it provides, and I don't think anyone should stop using it just because the cool kid says so.

ravenstine 8y ago
That pretty much sums it up. jQuery animation can be pretty atrocious. Granted, CSS transitions/animations can also be atrocious if certain properties are being changed at the wrong times. jQuery is going to select and manipulate elements, but it's not going to compensate for when the developer does moronic things like creating DOM elements a bajillion times with HTML strings in jQuery every time something changes, animating things in improper ways(like animating dimensional properties that cause extra redrawing before postrender), etc. There's nothing wrong with using jQuery. I just find that I don't even need it and would much prefer to just use existing APIs in its place. If there's a compatibility issue, I can install a polyfill that's much smaller than jQuery ever will be.

reaperducer 8y ago

I think a big part of the problem is that jQuery went from a nifty tool to do nifty things to a crutch that is abused by low-end devs. The most recent project I took over had jQuery loading on every page. Even though jQuery was actually only used on maybe 10% of the pages. And the thing the previous developer was trying to accomplish with jQuery can be easily done in CSS. Needless to say, that web site is now jQuery free.

wnevets 8y ago

because its not cool

DonHopkins 8y ago

Have you ever single stepped through the jQuery code and looked at the return stack? shudder There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer. Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc. That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide. But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result. Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name. And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.) https://github.com/cbrandolino/jQuery-basic-arithmetic-plugin https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...

rstuart4133 8y ago

One reason is it should not have been there in the first place. Due to it's age, if you google / stackoverflow something, the odds are very high a jQuery response will be among the top hits. And so you end up with some jQuery dependency. Back in the day when you had to target IE-6 that made sense - the web was so broken you really needed something it jQuery to render it sane. But that time has gone now, and I can't count the number of times the jQuery solution actually used more core than raw js. Doing this is positively harmful. Not only is it slower and creates clashing dependencies because library A wants jQuery version B, but library Y wants version jQuery Z, it forces the programmers to learn the 10'th different way of doing something (there are always at least 10 libraries that do it). It's unnecessary because there is one thing every javascript programmer should know (and it's not jQuery) - it's modern javascript and the standard library provided by a IE9+ browser. If it can be done with a few lines that then that is how you should do it - because it makes like so much easier for those who follow you.