I Still Love jQuery — And You Should, Too.

There’s a big stigma around using jQuery lately . It seems like everyone is insistent on avoiding it in modern JavaScript development. Lately developers are all talking about things like TypeScript, ECMA2015+, and the current flavor of the month framework.

I think this is silly. jQuery is still very much relevant in 2017 — it just isn’t getting talked about.

jQuery Doesn’t Make Your Site Slow

One of the biggest reasons to avoid jQuery I see posted these days is that it adds unnecessary file size to your site. However, the truth is the file-size it does add to your site is more often than not insignificant, or non-existent at all.

A huge percentage of your visitors already have jQuery cached from a CDN. This means using jQuery is essentially free as far as your bandwidth is concerned. It won’t slow down the loading time of your website in any meaningful way.

Even if they don’t have it cached, jQuery Slim Minified + Gzipped is only about 27KB. Your HTML markup might be larger than this. If you want the full featured version of jQuery, that’s only about 6KB more.

webpack Externals are Great

webpack is a staple of modern JavaScript development, and you should be using it or another module bundler of your choice. Use jQuery as an external library so you can import it into your modules where needed. Other tools, like Rollup, have something similar.

jQuery Makes Writing Code Faster

Time is money. Your time is valuable, and clients perceive value in the amount of productive features you can successfully implement within a number of billable hours. If you can save 30 seconds of typing here and there, a few minutes of writing code elsewhere, you will undoubtedly start demonstrating significant productivity advantages compared to other colleagues who have a stigma against using jQuery.

Even if you are just working on a personal project, you should treat yourself as your client and strive for the best value possible.

You Should Still Be Aware of Slow Code

It is very easy to write very inefficient code in jQuery. The extremely low barrier to entry means there is a huge amount of very bad code, even in popular StackOverflow results for Google searches.

Here’s a short (but definitely not exhaustive) list of things you should be aware of:

• jQuery animations are almost never the right answer anymore. CSS is better for this stuff unless IE7 support is something you care about — in which case I would often argue that no animations are better than slow ones. Animations are removed in jQuery Slim.
• $.each() or $(someSelector).each() can be frequently replaced with a normal loop.
• $.ajax() isn’t very good. Axios is pretty great if you aren’t already using it. This functionality is removed in jQuery Slim.
• If you reuse selectors, store the result in a variable for use later. Querying the DOM is slow. This answer on StackOverflow has a good example.
• Similarly, if you need to perform multiple options on something, leverage chaining.

Writing jQuery that Scales

I am definitely not suggesting that you use every jQuery extension you can find to just throw features together. For very low budget and low traffic sites, this can be a reasonable approach for a couple of features, but every jQuery extension you use in your code will potentially contribute to significant performance reductions. You also need to be aware of the age of the libraries you’re adding. They could be adding a lot of bloat for things like IE8 or even IE7 (*gasp*) support.

The topic of scalable jQuery is huge and probably deserves an article all to itself, but the short version is simple: be aware of the performance hit of anything you use. If you are using a jQuery extension to add some functionality, do some testing to see how much it slows down your web site or application. If you are using code copy and pasted from StackOverflow, make sure you understand what it is doing before using it.

Seriously, Use webpack

It’s 2017, and if you’re not using a module bundler like webpack, you’re a little behind. A very basic webpack configuration will give you ECMA 2015+, which means modules for scalability. This will also give you easy uglification for production environments.

If you are anti-jQuery in 2017 and not using something to minify/uglify your code for production, I’m not quite sure your priorities are straight.

Use jQuery with Other Frameworks

I’m an advocate for Vue as my framework of choice right now, and so are a lot of other people. 2016 saw Vue as the fastest growing Javascript framework. Vue is very easy to use, with simple naming conventions and a very low barrier to entry.

Using jQuery in conjunction with Vue (via a webpack external as mentioned above) doesn’t really add a lot of additional features, sure. But it can take something that would take you an hour to write in Vanilla JS and allow you to write it in a few minutes if you know jQuery to a reasonable extent.

When to Actually Avoid jQuery

In my opinion, whether to use jQuery or not is a budget-minded question, not a practical one, in most cases. If you are a developer very familiar with jQuery, and you are working on small- to medium-scale websites, then you can often save yourself a lot of time by using it.

For large scale sites, you can still consider jQuery, but issues of complexity are going to start coming up. If you are working on a team of multiple people on a website, jQuery can often over-complicate your code and lead to an unmaintainable spaghetti monster of a website. You might want to consider a more rigid framework in these cases, such as Vue or Angular, which is going to provide a more opinionated of a base to build from, instead of the free-for-all cage fight that is jQuery-based development.

jQuery is great. I still love using it daily, and I do find that it saves me a significant amount of time on my projects. However, you should be aware of any performance impact it is having on your website or application. jQuery has suffered from years and years of bad information and an often abused extension-based ecosystem that can make your website feel like it was built in 2007 rather than 2017 if you’re not careful.