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 . 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. already have jQuery cached from a CDN Even if they don’t have it cached, . Your HTML markup might be larger than this. If you want the full featured version of jQuery, that’s only about 6KB more. jQuery Slim Minified + Gzipped is only about 27KB 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 so you can import it into your modules where needed. Other tools, like , have something similar. as an external library Rollup 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 , 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. can save 30 seconds of typing here and there 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 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. very easy 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. or can be frequently replaced with a normal loop. $.each() $(someSelector).each() isn’t very good. is pretty great if you aren’t already using it. This functionality is removed in jQuery Slim. $.ajax() Axios If you reuse selectors, store the result in a variable for use later. Querying the DOM is slow. has a good example. This answer on StackOverflow 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 will give you ECMA 2015+, which means modules for scalability. This will also give you easy uglification for production environments. very basic webpack configuration 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 . 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. so are a lot of other people 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 or , 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. Vue Angular 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.