jQuery: the good, the bad & the ugly

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.

  • http://twitter.com/zawzew Andrew McGivery

    My advice: If you aren’t already fluent in javascript, DON’T USE JQUERY.

    The purpose of JQuery always has been and always will be a supplement to javascript, to speed up development. It was never meant to be a replacement, or a “learn this instead of javascript”. If you don’t know generally what is happening in the background behind the JQuery code you are writing, you are wasting your time.

    • unicolored

      You’re right, it’s kinda like saying you know php while you just tweak some cms templates.

    • greekdish

       Highly disagree. I was making beautiful animations and interactive websites with jQuery before I really learned Javascript.

      If anything, jQuery helps you learn vanilla javascript.

      • Waganse

        I totally agree with you.

      • http://www.paulund.co.uk/ Paul

        I think you should always learn the basics of the raw language before starting to use a framework.

      • Aleksandr Strutynskyy

        right! you should learn mechanics before you even try to drive a car!

      • http://www.paulund.co.uk/ Paul

        Not really the same thing as a mechanics role is to fix a car.

        Using a framework without learning the language is like learning how to be a racing driver before learning how to drive.
        Why learn CodeIgniter before learning PHP?

        You should learn basic javascript before learning jQuery, this is so you understand what jQuery is doing under the hood.

  • http://twitter.com/arathael Ramón Ramos

    At the time of writing latest jQuery version was 1.8.1 … just sayin’.

    • Walter

      Thanks for your comment Ramón, but jQuery 1.8 wasn’t released until after this article was written.

  • http://www.stookstudio.com/ Erwin Heiser

    Really don’t see how spaghetti code is a jQuery exclusive – you can write spaghetti code in pretty much any language – javascipt included.

  • http://www.paulund.co.uk/ Paul

    I don’t see why you mentioned spaghetti code, with jQuery you work with objects, you can use namespaces and plugins. If you have spaghetti code surely that’s the developers fault not jQuery.

  • coolajax

    Great post.
    I’m a big fan of jQuery and it’s make my work so simple and efficient. But my suggestion is that, before starting jQuery we should at least learn basic terms of JavaScript. Only “Copy&Paste” of open source plugins can create a big disastrous while you are working on a big project.
    But, overall jQuery is the Best :)

  • just plain tired

    Ok boys and girls here’s my question: so you go to all the trouble to learn yet another language and just how long is that going to last? I’m serious. I feel like I’m just getting my arms around java or rather it’s strangling me to the ground and then there will be another language to learn. I’m not that good at languages to start with. Look mom now I know five languages that are completely useless. Is there any end in sight?

    • Walter

       I completely understand where you’re coming from just plain tired. It can seem like a never ending process of revisions.

      However, jQuery is a library for JavaScript, and JavaScript has been around well over a decade, plus it looks like being around for a long time to come.

      HTML5 is merely a revision of HTML4; and the same is true of CSS3, which is a revision of CSS.

      More importantly, if you learn how to code things like loops and work with OOP in one language, the principles (and sometimes even the syntax) will be exactly the same in the next language you learn.