Archives

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.

The culprit? jQuery’s less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.

If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries’ core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here’s a quick stab at how to trick out jQuery:

IBM developerWorks recently published my second “Ajax overhaul” tutorial. This series teaches intermediate-level developers how to layer Ajax features atop old-fashioned CRUD applications. My colleague Dietrich Kappe calls this the “Christmas tree” approach to Ajax development, and it’s a valid choice for many companies. It’s not the sexiest take on Ajax, but it often provides a lot of value for relatively little cost.

“Ajax overhaul” tackles a fictional shopping site for its use cases. Each installment examines a particular deficiency in the existing application’s user experience and improves it using Ajax and progressive enhancement. Because I focus on the interface layer, the code examples feature only client-side code. I’ve completed four installments so far, each one employing some combination of jQuery, custom JavaScript and custom CSS.

I previously posted about the first installment. Here’s the direct link to the second:

• Ajax overhaul, Part 2: Retrofit existing sites with jQuery, Ajax, tooltips, and lightboxes

Some noteworthy Ajax Framework releases have come out in the last few weeks, along with some other news of interest:

• Ext JS 2.1 and Ext GWT 1.0 Beta – Better performance, new Slider, StatusBar components. REST support (support for other HTTP methods beyond POST and GET). The Ext GWT 1.0 Beta consummates the love affair between GWT (Google Web Toolkit) and Ext that was started by gwt-ext and MyGWT, but provides the comfort of knowing that it is supported by the Ext JS folks. Note: Ext GWT is pure GWT, not an Ext JS wrapper.
• Dojo 1.1 – First off, API compatibility between 1.0 and 1.1. Unified timing loop (ala Scriptaculous) for animation effects, with increased performance. Syntactic improvements to dojo.query. Unification of XHR functionality into dojo.xhr() function.
• Backbase Enterprise Ajax 4.2 – Backbase has been in the commercial framework game longer than almost anyone. Among the new features: hierarchical data bindings and improved performance. If you’ve wanted data binding for tree widgets, have a look.
• Google Search, Feed and Translation API – I opined a while back that Google discontinued their SOAP search API because they didn’t want people reordering or otherwise manipulating their search results. Looking at the terms of use of the new REST service, you can see that this continues to be a concern:  You agree that you will not, and you will not permit your users or other third parties to: (a) modify or replace the text, images, or other content of the Google Search Results, including by (i) changing the order in which the Google Search Results appear…
• Google App Engine – it only runs Python apps right now, and it’s a preview release available to a select few, but you can already see that this is Google’s challenge to Amazon’s EC2 compute cloud. In at most a year, unless you are security sensitive — health care, financial services — or running on Windows, you won’t be building and maintaining data centers. The capital requirements for launching sophisticated and scalable online services is about to change.
• Echo3 (beta) – it’s getting close. Superior performance to Echo2. Easier development of new components. Automatic serialization of objects between client and server. All HTML rendering now done on client. Overall the JavaScript client code is now of a design quality on par with the server code.

Lots of exciting developments for Ajax developers and Web 2.0 entrepreneurs. I, for one, can’t wait to see how the Google App Engine compares to EC2 for deploying and scaling Facebook applications.

Technorati Tags: ajax, dojo, google app engine, gwt, ext js, backbase, echo3, google search

***Spoiler Alert***

Don’t read too much further if you haven’t seen “Citizen Kane” and want to be surprised when you do.

I’m a big SF nerd and lover of teen-angst dramas. (That’s why “Buffy the Vampire Slayer” is the Best Show Ever.) I love spoilers, but only when I’ve asked for them. When watching the entire run of “Dawson’s Creek” on DVD years after it aired (don’t ask), I accidentally spoiled Matt Laffey, the buddy who’d turned me on to the series, on how the big romantic triangle ended up in the final episode. I had no clue he had been saving Season 5 for a rainy day.

Since then, I have endeavored to include a ***SPOILERS*** alert in the subject line of any surprise-detroying emails – and to make liberal use of the return key to make sure the contents of such messages are below the fold in email clients with preview panes. This has made me a much more responsible citizen of fandom – though it hasn’t lessened my outrage when entertainment websites post spoilers in their headlines or intro paragraphs without warning me and my fellow geeks. (Sci fi blog io9, by the way, is pictured to illustrate the right way to do things.)

Hats off, then, to Chris Coyier of tutorial site CSS-Tricks for his recent post on using jQuery to create a Fade-in Spoiler Revealer for use on websites. My only reservation about Coyier’s technique was its reliance on JavaScript, and only JavaScript, to hide spoiler-laden content. With RSS and mobile browsing on the rise, lots of people read content in user-agents without JavaScript support. Shouldn’t we try to protect them, too? I commented to this effect on the original article, then realized that I should just write the code myself as proof of concept.

Who knew IE6 and transparent PNGs could inspire so much discussion?

When you’re churning out tips and tricks on a regular basis, you quickly learn to state things like this:

“I had Problem X, and my solution was Y given constraints Z.”

… instead of this:

“The only way to solve Problem X is Y.”

I was reminded of this lesson last week, after I posted a series of beginner-level tutorials about overcoming some of IE6′s shortcomings with jQuery. My two-part piece on transparent PNG support got picked up by the kind folks at Ajaxian, and boy did the comments come. Between the two sites, we’ve heard from 20 people so far. A few were from the usual cranky haters. (Thanks to whoever felt the need to write, “Is this year 2001? IE6 png transparency? News on Ajaxian? Good heavens…” instead of just moving on to the next post.) But the rest provided lively debate and some valuable alternative approaches to the problem.

For review, here are the posts (with comments):

• Part 1
• Part 2
• Ajaxian cross-post

And here are some of the various approaches suggested:

At long last, Pathfinder’s new website launched on Friday. To see the results of all my fiddling with Radiant CMS, point your browser at www.pathfindersoftware.com.

There’s actually no Ajax and very little DOM scripting involved in our first iteration. Just a little jQuery to progressively enhance some links. Our strategy in redeveloping the website quickly and iteratively was to use simple tools for simple problems. jQuery fits the bill perfectly. Eventually we hope to show off our Ajax chops on the Showcase section of the site. In the meantime, we got a new site up and running in two months with part-time commitments from a team of five – and that includes our client, the CEO. Result!

An in-depth look at our use of jQuery and why we dig it after the jump.

Photo: Joe Shlabotnik

In addition to the jQuery UI Tabs plug-in I mentioned in yesterday’s post, I’ve been playing with jCarousel, a fairly mature component for building DHTML and Ajax slideshows out of images or arbitrary markup. Overall, I was impressed enough with jCarousel to build half of my latest piece for IBM developerWorks around it. But despite the component’s many configuration options, I found that I had to do some hacking to bend it to my will. jCarousel can get a little confused when you load dynamic content, especially if that dynamic content includes blocks of markup rather than just individual image files. It miscalculates some widths in its behind-the-scenes DHTML trickery, causing images to load but never appear in the carousel. To get around this problem, I used the brute-force approach of applying a hard-coded width to my carousel:

//build the carousel
jQuery('#imageCarousel').jcarousel({
	itemLoadCallback: itemLoadCallback,
	scroll: 1
});

//now recalculate the width of the unordered list
//that makes up the carousel items
jQuery('ul.productImages').css("width","3012px");

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

The day has finally arrived: Ext JS 2.0 received its final public release today. Judging by the timeouts I’ve been getting all morning when trying to connect to the Ext site and blog, I’m not the only one who’s been waiting anxiously. Originally tied to the YUI framework but now a standalone library, Ext provides the best example I’ve yet seen of a completely client-side framework for desktop-style RIAs.

As Ajax libraries multiply, they need to differentiate themselves to get my attention. Ext does just that, providing a top-to-tails solution for GUI components: tabs, trees, grids, you name it. Prototype, jQuery, Mootools and Dojo provide powerful general-purpose tools for Ajax development. Ext, on the other hand, uses a component model whose baseline configuration gets you 90% of the way there and whose extensibility gets you the rest of the way. It’s a huge achievement that Ext does so while embracing Web standards and user experience design. You don’t use Ext to sprinkle a little Ajax on your Web 1.0 application; you use it to build powerful, data-centric applications from the ground up without relying on GWT or .Net to write your JavaScript for you.

For the example application I’m building to show off Really Simple History, I’m constructing parallel versions with Prototype, jQuery and Ext. Frankly, it’s the Ext version that I’m most excited to show off. I’ve been waiting patiently for a couple of months to find a hole in the schedule of busy Ext creator Jack Slocum. Now that Ext 2.0 is out there, I hope to publish an interview with him in this space soon.

With the Ext servers struggling to meet demand, you may have trouble trying to download the library, read the announcement or peruse the completely overhauled documentation. In the meantime, you can read this exhaustive Ajaxian post about all of the changes and new capabilities.

Technorati Tags

• Ext
• JavaScript
• Ajax

I committed several weeks ago to roll Really Simple History 0.6 RC1 over into a final release on Dec. 1. That’s still the plan, but I’m having trouble resisting the urge to tinker. I’m starting to see how a project like this could remain in indefinite limbo if I don’t just draw a line in the sand and release a final "hard" version that people can rely on for production code. The current SVN trunk includes a number of backwards-compatible enhancements. I’m working hard to test them all as comprehensively as possible, but I’m going to avoid adding risk to 0.6. Instead, I’ll save them for 0.7, which will come out in beta before Christmas.

The enhancements targeted for 0.7, some of them already complete, include the following:

• Configurable location for the blank.html file: You’ll be able to override the name and directory location of blank.html in case your server architecture demands that it be served from a different location.
• Automatic handling of history points whose keys contain spaces or other special characters; encodeURIComponent is my friend.
• Automatic title changes: You’ll be able to pass a third argument to dhtmlHistory.add and update the document title with its value. You’ll also be able to pass in a base document title through the options bundle so that each call to add just swaps out the subtitle.
• One-line initialization: You’ll be able to pass your listener into the dhtmlHistory.initialize without having to call addListener separately.
• Private methods that are actually private: Methods that are currently marked "private" but are accessible to anyone will become inner functions with no public access.
• Better global namespacing: I was hesitant to change the API for the 0.6 version, but I’d like to follow the YUI model and group all of RSH’s objects into a single global variable. Instead of dhtmlHistory and historyStorage, we’ll end up with RSH.history and RSH.storage.

The roadmap for 1.0 includes the following:

• JSUnit and Selenium test suites.
• Adapters for major frameworks using the MooTools model.
• Customizable downloads.
• Serious tutorials and documentation.

In the meantime, downloads for 0.6 RC1 have crept to just under 350 almost 700. Look for me to "flip the switch" on Saturday, promote 0.6 to the stable production version, and deprecate 0.4 once and for all.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History