jQuery Plugins, Size, and Storage

There is no such thing as a JavaScript plugin contends James Coglan. I completely agree that there are no, specific, techniques within the JavaScript language that make “plugins” possible (such as the ability to namespace code and import it, or some such).

HOWEVER – I will contend that such a thing as plugins exist and are logically distinct from “random JavaScript code that manipulates other JavaScript code” as long as the following points are met:

  1. There have to be explicit points upon which a plugin can attach. James notes the most common one in jQuery (jQuery.fn) but we have tons more – events, animations, selectors – all over the board for developers to snap in to.
  2. Even more importantly: Those points have to be documented or, at the very least, be under some sort of agreement that they will be treated like a normal piece of the user-facing API. In jQuery we treat all plugin extension points as “user-facing API” and only ever change them in major releases (if at all) and always provide an alternative for authors to use.
  3. Finally, there has to be some sort of repository for navigating these plugins. This is a huge differentiator. Simply referring to “code in the wild” as plugins doesn’t really cut it if there’s no commitment to hosting them and keeping their documentation and examples alive.

We take our plugin architecture very seriously in the jQuery project and are constantly looking for ways to improve (looking at plugins, reading their code, seeing what we can provide to make their lives easier).

Alex Russell of Dojo recently built a sleek 6kb version of Dojo – presumably for use on mobile platforms. He states in his post that:

Even so-called “lightweight” libraries like jQuery are far too heavy for some environments…not because they (like Dojo) pull in all the code needed to use them, but because they do it all up-front. Often the best time to pay the expense of loading, parsing, and executing JavaScript code is when the user takes an action that needs the enhancement to run.

The way it’s worded you would assume that you were paying a large, up-front, cost to using jQuery when, in fact, there is very little overhead. jQuery has been shown to be the fastest loading JavaScript library for non-cached code and considerably fast for cached code.

Arguably a mini-Dojo would be able to provide an extra edge in this respect – however any gains that you would make up-front (which would be minimal – mini-Dojo is only about half the size of jQuery, as it stands) would have to contend with any future overhead incurred by loading additional components at a later time.

I frequently queue up long pages to read on my iPhone while I travel the subway system here in Boston and I think I’d be quite upset if I got halfway through a page, clicked a hide/show link, and found out that the action wasn’t able to work since the requisite functionality hadn’t been loaded yet.

There is a cost to loading “all” of jQuery up front, absolutely – however there are numerous benefits: It’s highly cacheable, you never have to worry about what you do/don’t have loaded, the API, documentation, tutorials, and examples are all dramatically simpler since you never have to worry about having extra components or making sure that they’re being included correctly.

And, as always, if you’re particularly excited about breaking jQuery down into little chunks you can grab the individual pieces from SVN and build a custom copy.

I was out of town when it happened but the release of the Google Ajax Library CDN (which includes the current release of jQuery) was incredibly cool. I’ve had a few requests from users wondering how this release came about. While I can’t speak for the other projects, I can, at least, speak for what happened with jQuery.

Dion and I had been discussing solutions for providing better hosting solutions to JavaScript libraries for a long time (at least a year or two). Progress kept getting stalled at different points but persevered and got the release up at Google. I’m really glad to see this come about and I’m sure that jQuery users will certainly appreciate this release.

I have a couple points of concern with the release, namely:

  • How do we push a new release out? Currently we have to contact the guys at Google to get it pushed through – a way to automate this and do it programatically would be greatly appreciated (we could integrate it right into our release scripts).
  • How do new pieces of code get added? There’s no way for other projects to get added to the repository – some sort of process for joining would be ideal.
  • SSL? Having an SSL-based CDN would be very useful, as well. However I suspect that if a site is going so far as to have SSL on their pages then they’re probably not pulling their source code from an external site.

Other than that, though, I’m quite pleased with the release. The more that people pull from there the faster it’ll be for everyone who uses JavaScript libraries (cutting away that initial download time).

Posted: July 2nd, 2008

Subscribe for email updates

21 Comments (Show Comments)

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.

Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.