As someone involved with a decent amount of Rails programming over the past year, most of my work in Javascript frameworks has centered on Prototype and script.aculo.us. And with good reason — both are enormously capable and, with Prototype at least, extremely well documented. They create beautiful effects and nearly painless AJAX, they integrate really well with Rails, and there’s a wide community of users you can slot yourself right into. I’ve used some other frameworks as well — made interfaces with ExtJS and messed around with MochiKit some — and I’ve discovered that every one of these things (with the possible exception of MochiKit, which seems to be essentially abandonware at this point) has a specific niche to fill.
But for the most part, what all these things have in common is that they seem to have been created with web application interface development in mind. They’re not all that well suited to the set of one-off needs that crop up with general forms and lead generation tools on your average small site, but a lot of people end up using them for that anyway because they remove some of the tedium from JS. Numerous blog posts have been written about the phenomenon of people including the entirety of Prototype just to make tiny, “DHTML” DOM manipulation a little less painful, which makes no sense. Just suck it up and use JS for real. It’s not that hard.
There are some tasks that fall in between though — they’re more than trivial with bare JavaScript, but loading the entirety of a framework like Prototype is kind of like using a chainsaw to trim hedges. It’ll work, but it will be heavy and imprecise, and you may find yourself regretting all the extra work later. You still need a tool though, so what’s the solution?
A smaller, more task-oriented framework. This week, I decided that I’m a fan of JQuery. Here are the two examples from this work week that sold me:
Cycle
The Cycle plugin makes it dead simple to create a slideshow effect.
It supports pause-on-hover, auto-stop, auto-fit, before/after callbacks, click triggers and many transition effects including fade, shuffle, scroll, turn and zoom. It also allows you to define and run your own custom transitions. In addition, it supports, but does not require, the Metadata Plugin and the Easing Plugin.
The basic way it works is that you put together a div filled with the objects you want to cycle, usually other divs containing, say, an image and a caption. Once you’ve got your structure set up, you call cycle with one line, which it’s good to place at the bottom of your HTML so you’ll know all your pictures have loaded:
1<tt>
</tt>2<tt>
</tt>3<tt>
</tt>
|
<span class="ta"><script</span> <span class="an">type</span>=<span class="s"><span class="dl">"</span><span class="k">text/javascript</span><span class="dl">"</span></span> <span class="an">charset</span>=<span class="s"><span class="dl">"</span><span class="k">utf-8</span><span class="dl">"</span></span><span class="ta">></span><tt>
</tt> $('#mydiv').cycle();<tt>
</tt> <span class="ta"></script></span><tt>
</tt>
|
You can add all kinds of options in the call to cycle, but the bare effect itself is pretty pleasing and is frequently exactly what a developer is looking for.
UI.Datepicker
UI.Datepicker is part of the JQuery UI library. You can think of UI as being script.aculo.us to JQuery’s Prototype — it’s built on top of the JQuery core and provides visual effects like fade, appear/disappear, window shade, shrink, grow, etc. It also contains all the drag/drop-oriented stuff you might need, as well as several other “widgets” and interaction pieces.
Datepicker is a widget that provides a calendar. When a user clicks on a form text field which has been tied to a Datepicker object, a calendar appears. The user navigates the calendar and chooses a date, which is then inserted into the text field. Again, the implementation code is short:
You could one-line this at the bottom of your page as well if you wanted (as with cycle above), but using JQuery’s $(document).ready() enables you to ensure that the code won’t try to execute before the page is loaded, so you can keep code you might use a bunch (like a standard calendar widget) outside your HTML file in a central spot.
1<tt>
</tt>2<tt>
</tt>3<tt>
</tt>4<tt>
</tt><strong>5</strong><tt>
</tt>
|
<span class="ta"><script</span> <span class="an">type</span>=<span class="s"><span class="dl">"</span><span class="k">text/javascript</span><span class="dl">"</span></span> <span class="an">charset</span>=<span class="s"><span class="dl">"</span><span class="k">utf-8</span><span class="dl">"</span></span><span class="ta">></span><tt>
</tt> $(document).ready(function(){<tt>
</tt> $('#date').datepicker({dateFormat:'yy-mm-dd'});<tt>
</tt> });<tt>
</tt> <span class="ta"></script></span><tt>
</tt>
|
One thing I love about the JQuery UI site: you get to build your own download — i.e., you can select the pieces of code you need by feature and have the file built with just that code. Among JavaScript frameworks, I believe this may be unique to JQuery, and it makes a serious difference in the file size.
I believe that this attitude — favoring modular code, giving you only what you need so you don’t end up with page bloat — probably drives a lot of JQuery’s adoption in smaller-need situations like the ones I’m describing here. But JQuery is also the native JS framework for both Drupal and WordPress. I haven’t messed with MooTools or Dojo yet, but I think of them as being in a similar class to JQuery, and I think JQuery definitely has the momentum to draw in more converts the same way I was: dead-simple use, only-what-you-need philosophy of code distribution, pervasive understanding of the bandwidth challengers front-end web developers face.