jQuery: It’s OK To Use It

I’ve seen lots of articles recently that claim you don’t need jQuery. Some try to define when you should and shouldn’t use it, a small number of them say you shouldn’t use it at all.

To be fair: the definition-setting articles take the position that “It’s completely OK to use jQuery…just think about a more efficient JavaScript-only approach first.” But they still show a bias for not using it at all so I wrote this article to present this bias from the other direction.

A preamble

Scott Hanselman recounted a story on JavaScript Jabber about how he was managing a bunch of developers for a banking software project. One of them wanted to create their own .NET calendar control to a solve a problem he was having with the one that .NET already came with.

During the conversation, Scott asked him if he had looked at any third party options. The developer said he found a widget that cost $400, to which, Scott responded:

“You have four hours to write the greatest calendar control in the world, because you’re [costing me] $100 an hour and you told me that you can buy one for $400. So you have four hours. If you can solve this problem in four hours, great. Otherwise we’re going to buy a widget.”

Supervisors have used that exact same math with me before: I once had to build a photo gallery for the Revlon site which, at the time, was a sloppy mashup of Flash and XHTML. That kept me from building the gallery as per the spec.

I told my boss I needed more time to do this and that the deadline may be in trouble as a result. He told me to just go and buy a $20 gallery plug-in: I did and solved the problem in 20 minutes.

Being able to build things as a developer is great but can be too visceral at times. Sometimes, we have to ignore our desire to change the world with software and just get stuff done.

I put jQuery on that exact same pedestal.

The main arguments

Some of the common arguments for not using the library are:

  • DOM selection in pure, vanilla JavaScript is faster than if you use jQuery.
  • We can now create web animations with CSS3 that are faster than the ones we used to create with jQuery.
  • Too many new developers choose to learn jQuery before learning pure JS.
  • Browsers have progressed to a point that they’ve solved many of the bugs that jQuery provides workarounds for.
  • JavaScript itself has progressed to a point that it’s solved many of the bugs that jQuery provides workarounds for.

The Newbies!!!!!

First, I can’t disagree with the performance issues related to both DOM selection and web animation. My opinion is that we should first attempt to do DOM selecting and animations with, respectively, vanilla JavaScript and CSS3 before doing them with jQuery.

But those newbie developers that learned jQuery before JavaScript? That’s their problem to fix, and they’ll fix it as soon as they realize it’s lessening their employment prospects.

jQuery has always said “write less, do more” but has never said “learn jQuery before JavaScript.” Since the library never led people down that latter path, I don’t think it should be part of a “don’t-use-jQuery” conversation.

Now, if experienced developers want to make it part of the conversation and want to change things, they need to go out and actively mentor newer developers and explain to them why it’s the wrong approach. Furthermore, they need to mentor newbies on the role of libraries in software development and explain its pros and cons.

Experienced developers limiting their own jQuery usage and then blogging about it certainly leads the newer developers by example. But it’s no guarantee that newbies will shift their learning pattern if no one’s around to lead them to that direction.

The Bugs

And yes, both browsers and the JS language have fixed their internal bugs but there are still a few that jQuery handles for you behind the scenes. The current 2.x version fixes a handful of bugs related to IE9+, Android, Chrome, Mozilla and iOS8+.

And I’ll let you in on a little secret: more browser/JS bugs are coming. And there’s a very good chance that jQuery will account for those bugs before you know they even exist.

“You Might Not Need jQuery” was one of the first popular “don’t-use-jQuery” arguments because it showcased vanilla JS code snippets as alternatives to their jQuery counterparts. Leaders in the web dev community quickly countered all this with a document highlighting all the edge case bugs jQuery created work-arounds for.

The document’s over two years old at the time of this post and covers a few legacy IE bugs, so it may be considered as slightly outdated. But the statement it starts out with is still valid:

While the sentiment of youmightnotneedjquery is great, developers should be aware that ditching libraries, like jQuery, can easily require large amounts of research on their end to avoid bugs (even in modern browsers). The snippets provided by youmightnotneedjquery are a starting point but hardly scratch the surface of being a solid robust replacement to jQuery.

Managing and researching JavaScript bugs is jQuery’s strong suit after DOM selection. And it will probably stay that way for a long time.

jQuery gets the job done

This segues into the main reason why it’s OK to use jQuery: because it’s a tool you use to help you get your work done faster!

jQuery a library stocked with utility methods that perform quick, efficient tasks so you can get the job done quickly and efficiently. Such tasks include:

  • Advanced DOM selection (I’m slightly contradicting what I said earlier, but jQuery’s advanced DOM selecting power still kicks ass)
  • Event handling
  • Ajax-related tasks
  • JSON
  • Promises

Zach Holman is a web developer that’s done a lot of great writing and speaking on the internal workplace dynamics of tech startups. In a recent blog post, he recounted a story of being quizzed about some Ruby stuff during a job interview.

He was asked to execute a particular Ruby operation and wrote a simple method from the standard Ruby library to do so. Then the interviewer asked:

“Okay now what if you couldn’t use the standard library? Imagine it’s a 200GB file and you have to do it all in memory in Ruby.”

To which, Holman respectfully responded:

“Why the fuck would I do that?”

Questions like this are commonplace in web dev job interviews so I’m taking things out of context to prove a point. But yeah: why the fuck would you do that?

Why would a developer purposely do a job the hard way when tooling exists to avoiding that exact situation? Why take more time than needed to finish a task?

This goes back to the role of libraries in software development: they’re a necessary tool, not a necessary evil. I’m not saying you should always use jQuery, but respect its efficiently when it comes to getting the job done…well!

And a quick side-note: using libraries and buying widgets instead of coding things from the ground up is generally how it works in the corporate web dev world. The Hanselman and Revlon stories previously mentioned are not anomalies…jQuery thrives in those situations.

About those performance issues

All this being said, sites and apps that don’t use jQuery run faster than those that do. And this matters in our mobile device-obsessed world.

I once did a jsperf comparison test where I added a bunch of attributes to a page element with both plain JS and jQuery (and I’d show you the test if jsperf was working). Plain JS was clearly the fastest way to do things, particularly on legacy IE.

While not using the library is faster, I think this is negligible. Lots of images, multiple network requests/DNS checks, shared hosting, etc…these are the speed problems we need to focus on.

Most profoundly, both browsers and the JavaScript language have had bugs that hamper site/app performance and developers have always been vocal about not liking this. But a nice byproduct of devs being vocal is that browser and language implementers heard them and fixed things where they could: Microsoft’s shift from IE to Edge is proof of this.

My point is, jQuery isn’t the only thing with performance issues. Definitely focus on optimizing its usage, just remember that there are other issues you’ll have to deal with.

Conclusion

There have been some great arguments for limiting jQuery usage. My two favorites come from Patrick Kunka and his “A Year Without jQuery” post (where he talks about how not using jQuery for a year forced him to get better at pure JavaScript), and Lea Verou and her “jQuery considered harmful” post (where she highlights how over-zealous jQuery usage can lead to a sloppy codebase that’s hard to fix and maintain).

Remy Sharp also wrote an article on the subject. I think he summarized the best approach: don’t let jQuery be your default starting point for writing JavaScript and start by writing pure JS instead (this is what I do).

Regardless of these and other articles, libraries like jQuery are a standard requirement for web development. And in the big picture, we need them to do what they do…so we can get done what we have to get done.


Leave a Reply

Your email address will not be published. Required fields are marked *