I better do some explaining after that unnecessarily provocative title… jQuery is obviously a fantastic JavaScript library and has been my tool of choice for quite a while now, and it’ll probably continue that way until something better comes along. What I wanted to discuss today though has nothing to do with the technical aspect of jQuery but rather the plugin culture that’s formed around it and some of the possibly negative effects of this culture.
The problem I’m about to outline may be inherent of other plugin cultures within other libraries too but I won’t dare mention them at the risk of starting a flame war. This isn’t really about jQuery, this is about a much larger problem which has proven to be unavoidable and unstoppable on a platform as pervasive as the internet.
So here’s the problem: Joe Average needs some “cool JavaScript stuffs” to impress his client – he hops over to the plugin repository (more likely, Google) and searches for some specific jQuery plugins. After choosing the plugins he desires he will delegate to each one a certain chunk of responsibility – the cycle plugin gets the featured-banner, the validation plugin gets all the forms, and the tooltip plugin gets the navigation menu, and the list goes on. By the end, Joe has 5 plugins he wants to use on his newly developed website. So, like any innocent developer he sticks them all in the <head> and calls it a job well done!
There are over 3000 plugins in the jQuery plugin repository and probably multiples of that amount floating around elsewhere. With so much functionality at the tip of our fingers it’s no wonder that most of us have succumbed to the notorious copy-and-pasting-syndrome.
The jQuery plugin culture is essentially just an extension of this. Sure, many of the plugins are much more reliable than any random code snippet but it’s still the same. I think this “syndrome” protrudes most significantly into jQuery because of its popularity amongst people that have no interest in JavaScript whatsoever… I’m talking about the thousands of designers and interface-engineers who use jQuery on a daily basis yet have no interest and very little knowledge when it comes to JavaScript and its various abstractions. To these people it seems okay to bombard users with a symphony of jQuery-chaos at the expense of many-hundreds of kilobytes of mostly-useless JavaScript code.
The most popular jQuery plugins have been made to suit many different situations. Let’s take the “cycle” plugin by Mike Alsup as an example – it’s a very well built plugin that is very easy to integrate and even simpler to customise. The one problem with it though, and this is inherent of all the most popular plugins, is that it tries to cater to every conceivable usage at once. This results in 20kb (at minimum) of mostly unused code. Most users of this plugin will probably use only one or two of its features on any particular website. If they were to write the desired functionality from scratch than I doubt it would take up any more than 2kb. I may be over-simplifying and making many assumptions but it’s an undeniable fact – there is a problem with this plugin-model. As it currently stands, the model offers only a marginal benefit to the user… suddenly, it’s all about the developer!
There’s an obvious cost – if building the functionality from scratch results in only 2kb yet using the plugin is a monstrous 20kb then the cost of using the plugin is 18kb. We don’t feel the brunt of it though – it’s our users that suffer. Note that I’m not talking about the monetary cost (as a business would see it); and this really shouldn’t be considered at all – when it comes to doing the right thing, money is no object!
There are obvious exceptions to the outlined problem though; not all plugins try to do everything at once and not all plugins are that huge but the crux persists: these plugins are used as if they were throw-away snippets, integrated on a whim by some designer that thinks “jQuery rulez!”
This is probably contrary to the concept of code-reuse but this is what I tend to do: If I need a piece of functionality and if I know how it’s achieved then I’ll build it myself. Some may think it foolish to constantly re-invent the wheel but I would have to disagree – doing this allows you to progress as a flexible developer – one who can confront many different problems without having to rely on multiple abstractions.
There are times when I’ll gladly use someone else’s code but it’s normally only when that code caters to a very specific problem that is quite unique and difficult to solve. For example, I use the history plugin a lot! It does just one thing and it does it very well!
jQuery itself is a massive abstraction and has closed the gap between those-who-can’t and those-who-can. Do you really need any more? I’m not saying you should stop creating and using plugins, I’m simply saying that the usage of any particular plugin needs to be carefully considered! Remember, it’s not about you, it’s about the users!
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
I fully agree.
For me, every time a client wants a ‘lightbox’ style photo gallery I have to then import the whole jQuery library just so I can then import a jQuery plugin (like ‘slimbox’) that creates the required functionality.
That is just obscene for the end-user who has to download all that JavaScript for one page (and simply because it would take forever for me to sit and write the code myself from scratch).
I’ve tried looking for ‘library agnostic’ code but they all rely on a framework.
James,
Some good points about plugin-itis. But remember, there’s always going to be “webmasters” who simply, download, cut, and paste code. In any framework. In any language. The very word – PLUGin – implies a behavior that is easy to accomplish. And this is by design.
As for Mike’s jQuery Cycle plugin, he acknowledges the size of the standard code required to do so much, and offers a “lite” version:
http://malsup.com/jquery/cycle/lite/
which weighs in at just 3KB minified, and is designed with just the core slideshow features in mind.
— SEAN O
One thing developers should start doing (if they’re not already) is to stop downloading jQuery. By letting the Google AJAX Libraries do the hosting for you, you can reduce your server load, and your users’ download latency (thanks to Google’s CDN), meanwhile allowing more parallel downloads of your local content.
Additionally, due to jQuery’s current-day ubiquity, if more developers linked to the jQuery Library via Google, most users would already have it cached on their system as well.
Click here to learn how to implement this.
Its a fair point you make, but its not just limited to plugins, jQuery or otherwise. Any large framework is just as susceptible to unnecessary bloat (that is, anything not required to achieve the developer’s main task) as any plugin; the fact that you decided to make your own ‘mini’ CSS selector is indicative of that.
@Mark, It might be worth crafting something yourself – you’ll know exactly how it works and it will (in the long run) save you time (and your users’ bandwidth) in future projects.
@Sean, good point about the word, “plugin”. I didn’t originally intend to pick on any particular plugin but Alsup’s Cycle plugin seemed the obvious example since it’s both large and extremely popular. I didn’t realise he’d made a lite version – thanks for the link!
@David, absolutely, anyone not doing this better have a good reason.
@Graham, I agree – it is just a tiny part of a much larger problem. All these do-everything-plus-the-kitchen-sink libraries really don’t help matters…
James, you could make the same argument for the underlying library itself, jQuery. Or dojo, or YUI, or whatever. On any give page, most of the library code will go unused, so the cost of the library is most likely far greater than the delta cost of the plugin. But that’s a cost inherent to abstraction layers and convenience plugins. In many projects there is a build-vs-buy decision that takes place where these factors are considered, along with other factors and requirements, such as deadlines and skillsets.
As for the specific case of Cycle, I agree there is overhead in handling many features and edge cases (and I realize you’re just using it as an example). I noticed early on that scope creep was inevitable based on its popularity and the volume of the feedback I was receiving. That’s why there is also a Cycle Lite plugin. As Sean pointed out, it’s 3kb and focuses on doing one thing well, managing a fade-animation slideshow. It’s been available for over a year and in that time I’ve not added a single feature.
David’s comment about using a CDN is spot-on. Wouldn’t it be cool if there were a public CDN that devs could upload versioned plugins too? Google’s AJAX CDN covers the big guys, but what about the smaller guys?
Cheers!
Nice post James. I was thinking about excactly the same thing this morning and decided to replace a jQuery plugin with my own code, saving about 12KB.
And David is right about the Google’s CDN, we all should use it.
Yes James, you are right about plugins, and the suggestions are always welcomed. The plugin you made for text area auotresizer is very small, but I have seen some foolish implementation of it, where the complete jQUery library was included just to get that text area expand automatically.
As per the solution by David about the CDN is nice and is time and resources saving.
I have one doubt/suggestion. what if we make use of the Google CDN to get the updated jQUery (or in that matter any other javascript library) as the firefox addon and store it in some place on our system. so whenever browser is trying to make the request to the google hosted js code, it just copies the updated one into the cache from the system itself rather than pulling it from the server. so once in a while we updated the extension which downloads the jQuery code on to the system and whenever there is the request it just puts it into the cache someway or the other and voila.
I don’t know how much possible it is since I am unaware how firefox extensions are handled, but by the quality/variety of addons available, even this should be possible.
I am curious to note that Mootools has not been mentioned here yet. Believe me I am a jQuery fan and use it more than mootools. But I have always seen Mootool’s offering developers the chance to mix and match stuff that you actually need.
http://mootools.net/core
可能有一天jquery会变成这种形式：
include(‘core.js’);
include(‘event.js’);
include(‘ajax.js’);
…..
而jquery的plugins也会用这种形式
…
这样就尽力实现按需加载
少点浪费没有用倒的代码
lack of real Integration is definitely a problem with the way people are using JavaScript at the moment. With the amount of widgets you need on an average site you need to be able to quickly configure your library builds, and lazy load everything you don’t need on initial page load.
I think plugin creators should always try to offer their plugin’s in smaller pieces, just like mootols and jQuery UI does. But i guess it takes so much time for them to create something like that, so it’s usually done just the way malsup has done – one big thing with lots of features and one same much much smaller thing that focuses on just one funcion.
Couldn’t agree more. I use about UI plugins and a couple more like $.cookie, thickbox and some others with specific usage and apart of this I write my own stuff whenever I need it. Using over pumped plugins that maybe are not even maintained is not a good idea for a long time project susteinability.
Totally agree, but give me a chance to talk 🙂
I started recently with JavaScript and to find all those capabilities under my fingers and not to use is really harsh! I cannot write a slim box script cause I am still a noob!
I thought of what you said before. I am using the frameworks together with the plugins BUT at the same time I am learning more and getting deeper into JavaScript so someday I can stop using others code and invent my wheel.
What’s the problem with it?
bandwidth? Google CDN is here to help! download time? It’s just 20k and even with my dial-up speed it will load in just 4 or 5 seconds… CPU usage for tools that are not really going to be used? I think time of human is more important that time of the machine. If jQuery for example saves the time to do a job, fine, use it.
@Mark McDonnell: There is this TinyBox which is only 4k and does nor rely on any library/framework.
I agree with the sentiment, but it’s one of those where you have to pick your battles. Every framework and higher order language that abstracts has costs for the abstraction. Depending on how much of a purist you are, we should all probably be coding in assembly (ever see what folks can do in 4KB?).
Besides, agreeing with some of the others above. The size of the scripts one uses on a page isn’t too bad considering the speeds nowadays combined with subsequent caching, even with the 1st hit costs. There’s bigger fish to fry… like reducing someone’s 225KB background image to something a touch smaller 🙂
@Hassan
You must think big, if your site is huge and lets say that js file is downloaded 1,000,000 times a day, that is 30M per month.
30M * 20kb = 600,000,000 kb = 585937.5 mb = 572.20 gb
If you have that same script down at 2kb that is 57.2 gb.
I know it sounds silly but i think you should build any web site the best you can. Just because that site is not new twitter or something doesnt mean that you shouldnt optimize it.
Oh and server bandwidth is ridiculously expensive…
“like reducing someone’s 225KB background image to something a touch smaller”
Thats another topic… 😛 But also very important.
Before someone start flaming me for previus post, i do know about caching, i am just saying that 1M of new users(without cache) come everyday… 😛
@GaVrA: Totally agreed with you. But as you say, most of web pages we design is not going to be the new twitter. And your’re right, we should do our best, and I think using a 20k script to make better user experience is one of them! It’s not a big deal! 🙂
Well i wish it all would be that easy… 🙂 I mean like here i am and i say “im going to build new twitter”! As if… 😀 Thats why i say its better to do everything the way you would do for imba mega sites and if you get lucky there would be sooo much less work to be done when you DO start to optimize your site.
I am not talking about that “its not a big deal”, and neither is James(i think), its weather you should use 20k script and use one of its function or make/pull out that one function and put it into 2k script – that is the issue here.
Ofc if you are using every possible function 20k script offers you – then thats ok because there is no useless code. 😉
The YUI3 library aims to solve the problem presented by this blog post. Instead of plugins that “do it all” and therefore contain a lot of code that you won’t be using, YUI3 emphasizes a type of granularity where you only use the pieces of a module (plugin) that you actually need.
Check out this video for more information:
http://developer.yahoo.com/yui/theater/video.php?v=desai-yui3
BTW, you all of course know, root of what is pre-optimization?
I gotta agree with you on this, I usually prefer to write my own JS to do the specific task at hand instead of getting a plugin that does what I want, and a hundred other things. Keep it simple, keep it clean.
I’d have to agree that 99% of the jQuery plugins come packed with a solution for every possible problem adding bulk to the plugin.
However, I wouldn’t specifically state that there is a problem with the jQuery plugin architecture but the plugin author.
It’s entirely possible for a jQuery plugin author to make their plugin modular and load extra scripts as required by the options passed to the plugin.
Cycle does not do this but I would imagine someone has done it before.
> “This is probably contrary to the concept of code-reuse but this is what I tend to do: If I need a piece of functionality and if I know how it’s achieved then I’ll build it myself. Some may think it foolish to constantly re-invent the wheel but I would have to disagree – doing this allows you to progress as a flexible developer – one who can confront many different problems without having to rely on multiple abstractions.”
This is the single best advice you can give to many web developers. This is exactly what I am doing, I’m writing my own jQuery plugins for things quite popular, like form replacements etc. This is also the reason I started to develop my own CMS. Even I sometimes think that it’s reinventing the wheel but my “wheel” will be different, will suit my needs and the feeling of accomplishment rewards everything.
Maybe things I craft will not be as flexible and as durable as ready-made plugins, but I can improve then all the time, I can write HOW I want and WHAT I want.
And the amount of knowledge you gain by simply researching, tweaking, trial & error is immense!