Archives

The first two installments haven’t even been published yet, but I spent most of last week hammering out the third entry in the series I’m writing for IBM developerWorks. The first two installments tackled things like modal dialogs, tooltips and lightboxes. But for the latest piece, I delved a little deeper into full-scale Ajax by showing readers how to load page fragments and images on the fly into tabbed interfaces and image carousels. As before, I enjoyed writing for a more beginner/intermediate audience. And I especially enjoyed the chance to play with jQuery and all of its shiny new plug-ins.

Inspired, perhaps, by the success of YUI and Ext, all the big JavaScript frameworks are releasing companion libraries of packaged, themable UI widgets. jQuery is no exception. My latest IBM piece uses jQuery UI Tabs, one of many components in the new jQuery UI framework. UI Tabs began its life as a standalone plug-in. With the launch of jQuery UI, it has become more tightly integrated with the other components. Ultimately, that’s the lure of an umbrella concept such as jQuery UI: fewer far-flung extensions of unknown provenance; more plug-and-play efficiency.

When I was first getting acquainted with jQuery, I blogged about it quite a bit (here, here and here). There was a lot I liked, but I got easily frustrated. Having previous experience with Scriptaculous, I found the built-in effects features and even the Interface plugin a little under-featured. In particular, the lack of fine-grained queue control bothered me. I also struggled at first with jQuery’s lack of built-in object and class factories. I engaged in back-and-forth with jQuery team members about my posts. Then I moved on to other projects.

Recently, however, I returned to jQuery for Ajax Overhaul, my upcoming series of tutorials for IBM developerWorks. Ajax Overhaul tackles how to improve the user experience of dusty pre-Ajax applications with unobtrusive JavaScript. My series shows how to install lightboxes, modal dialogues, form validation and other Ajax goodies with minimal changes to server-side infrastructure. It was therefore imperative that I use a toolkit engineered from the ground up for progressive enhancement. Naturally, I thought of jQuery.

In the process of writing the first couple of installments, I discovered the not-so-secret ingredient to jQuery’s success: the plugin ecosystem. By officially sanctioning a broad range of plugins and providing hosting, support and PR for mature plugin libraries, the jQuery team has galvanized a really impressive developer community. So far in my writing for the IBM site, I’ve used Greybox, Thickbox, jTip and jQuery Forms – all really fantastic tools that empower even novice Ajax programmers to do really cool things with very little custom code and 100% adherence to progressive enhancement.

As long as plugin authors follow the rules, their libraries offer the same compatibility as the core jQuery distribution. (See this post, including comments, for details on how to write plugins that don’t create namespace collisions.) My only gripe with the plugin landscape is that it’s so scattered. Despite the availability of hosting on the jQuery servers, lots of plugin authors opt to host their own sites. There’s no one-stop shop like the one for, say, Firefox.

I still haven’t found a good plugin for managing classes, mix-ins and other inheritance schemes, but just by typing that I’m sure I’ll get comments to the contrary. Regardless, it’s easy to use jQuery alongside, say, MooTools.

As for my desire for fine-grained control of jQuery’s effects queues, all it took was one enterprising plugin author. jQuery team member Rey Bango pinged me a few months ago about developments on this front, and now the code is live. I haven’t yet worked with Luciano G. Panaro’s Fx Queues plugin, but at first glance it looks like exactly what I need. As Really Simple History matures, I’m looking to get involved in other open-source projects. Contributing to the jQuery ecosystem is at the top of my list.

Technorati Tags

• jQuery
• JavaScript
• Ajax

Prototype and Scriptaculous had their origins in Ruby on Rails before spinning off. There they went head to head with the lighter, leaner JQuery. Now the circle is complete, with Scriptaculous functionality on top of JQuery making its way back into RoR in the form of JRails.

jRails is a drop-in jQuery replacement for Prototype/script.aculo.us on Rails. Using jRails, you can get all of the same default Rails helpers for javascript functionality using the lighter jQuery library.

This is certainly good news for folks who do a fair bit of mashing up. Combining two sites or services, one of which uses Prototype and the other JQuery, can be a bit painful.

Technorati Tags: ajax, prototype, scriptaculous, jquery, ruby on rails

It’s nice to know you’ve inspired someone and it was very nice of Chris Anderson to drop us a note on his own Bookmarklet: Make it Play. Basically, this bookmarklet will scan a page for mp3 links and then insert a little semi-transparent media player interface at the bottom of the page.

It’s not SongBird, but it’s a good demonstration of the power of Bjax — injecting user interface to improve an existing web interface. Based on JQuery.

Technorati Tags: ajax, jquery, bookmarklets, bjax, mp3

There’s never been a better time to be a JavaScript developer. JS hit the big time with the advent of Ajax, and overnight client-side programmers went from being the redheaded step-children of the web-development world to front-and-center participants in the RIA revolution. Even if you’re working on a team of one, there’s a thriving global community of JavaScript gurus constanly pushing the language forward, working out browser kinks, demonstrating how to import concepts from other languages and computing paradigms, and otherwise inspire you. It’s a big change from 10 years ago, when you had Webmonkey and the David Flanagan book and a few cookbook-style compendiums of tips and tricks. This is seriously the golden age.

Working for the last couple of months on Really Simple History, though, I’ve become interested in the way specific techniques become the flavor of the month and quickly redefine how we conceptualize "good" JavaScript coding practices. Take, for instance, DOMContentLoaded. After the first version came onto the scene, within a matter of months we had many competing implementations of the basic concept that your scripts shouldn’t have to wait for window.onload to fire before getting down to business. Now, DOMContentLoaded is the de facto start point for many, many JavaScript applications. Heck, it’s even the basis of the entire jQuery event model. There’s nothing wrong with that, but widespread use of Ajax toolkits can conceal the fact that DOMContentLoaded is just a collection of hacks. It works, as long as our toolkits keep iterating one step ahead of the browser vendors. But do we really need it?

At Orbitz Worldwide, my previous employer, we implemented a first-rate unobtrusive-JavaScript architecture. (See it in action at Ebookers UK.) Everything was progressively enhanced from dumb markup. That meant our application worked just about everywhere. But it also meant lots of DOM parsing and initialization that couldn’t begin until window.onload. As our application grew, this caused enough of a UI flicker – form controls turning into widgets, links morphing into Ajax calls – that we needed to jump the gun on window.onload if we wanted a good experience for the majority of users … the ones with modern, JS-capable browsers. DOMContentLoaded made sense, and architect Nik Krimm pounced on it.

But for a large subset of websites, there really isn’t THAT much difference between window.onload and DOMContentLoaded. If you’re merely adding an unobtrusive behavior layer to a traditional, content-driven website, chances are that good old window.onload will perform just fine. There’s usually little reason NOT to use DOMContentLoaded. But unless you are developing a desktop-style webapp or implementing progressive enhancement on a foundational level, it’s not really necessary. And in certain cases, it just flat-out won’t work.

An enthusiastic beta-tester discovered such a case when trying to initialize RSH’s dhtmlHistory object from DOMContentLoaded. It broke, and I immediately knew why: RSH relies on the ability of modern browsers to auto-save form data for the life of a session. RSH uses a hidden textarea to cache serialized Ajax application state and render the back button useful again. Internet Explorer doesn’t repopulate the cached value of that textarea until an instant after window.onload. If you try to access that cache during DOMContentLoaded, it simply isn’t there. This is true of both IE6 and IE7. Therefore, you need to wait for window.onload.

I’m not really sure there’s any big conclusion to draw from this example. As I said, it’s just interesting to me that in the space of a year or two, DOMContentLoaded has become a de facto standard. As we pile browser hacks on top of one another to push the web forward, sometimes they’re going to conflict. Luckily, we can always peek past the curtains and figure out what’s  going on behind the scenes.

• Ajax
• JavaScript

JQuery 1.2 is upon us and, as usual, there’s already tons of carping discussion in the comments section of Ajaxian. I took a wander through the 1.2 release notes and the source code, and while I’m impressed with many of the new features, I’m a little disappointed with status quo of the Effects object. They’ve updated the queue and dequeue methods and made them public,  but effects queues continue to be maintained separately for each element. This was a real stumbling block for me when I took jQuery for a test drive on a demo project last month. Compared to Script.aculo.us’s global effects queue, jQuery’s element-by-element queues provide far less precise control for combinations of effects on disparate nodes. It’s difficult to coordinate the timing of effects when you want, for instance, to pause the processing of all effects globally in response to an event, then restart some or all of them. The queue and dequeue upgrades are a step in the right direction, but I’d love to see a truly global effects queue that can be sliced and diced into named or element-based sub-queues as appropriate. In the meantime, I’m starting to agree with the widespread belief that jQuery is great for quick, unobtrusive effects but less appropriate for complex, large-scale applications. Am I just missing something? Would this feature be overkill for a library with jQuery’s stated aims? Let me know in the comments.

After brushing up on jQuery via a little light reading, I’ve started to play with the framework in code. I’m demoing a scrolling news ticker and decided to write it using jQuery and its Interface plug-in. Future iterations will probably include the history and easing plug-ins, too. In the meantime, though, it’s been two steps forward, one step back. I really dig the elegance of the jQuery API and its concise method-chaining. But there’s one integral element of the Prototype/Script.aculo.us framework that I miss: The Class object and the OOP training wheels it provides.

For developers like myself – long-time UI folks who have used JavaScript’s Object datatype for years but lack significant experience writing in a strongly typed, truly object-oriented language like Java – Prototype has been a revelation. It doesn’t enforce OOP principles, but it encourages them. And its source code is like a Rosetta Stone for how to implement them in the dynamically typed, prototype-based world of JavaScript.

There’s been lots of discussion over the past year about the deficiencies of Prototype’s inheritance scheme. A lot of the syntax is ugly, and Object.extend is easy to overuse or misuse. The new 1.6.0 release candidate appears to address some of those weaknesses by augmenting the Class object’s API. Regardless of your position on this debate, though, it’s hard to ignore the fact that Prototype has helped a lot of front-end folks improve their half-assed understanding of OOP. Personally, I wouldn’t even be in a position to follow the discussion if I hadn’t spent the last 18 months or so writing Prototype-backed JS classes. Thanks to the patterns to which this library has exposed me, my grasp of JavaScript – and of software engineering in general – has grown by leaps and bounds.

Once I started using a different library, though, Class.create was suddenly useless. I had to figure out different inheritance and encapsulation strategies. The training wheels were off, and I had to find my own of balance. My first hurdle was figuring out how to organize my jQuery procedures into reusable methods. I felt totally adrift without the built-in ability to bind functions to their execution environment; the this keyword was always assigned to a DOM node. I thought about simply porting Prototype’s Function.bind and Function.bindAsEventListener methods, but that seemed at odds with the design of jQuery’s own API. Finally, I turned to Douglas Crockford‘s module pattern for JavaScript. Now I had a new way to organize my objects and methods in a reusable way that worked well with jQuery. By defining private methods inside of a closure, I could access those methods with simple function calls, no binding necessary. As with Prototype, a whole new world opened up.
   

A lot of developers worry that Ajax frameworks make for lazy programmers, but in my experience the opposite is true. Each new design pattern or framework that I play with teaches me new approaches to JavaScript and OOP in general. Folks coming at UI development from, say, a C++ background may want a framework that enables a well-defined inheritance model. But OOP scaffolding is a separate concern from Ajax and DOM tools. Prototype provides both, while the base jQuery library provides only the latter. Still, somebody could easily write an OO plugin for jQuery – or several of them, each implementing a different inheritance model.

Simon Williamson’s recent post on jQuery for JavaScript programmers does a good job of explaining how jQuery encourages good OOP techniques. The walled-off namespacing represents a different conceptual model from Prototype’s. Until you understand both, it’s difficult to see all the strenghts and weaknesses of either. As with other tool, the key to these frameworks is learning what tricks and tradeoffs each one supplies, and why. Up next: YUI and Ext.

Related Services:
Ajax Rich Internet Applications, Custom Software Development