Menu Search
Jump to the content X

jQuery Plugin Checklist: Should You Use That jQuery Plug-In?


jQuery plug-ins provide an excellent way to save time and streamline development, allowing programmers to avoid having to build every component from scratch. But plug-ins are also a wild card that introduce an element of uncertainty into any code base. A good plug-in saves countless development hours; a bad plug-in leads to bug fixes that take longer than actually building the component from scratch.

Fortunately, one usually has a number of different plug-ins to choose from. But even if you have only one, figure out whether it’s worth using at all. The last thing you want to do is introduce bad code into your code base.

Do You Need A Plug-In At All? Link

The first step is to figure out whether you even need a plug-in. If you don’t, you’ll save yourself both file size and time.

1. Would Writing It Yourself Be Better? Link

If the functionality is simple enough, you could consider writing it yourself. jQuery plug-ins often come bundled with a wide variety of features, which might be overkill for your situation. In these cases, writing any simple functionality by hand often makes more sense. Of course, the benefits have to be weighed against the amount of work involved.

For example, jQuery UI’s accordion is great if you need advanced functionality, but it might be overkill if you just need panels that open and close. If you don’t already use jQuery UI elsewhere on your website, consider instead the native jQuery slideToggle() or animate().

2. Is It Similar to a Plug-In You’re Already Using? Link

After discovering that a particular plug-in doesn’t handle everything you need, finding another plug-in to cover loose ends might be tempting. But including two similar plug-ins in the same app is a sure path to bloated JavaScript.

Can you find a single plug-in that covers everything you need? If not, can you extend one of the plug-ins you have to cover everything you need? Again, in deciding whether to extend a plug-in, weigh the benefits against the development time involved.

For example, jQuery lightbox is a nice way to enable pop-up photos in a gallery, and simpleModal is a great way to display modal messages to users. But why would you use both on the same website? You could easily extend one to cover both uses. Better yet, find one plug-in that covers everything, such as Colorbox.

3. Do You Even Need JavaScript? Link

In some situations, JavaScript isn’t needed at all. CSS pseudo-selectors such as :hover and CSS3 transitions can cover a variety of dynamic functionality much faster than a comparable JavaScript solution. Also, many plug-ins apply only styling; doing this with mark-up and CSS might make more sense.

For example, plug-ins such as jQuery Tooltip are indispensable if you have dynamic content that requires well-placed tooltips. But if you use tooltips in only a few select locations, using pure CSS is better (see this example). You can take static tooltips a step further by animating the effect using a CSS3 transition, but bear in mind that the animation will work only in certain browsers.

Avoid Red Flags Link

When reviewing any plug-in, a number of warning signs will indicate poor quality. Here, we’ll look at all aspects of plug-ins, from the JavaScript to the CSS to the mark-up. We’ll even consider how plug-ins are released. None of these red flags alone should eliminate any plug-in from consideration. You get what you pay for, and because you’re probably paying nothing, you should be willing to cut any one a bit of slack.

If you’re fortunate enough to have more than one option, these warning signs could help you narrow down your choice. But even if you have only one option, be prepared to forgo it if you see too many red flags. Save yourself the headache ahead of time.

4. Weird Option or Argument Syntax Link

After using jQuery for a while, developers get a sense of how most functions accept arguments. If a plug-in developer uses unusual syntax, it stands to reason that they don’t have much jQuery or JavaScript experience.

Some plug-ins accept a jQuery object as an argument but don’t allow chaining from that object; for example, $.myPlugin( $('a') ); but not $('a').myPlugin(); This is a big red flag.

A green flag would be a plug-in in this format…

 opt1 : 75,
 opt2 : 'asdf'

… that also accepts…

 opt1 : 75,
 opt2 : 'asdf'
}, $('.my-selector'));

5. Little to No Documentation Link

Without documentation, a plug-in can be very difficult to use, because that is the first place you look for answers to your questions. Documentation comes in a variety of formats; proper documentation is best, but well-commented code can work just as well. If documentation doesn’t exist or is just a blog post with a quick example, then you might want to consider other options.

Good documentation shows that the plug-in creator cares about users like you. It also shows that they have dug into other plug-ins enough to know the value of good documentation.

6. Poor History of Support Link

Lack of support indicates that finding help will be difficult when issues arise. More tellingly, it indicates that the plug-in has not been updated in a while. One advantage of open-source software is all of the eye-balls that are debugging and improving it. If the author never speaks to these people, the plug-in won’t grow.

When was the last time the plug-in you’re considering was updated? When was the last time a support request was answered? While not all plug-ins need as robust a support system as the jQuery plug-ins website, be wary of plug-ins that have never been modified.

A documented history of support, in which the author has responded to both bug and enhancement requests, is a green flag. A support forum further indicates that the plug-in is well supported, if not by the author then at least by the community.

7. No Minified Version Link

Though a fairly minor red flag, if the plug-in’s creator doesn’t provide a minified version along with the source code, then they may not be overly concerned with performance. Sure, you could minify it yourself, but this red flag isn’t about wasted time: it’s about the possibility that the plug-in contains far worse performance issues.

On the other hand, providing a minified, packed and gzipped version in the download package is an indication that the author cares about JavaScript performance.

8. Strange Mark-Up Requirements Link

If a plug-in requires mark-up, then the mark-up should be of high quality. It should make semantic sense and be flexible enough for your purposes. Besides indicating poor front-end skills, strange mark-up makes integration more difficult. A good plug-in plugs into just about any mark-up you use; a bad plug-in makes you jump through hoops.

In certain situations, more rigid mark-up is needed, so be prepared to judge this on a sliding scale. Basically, the more specific the functionality, the more specific the mark-up needed. Completely flexible mark-up that descends naturally from any jQuery selector is the easiest to integrate.

9. Excessive CSS Link

Many jQuery plug-ins come packaged with CSS, and the quality of the style sheets is just as important as the JavaScript. An excessive number of styles is a sure sign of bad CSS. But what constitutes “excessive” depends on the purpose of the plug-in. Something very display-heavy, such as a lightbox or UI plug-in, will need more CSS than something that drives a simple animation.

Good CSS styles a plug-in’s content effectively while allowing you to easily modify the styles to fit your theme.

10. No One Else Uses It Link

With the sheer volume of jQuery users, most decent plug-ins will probably have something written about them, even if it’s a “50 jQuery [fill in the blank]” post. Do a simple Google search for the plug-in. If you get very few results, you might want to consider another option, unless the plug-in is brand new or you can verifiy that it is written by a professional.

Posts on prominent blogs are great, and posts by prominent jQuery programmers are even better.

Final Assessment Link

After you’ve given the plug-in the third degree, the only thing left to do is plug it in and test how well it performs.

11. Plug It In and See Link

Probably the best way to test a plug-in is to simply plug it on the development server and see the results. First, does it break anything? Make sure to look at JavaScript in the surrounding areas. If the plug-in includes a style sheet, look for layout and styling errors on any page that applies the style sheet.

Additionally, how does the plug-in perform? If it runs slowly or the page lags considerably when loading, it might be important to consider other options.

12. Benchmarking With JSPerf Link

To take your performance review to the next level, run a benchmark test using JSPerf. Benchmarking basically runs a set of operations a number of times, and then returns an average of how long it took to execute. JSPerf provides an easy way to test how quickly a plug-in runs. This can be a great way to pick a winner between two seemingly identical plug-ins.

jsPerf screenshot
An example of a performance test run in jsPerf.

13. Cross-Browser Testing Link

If a plug-in comes with a lot of CSS, make sure to test the styling in all of the browsers that you want to support. Bear in mind that CSS can be drawn from external style sheets or from within the JavaScript itself.

Even if the plug-in doesn’t have any styling, check for JavaScript errors across browsers anyway (at least in the earliest version of IE that you support). jQuery’s core handles most cross-browser issues, but plug-ins invariably use some amount of pure JavaScript, which tends to break in older browsers.

14. Unit Testing Link

Finally, you may want to consider taking cross-browser testing even further with unit tests. Unit testing provides a simple way to test individual components of a plug-in in any browser or platform you want to support. If the plug-in’s author has included unit tests in their release, you can bet that all components of the plug-in will work across browsers and platforms.

Unfortunately, very few plug-ins include unit test data, but that doesn’t mean you can’t perform your own test using the QUnit plug-in.

With minimal set-up, you can test whether the plug-in methods return the desired results. If any test fails, don’t waste your time with the plug-in. In most cases, performing your own unit tests is overkill, but QUnit helps you determine the quality of a plug-in when it really counts. For more information on how to use QUnit, see this tutorial

QUnit screenshot
An example of a unit test run in QUnit.

Conclusion Link

When assessing the quality of a jQuery plug-in, look at all levels of the code. Is the JavaScript optimized and error-free? Is the CSS tuned and effective? Does the mark-up make semantic sense and have the flexibility you need? These questions all lead to the most important question: will this plug-in be easy to use?

jQuery core has been optimized and bug-checked not only by the core team but by the entire jQuery community. While holding jQuery plug-ins to the same standard would be unfair, they should stand up to at least some of that same scrutiny.

You may be interested in the following related posts:


Smashing Book #5

Hold on tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? For example, Smashing Book 5, packed with smart responsive design patterns and techniques.

↑ Back to top Tweet itShare on Facebook

Jon Raasch is a front-end web developer / UI designer with endless love for jQuery, CSS3 and performance tuning. Follow him on Twitter or read his blog.

  1. 1

    Agreed – picking right plugins is important. For simpler functionalities (such as carousels, slideshows, rotating banners etc.) I prefer to write it out myself so I have maximum flexibility. You can often end up spending more time trying to figure stuff out off a documentation or a set of code that was written to make it too easy for people to punch in options etc.

  2. 2

    IMO “Do You Even Need JavaScript?” should be at first place ;)

  3. 3

    Thanks for the checklist! In addition to cross-browser testing. Most plugin websites also offer a demo, do check the demo in different browsers. Most transition effects work perfect in Chrome or FF, but aren’t that smooth in IE. Also, when trying a demo, do it with a bit more heavier images. Most demo’s are shown with low kb images (sometimes 3 or 4kb gif’s). When you want to implement an image carrousel for one of your customers, most images aren’t that small in size.

  4. 4

    Minified version sure, but there appears to be some confusion about offering a “gzip version” in the text. gzip is a server setting you’d need to configure on your hosting – i.e., it’s not something a plugin, especially a client-side file such as JavaScript – can provide on its own.

  5. 5

    I find whilst some of the jQuery Plugins for image manipulation, modal popups etc. are good, they’re designed to be a ‘one size fits all’ solution. This has the drawback of ending up with larger Javascript files (even if minimized), of which you’re lucky if you’re using 5% of its functionality.

    In comparison, writing your own (even reusable) solution that has just the code required results in smaller Javascript files and better loading times – although you’ve then got to consider the time required to build such a custom solution, and whether you do need to reinvent the wheel.

  6. 6

    I would urge anyone that uses (or is in the process of picking) a general purpose library to not just blindly follow the crowd, research and understand how that library works and what it does (and what it can do for you) – it may not be all you expected it to be, and could create other problems e.g. memory leaks, browser sniffing, bugs, poor documentation etc.

    Secondly is all that extra download really needed? I mean really, just to fade a couple of elements in/out…

    Just my 2p.

  7. 7

    I find it ironic that not providing a minified and gzipped version is a minor red flag, but spelling gzipped with a captial Z is a red flag in itself.

    Otherwise, a fantastic article!

  8. 8

    Mike is right, you can’t offer a “gzipped” version in the download. I’m also not a fan of “packed” versions since they use eval (slower and a little bit evil). A simple minification is all that’s required. Preferably with Google Closure Compiler.

    I would also suggest checking the (unzipped) download size. jQuery is around 50kb minified but there are plugins that are as big or bigger than jQuery itself! It’s worth looking for a plugin that does everything you need but little more. For example DataTables is an excellent plugin for all sorts of table handling, but if you only need basic sorting you’re better off going for something like TableSorter.

  9. 9

    You forgot one of the most important decisions – what kind of license does the plugin have.

  10. 10

    Benchmarking is really strange thing you mentioned, as different browsers are faster in different aspects. For example selector speeds are a lot different in current browsers. Opera has the fastest selector speeds ATM, so a jQuery selection will take the less time in Opera, but the type of selector handling is also pretty different across browsers. So some will support one kind of query better then another.
    $(“#container p.ehh”) will be ~3 times faster in one browser and a little slower in others then $(‘#container’).find(“p.ehh”). So comparing based on speed is not really reliable, and must be well thought through.

  11. 11

    One of the better posts I’ve read here recently. I benefited from the straight-forward language. I don’t need to be a programmer to understand each heading / paragraph. Thanks!

  12. 12

    $.myPlugin( $(‘a’) ); but not $(‘a’).myPlugin();

    Those are different sittuations. The first one is a function, second one a public method. First one should be used for utilities, like jQuery’s isArray etc. Depending on the plugin it shouldn’t be a red flag :)

  13. 13

    Overkill… what are we actually talking about ?
    In my opinion you should use whatever you think is usable.
    BUT do not use plugins that are more then 1 MB in size… minified !

    My connection speed is really fast. 25 MB loads in 5 seconds.. So you can minify or compress as much as you want… try to get your perfect world.. I wont notice it.

  14. 14

    Gzip can also be done at the file level, and I’ve seen some plugins bundled with this. It can help if for instance you’re uploading it to a CDN such as Amazon s3 (although then you’re probably concatenating all your Javascripts into a single file and gzipping as part of the deployment process, so it’s sort of a moot point). I’d say that a minified / packed version is much more useful.

  15. 15

    Yeah I would definitely agree that it’s good to not blindly follow the crowd, there are plenty of popular plugins that aren’t all that great. However I would also say that no press at all is a red flag unless the plugin is brand new (although still not a ‘deal-breaker’).

  16. 16

    Hehe zinger! Fair enough :-)

  17. 17

    Good point although almost every jQuery plugin I’ve come across is released under a GPL.

  18. 18

    Good point, I should have mentioned that you might want to run the benchmarking in different browsers (which is pretty easy with jsperf).

  19. 19

    I strongly disagree with this, as bandwidth is one of the biggest bottlenecks these days, especially with the rise of the mobile web. I definitely don’t think you should build sites that only run well on fast connections, even if you don’t personally notice it.

  20. 20

    Based on the fact that 4 out of 5 web design articles I read suggest you use HTML5 and CSS3 in your project, I really get the feeling that web design bloggers are more like “those” college professors that have a Ph.D in the field, but no actual work experience. Every project I’ve worked on has had at least 30% of the users (as reported by Google Analytics) still on IE6, and around 70% on IE7 or 8. Maybe I’m wrong, but it’s my understanding that I’d have to throw in a great deal of hacks (increasing file sizes) to have a consistent user experience, and I’d probably have to use the jQuery anyway for the people who’s browsers don’t support CSS3 or HTML5 yet. Are there any compelling reasons to hack together a page with lots of code to support individual browsers (including the newer ones that don’t have consistent support for CSS3 and HTML5 yet) versus using things that we know will just work like jQuery, CSS2, and good old fashioned HTML4 (and I shudder to think a bit of Flash for some audiovisual goodness)?

  21. 21

    This is really very good article. i am looking forward


  22. 22

    I think that providing a minified version of a plugin is bad practice, as it encourages developers to use the files individually without a concat/minify build process.

    I can’t stress this enough: If you care about performance, you need a build process!

  23. 23

    “I definitely don’t think you should build sites that only run well on fast connections”

    Welcome in the world of flashsites! ;-)

  24. 24

    Though you make a good point, part of being a “developer” is to push the boundaries of what has been done before. In order to continue making advances and keeping your customers satisfied, you have to balance the newest and most exciting technology while still making the system degradable for users who are not early adopters or aware of changing technology standards. Personally, I’ve found it works best to plan what features you want to include in a project and plan through how to gracefully degrade the system for users not able to see HTML5 and CSS3 before you ever write any code. Such as including rounded corners, but not requiring them in order for the design to look correct. That way you don’t have to rewrite, or hack-up your design or code in a post-development mad dash to get everything working.

  25. 25

    I agree completely with this. Bandwidth considerations are so ultimately important. Google indexes based off page load speed, mobile browsers struggle with several connections and transferring, and of course your own bandwidth costs.

    Why waste resources if its unnecessary and only done out of laziness?

    If a plugin is over 500kb in size after minification, I’d wonder what kind of monstrous code is lurking in the obfuscated darkness.

  26. 26

    Zach, well what you said only makes sense if the minified version was the ONLY version available. If you think that by removing a minified version the end users will start using a build process, I think that may be hopeful wishing.

  27. 27

    I’m with you! May as well write a few lines of your own with very clear selectors to which elements are targeted etc. and you still have 100% control over every aspect of it with a smaller file…

  28. 28

    Forget user-level bandwidth, if you’re building high-traffic sites, every kilobyte you save on every pageload can reduce the # of servers you need to run a site. Think big, not small!

  29. 29

    @Andrew Douglass

    I’m a web blogger that often writes about HTML5 and CSS3 :)

    Consequently, at the company I run, a large majority of our users are also still using

    That doesn’t in any way mean that I’m being college-student like nor unrealistic in recommending people use HTML5/CSS3. The reality is that its not all that difficult to offer cross-browser compatible experiences these days.

    Simply look at Modernizr, HTML5Boilerplate, CSS3Pie etc – there are many ways that one can provide modern design experiences to those whose browsers accept them and ‘compatible’ experiences to those who do not.

    The idea is that we don’t to prevent the evolution of the web just because people are still using IE6.

  30. 30

    I would posit that one should grok the plugin’s source before implementing on a production web site. If you cannot understand what’s going on from that, your problem is not the plugin, but your lack of understanding as a developer. Seriously, one of your reasons for “red flag”-ing a plugin is the lack of a single line of code in a return statement. That is easy to remedy and if you are red flagging an otherwise awesome plugin because the options it takes aren’t to your liking, you may be the problem, not the other way around.


↑ Back to top