Skip to content. | Skip to navigation

Personal tools


You are here: Home / Steve's Blog / Plone and jQuery Tools

Plone and jQuery Tools

Posted by Steve McMahon at Jun 09, 2010 05:00 AM |
Filed under: , ,
Plone 4 uses the ultra-lightweight jQuery Tools set for basic UI. Here's why we chose it.
Plone and jQuery Tools

Popup form to add a new user

The two most obvious cosmetic changes to Plone 4 are its clean and modern theme, Sunburst, and the addition of popup forms for AJAX modal dialog functions like login, contact form, user addition and history views. (This is, of course, literally the surface of the great new feature set for Plone 4. See the roadmap for a quick view of the change set.)

Behind the slick popup overlays is a gem of JavaScript programming, the ultra-lightweight jQuery Tools UI library from the same folks who created FlowPlayer. jQuery Tools takes care of overlays and tabs in Plone 4, and we've also included in Plone 4 the tools' tooltip and scrollable libraries. And, there's some Plone-specific code that allows us to turn a form page into an AJAX overlay with just a few lines of JavaScript. This is built into Plone 4, and may be added to Plone 3 by installing the package.

The key jQuery Tools components will add an amazingly small 4kb of weight to the basic Plone page download. For logged in users, the average page size will sometimes be smaller than before, since we took advantage of the overlay facility to separate out page history into an AJAX popup. (For which, we also got an impressive improvement in page rendering speed. The rememberance of things past turns out to be computationally expensive.)

Despite the small size and general coolness of jQuery Tools, its addition to the base Plone package was an occasion for serious consideration and some debate. First of all, no third-party library is added to Plone's dependencies without some serious examination. Second, we know that many Plone developers have their own choices for JavaScript UI libraries, and the Framework Team didn't want to pick sides without good reason. But, we were also aware that if there wasn't any leadership on this, we'd soon end up with multiple UI libraries in commonly used add ons.

Tools, Not Policy

Candidates for our UI kit had to be jQuery-based. And, it helped that jQuery Tools is tiny (around 12kb minified and under 4kb gzipped). The small size isn't just great coding (though the code quality is excellent). It's the result of intentional minimalism. jQuery Tools isn't a framework, and it doesn't carry a design philosophy beyond being CSS-centric. For our purposes, that was great. Plone has its own user-experience philosophy and well-thought-out CSS structure. We didn't want a JS/UI kit that we'd have to code around or to which we'd have to adapt.

Why not jQuery UI?

The jQuery Project's jQuery UI library is an obvious point for comparison. I discovered at the recent jQuery Conference that many jQuery fans don't distinguish between jQuery UI and jQuery; in their minds, they are one and the same, and they don't understand why anyone would pick jQuery, but not jQuery UI.

jQuery UI is a very credible candidate if you're starting from scratch and willing to take its UI design philosophy for your own. Employing jQuery UI pretty much means that you'll be starting with its CSS theme kit as the basis of your style. Or, you'll have a lot of CSS bloat to support your jQUI visual components.

Also, JavaScript's support for object-oriented development is shaky. It's great for light-weight objects coordinated with an event-messaging system, but if you try to design like you're using class-based inheritance, you end up with big objects (code-wise). And, when you add functionality, they have to get bigger, as there's no multiple inheritance and no component architecture. jQuery UI (very much unlike jQuery) is built with this kind of structure. That's not necessarily a problem if your theming is built around jQuery UI, but I can't help but be reminded of where we ended up with Archetypes. It works, but you've got to buy into way too much to get going. Buying into way too much, in this case, means buying into a lot of CSS and JS overhead. Probably ten times as much to achieve just the basics.

And then, since the widget design philosophy is very different from that of HTML5, we might just be ripping out a lot of it not that far into the future....