- 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.
- 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.
- 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:
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.
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.