jQuery: the good, the bad & the ugly

By Richard Larson Posted Sep. 03, 2012 Reading time: 5 minutes

jQuery is the largest open source, cross-browser, CSS3 compliant, JavaScript library around and it has made client-side scripting a breeze.

The syntax is simple and jQuery can produce beautiful almost Flash-like animations. Unlike Flash, jQuery is viewable on iOS and it produces dynamic web pages easily.

jQuery is rapidly growing in popularity and with the recent jQuery conference held in San Francisco at the end of June it seems an opportune time to start a conversation about jQuery and specifically some of the pros and cons of using it for more demanding jobs.


The good

Perhaps the best thing about jQuery is that you don’t need to be a programming genius to wow clients.

There’s usually more than one way to skin a cat, but the ability to add plug-ins on top of the base library makes jQuery an incredibly flexible and above all speedy solution. Using CSS may be the better choice in some cases (see below) but if your programming skills are more limited, selecting jQuery will help you get the job done.

Web development is too often a process strapped for time and saving minutes or even hours of work is often not a luxury but a necessity. John Resig and the other developers behind the jQuery project genuinely understand the time/money equation that faces web developers on a daily basis. Speedy implementation usually means more dollars in your pocket.

The verbosity of JavaScript, the complexity of implementing CSS and the well-publicized drawbacks of Flash make jQuery the most practical solution to many common issues including DOM transverses, event handling, AJAX interactions and animation.

Microsoft and Nokia are both behind jQuery and planning to bundle it into their new platforms suggesting a bright future ahead. Additionally almost everyone in the open source community is behind jQuery because:

  • The support of the community is great
  • It makes DOM manipulation painless
  • It plays well with AJAX
  • It makes basic animation a piece of cake
  • Set selection is painless
  • There are plug-ins
  • Bugs get identified and fixed quickly

Open source allows fast and dynamic growth. There are no licenses to worry about and it is free. Free actually translates into a community of minds that is far broader and smarter than the developers held captive by one company.

The core of jQuery has been built by some of the most brilliant minds in the business and the development is literally exploding.


Paper cut of business man on old book via Shutterstock


The bad

Open source has its issues: for example, not everything is built to a common standard. This is fine if your client — or more likely, you — have the time and money to invest tweaking code. However, if time, money, ability or all three are in short supply your back will be up against the wall when something goes wrong.

The latest stable version of jQuery (v1.7.2) was released March 21, 2012, so the ability to find common solutions for your exact issue, drawn from the community pool is likely to be in short supply for some time to come.

Another major problem with jQuery is that there are multiple versions out there. Some versions play well with others and some don’t. For example, browser compatibility with animations has been a long-standing problem with jQuery animations. Making sure that you are currently running the latest jQuery update will fix many of the known issues related to jQuery animations, but you are left choosing between hosting the library yourself and continually updating, or loading the library from Google and risking incompatibility with your code as new versions are released.

The AJAX control toolkit provides server side controls. This gives a developer a lot more power and flexibility. But the AJAX toolkit is large and bulky compared to jQuery. As jQuery continues to develop the lightweight code will probably win out especially with Microsoft onboard — by backing jQuery Microsoft are essentially dumping their own MicrosoftAjax.js. On the surface, the results of using jQuery to deal with XML are really cool; there are so few lines of code, it all just seems so easy…

However, handling AJAX and jQuery is a common area where the downsides of not really being a programmer frequently become apparent. For example, understanding the fundamental differences between GET and POST HTTP requests is vital, and yet so many designers who lack this knowledge plow on, expecting jQuery to pick up their slack. There are pitfalls that designers may not be aware of, for example GET requests can be limited in length and many inexperienced programmers simply switch to POST to solve the issue; this can be a bad idea, GET makes no lasting modifications on the server whereas POST can. POST isn’t a command that should be arbitrarily repeated yet it is used unwittingly sometimes.

Another common server side issue related to jQuery rears its ugly head if $.get is used instead of $.getJSON (javascript object notation). Not using $.getJSON for data transport issues can cause all sorts of havoc.

Don't run before you can walk

Young boy pretending to drive a giant earth mover via Shutterstock

It’s easy to be cool with jQuery, it’s not so easy to be cool and correct.

To use jQuery and especially cool jQuery well requires a commitment to the community. The development is rapid and that is exciting but this can also lead again to issues related to time. The development is so fast in some areas that if a developer doesn’t follow and take part in the community on a regular basis it is easy to get left in the dust. This is an additional time commitment for developers who are strapped for time trying to run a business, take care of multiple clients, implement SEO and Content Marketing campaigns and still see their kids.

It is necessary to realistically evaluate your skill level and the time required to stay on top of all the new jQuery developments.


And the ugly

The two big elephants in the closet related to jQuery have been left for last: speed and spaghetti code.

jQuery can be slow, and for animation sometimes a lot slower than using CSS. In a large complex site every tiny sliver of a second counts. The reason for this is twofold: multiple DOM manipulations, one on top of another can slow a site down; secondly, CSS uses browser-side transitions for animations and is written in C++. This makes it slightly faster than JavaScript.

jQuery spaghetti, if you haven’t come across it yet, in time you will. jQuery’s biggest attribute — how easy it is to use — is also its Achilles heal. jQuery is a library that is designed to help with DOM transverses and CSS selectors. It does this with amazing efficiency. It is not intended to be used as a Framework for client-side interaction. When used incorrectly, especially jQuery CSS selectors, the end result can be code that grows and grows in a monster-sized .js file until it becomes impossible to maintain. Throw in callbacks, a few cosmetic design changes, and generic naming and down the road, maintaining a jQuery site can become a nightmare.

Eating spaghetti

Vintage Photo of two young boys eating spaghetti with their hands via Shutterstock

The jQuery community is addressing the problems surrounding jQuery spaghetti. Cedric Dugas raised awareness about jQuery spaghetti at Confoo. He among others is dedicated to reminding programmers of using best practices with jQuery to prevent mammoth bowls of spaghetti. As one front-end designer commented, to really use jQuery well you need to know and understand JavaScript. Cutting and pasting definitely has its drawbacks in that it enables results without understanding. While this can work for a while it can also cause all sorts of long-term maintenance issues.

Using a good framework can help to prevent some of the jQuery spaghetti. Unfortunately, frameworks are really a new area and it takes time to choose the right framework(s) and get them to play nicely with one another. Again this additional time needs to be factored into the jQuery equation. At the moment there are many frameworks looking to dominate the client side MVS Framework space. Backbone.js is the most popular at the moment but it has some serious competition.


In summary

jQuery is one of the best libraries out there and it can make writing JavaScript much easier. However, like many tools, jQuery is at its best used by an expert craftsman. Do we all fall under this category? Of course not. Does this mean we shouldn’t use jQuery? Of course not. It just suggests that having enough sense to ask for help when you are out of your depth is a good idea most of the time.


Do you use jQuery and do you also know JavaScript? Do you need to understand programming to implement jQuery? Let us know what you think in the comments.