I’ve pimped a lot of jQuery plugins, both here and in my articles for IBM developerWorks. On each occasion, I’ve praised the plugin model for its ability to keep core libraries small while still offering a sanctioned way to share reusable components with the open-source community.
I’m not taking any of that back. But after a few weeks of rapidly iterating on user-interface features for a new client, I’ve come to a different conclusion: I’d rather spend time building my own custom UI component than wrangling my code to work with somebody else’s plugin. When I write my own custom widgets and event handlers, I can accomplish the following:
-
Solve small problems with small solutions
Many jQuery plugins attempt to be many things to many people. The result is code that – although clean, reusable and heartily battle-tested – carries a far larger footprint than custom code that does only exactly what I need. The best plugins ameliorate this tendency by offering customizable builds of only the classes you need. Still, when you write the code yourself, any bloat is your own responsibility.
-
Solve my clients’ problems rather than the plugin’s
Some jQuery plugins offer great looks; solidly implemented, cross-browser compatibility; an intuitive API; wonderful support for progressive enhancement; or wonderful coding technique from which to learn and borrow. Few offer all of these advantages.
I’ve often used Thickbox for my lightbox needs, but according to its author, it’s really a code demo that grew out of control. If you look under the hood, it’s a big collection of unscoped global functions. Like many jQuery plugins, it makes lots of assumptions about how you’re going to build your HTML and CSS. By the time I get done figuring out how to work around those assumptions, I may as well have built my own solution.
I don’t mean to dump on this popular plugin. Creator Cody Lindley has released it under a liberal MIT/GNU License, which allows me to pick it apart, refactor it and benefit from his hard work. When and if I build a home-grown lightbox solution, I’ll no doubt pick through his code and benefit from lessons he learned the hard way about, for instance, IE6 support. I’m grateful to have it out there as an example, if nothing else.
-
Learn from my mistakes
If I spend hours trying to figure out how to get a plugin to meet my specific needs, all I’ve learned is how that plugin works. If I spend hours trying to figure out how to meet my specific needs by writing custom code, I’ve no doubt wasted a lot of time with false starts and dead ends. But I’ve actually learned something about JavaScript, jQuery and application design in the process.
-
Avoid beta-testing other people’s code
The best jQuery plugins can teach individual JavaScript authors lots about the design of reusable, cross-browser components. Even these examplars suffer from their share of bugs. If you write your own components, you know where the blame lies for problems that crop up in production on some obscure browser + platform combination. Better yet, you know the code well enough to dive in and start fixing things immediately. Not so with some open-source plugin whose source code you’ve only ever seen in minified form.
I’m a mootools user myself, but the plugin system is essentially identical. I’ve often attempted to “customize” some plugins to fit my needs, but then realize (after spending too much time learning the code) that I might as well write my own that accomplishes what I need it to from the get-go. Not only do you learn from the experience (everyone loves finding more IE6 quirks), but later down the road when you get that flash of inspiration you can jump right into the code without having to learn any logic. In fact, I can only think of one plugin that I was ok using “out of the box”, and that was using Slimbox for image links on product pages.
The only plugin that I think would be a real pain to code yourself would be a WYSIWYG editor. I spent a week just back-porting MooEditable to be compatible with mootools 1.11 (admittedly I also spent some that time adding extra regular expression parsing to make the html output w3c valid and identical across browsers).
If nothing else, you can use plugins to reuse your own code. And borrow from anyone else to learn how to do that properly. I think that alone makes plugins already worthwhile.
Anyway, you hit a good spot. Most plugins do a lot, but not what you actually need. Mails like “yeah, great plugin, but…” are the standard for most plugin author.
So the really hard problem is to find the right abstraction, like jQuery did: Identify a problem, and provide an abstraction that adapts to all variations of that problem.
The plugins I consider really good abstractions are those low-level components in jQuery UI, and my validation plugin. Both abstractions adapt to a lot of variations, though surely not all of them.
What plugins did you find worthwhile?
I completely agree. I feel this also applies to other libraries that have a “core” and then multiple layers on top. In YUI I use yahoo-dom-event, and the rest I do myself. I know those three libraries are rock solid, and they do exactly what I want a JavaScript library to do: abstract away the browser differences. The rest is just plain old JavaScript, which is exactly how I want it.
I agree with the sentiment, and often make the same decision, but I think it comes down to being able to assess how useful a given plugin really is for a given situation, and properly budgeting your time to make that assessment.
As we’re developing, if we identify a need so general in nature that we suspect a plugin might have already been written to meet it, of course we’ll look, and more often than not, we’ll find at least one, if not more, options available.
It’s easy enough to try them out, and if they don’t meet our exact needs, it’s usually just as easy to determine whether it would be faster/simpler to tweak the plugin or write our own solution. I certainly appreciate having the choice, as well as the opportunity to contribute alternative solutions to the community from time to time.
Scan through the plugin code, identify places where the modifications you need might be applied, and take a quick stab at it. The key is giving yourself a limited amount of time to patch the plugin (admittedly hard to do sometimes once you get into problem-solving mode) before dropping it in favor of a different solution. After all, if it’s not saving you time, what’s the point?
[...] opined recently that jQuery plugins can be more trouble than they’re worth. That said, they’re often indispensable. True, the worst plugins suffer from bloated code, [...]