You got your Ajax in my Ruby

by Rael Dornfest

The web development world is about to enjoy one of those chocolate-and-peanut-butter moments, the convergence of two individually flavorful technologies to form a scrumptious new taste sensation.

The chocolate in this equation is Ruby on Rails: a framework for building database-driven web applications. But far from being yet another web development framework, Rails is known for its small footprint, low barrier to entry, flexible-yet-powerful, "more joy and less code" approach to application building. Rails is primarily the work of David Heinemeier Hansson, the backbone of 37signals' fabulous Basecamp project management tool (more on this incredible pairing in a forthcoming post).

At Rails' heart is Ruby, a lightweight object-oriented scripting language somewhere between the flexibility of Perl and the cleanliness of Python. The magic of Rails, however, is that you can accomplish a great deal without ever stepping in any code. Rails takes care of the first mile of any web application: the database crud--that's "create, read, update, delete." What is usually an hour or three of rote programming, Rails whittles down to just a single line of configuration.
And when you do reach the point where you've need of some code, there's less of it to deal with. Less code means a lower bar for newcomers, a narrower gap between rapid prototype and deployed application, and fewer bugs to shake out.

But less code doesn't necessarily mean more joy for the developer: there's still configuration and setup to deal with. The heavyweight in the web application framework space is the Java-based Struts. Leaf through the first couple-three paragraphs of the Struts page and you'll find a profound dearth of joy in the laundry list of acronyms and strangely dubbed packages. And you've not even laid eyes on the most painful part: the unceasing stream of XML configuration through which the hapless developer must wade before even getting anywhere near database configuration, let alone the application itself. Rails opts for convention over configuration: establish some sensible defaults, glean all you can from what you're given (your database, for instance, already knows a lot about what your application's data will look like), and give it a whirl. While you're more than able to configure the life out of a Rails application, it's not the suggested way of going about things.

While I'm in no way suggesting Rails is a panacea, it's ability to appeal to those further down the power-law curve, on the cusp of that developer/designer divide, stands it in good stead. Indeed, we've been seeing interest in Ruby explode over the past few months: no doubt in large part due to the swift adoption (or at least tire-kicking) of Rails.

(Literally see a Rails application unfolding before your very eyes, then delve--if this is your thing--into the nitty gritties of "Rolling with Ruby on Rails".)

The peanut-butter is a little something called Ajax, and it's cropping up in your browser just about daily--often without your even taking notice of it (aside, perhaps, from a delighted "Hmm!" every so often). It's the desktop application-like quality of the Gmail interface, the surprisingly slick interactivity of Google Maps that made you stop wondering why anyone bothered writing yet another online maps site, the subtle auto-fill of your city and state names as you typed your ZIP code into a web form.

Codified by Jesse James Garrett of Adaptive Path in "Ajax: A New Approach to Web Applications", Ajax stands for "Asynchronous Javascript + XML." Essentially what Ajax does is move much of the smarts involving user-interaction from the web server to your web browser. This takes the form of an Ajax engine (a piece of Javascript code) embedded into a web page, downloaded to your browser, and springing into action upon arrival. Acting as an interaction broker, the engine takes care of all the whizbang interactivity you see (form input and validation, dragging-and-dropping, showing-and-hiding, etc.) while dealing with the web server (and it's back-end database) as needed. This is in stark contrast to the typical dichotomy of treating the browser as a dumb beast capable only of layout and display and relying upon round-trips to the server for anything requiring any smarts. By backgrounding all of the back-and-forth with the web server, the stateless, staccato nature of typical web applications is kept to a minimum.

This makes for a richer application for the user, up-to-the-minute data streamed live from the back-end database server, and a lighter load in-between (data is shuttled back and forth as XML rather than being wrapped in the heavy clothing of HTML).

Now you've no doubt noticed some of this sort of interactivity on airline reservation, bookseller, and online banking sites. Much of that, however, was slight-of-hand rather than true Ajax at work. View the HTML source of many of those pages and you'll find them choked with pre-loaded data made available to a tangle of single-purpose Javascript scripts. A lovely (though unfortunate) example can be seen in the International Herald Tribune's typical article page; while seemingly Ajaxian, the full content of the article is already on-board, only hidden from view until you click the "> NEXT PAGE" button. While the effect is snazzy--for some limited definition thereof--that's a lot of baggage for a page to be carrying about just in case it's needed. Not to mention the amount of work it takes for the developer to keep all these loosely joined bits in some semblance of order. And, in the end, it doesn't result in anything more than base-level interactivity of the sort you wouldn't tolerate in any desktop application.

Ajax is about moving the intelligence to where it does the most good: presentation and interactivity in the browser, transaction management on the server, and data passing back and forth on the network.

Now bear in mind that Ajax isn't something you download. It's a collection of technologies and a way of harnessing them together in designing web applications. Implementations are springing up like tulips on the first warm day of Spring. And they vary widely in applicability, usability, completeness, and integration with web application development frameworks. And it's in these details that the devil really lies (c.f. Yahooligan Jeremy Zawodny's "Respect for Web Developers").

The taste sensation of the Rails/Ajax sweetmeat lies in baking Ajax right into the framework. Through the object-oriented Javascript library Prototype and a set of helper tags, Rails is making Ajax part of the process of developing web applications rather than another layer to be grafted on in a completely different way (and historically by a different person or team). To quote
David Heinemeier Hansson, chief Ruby on Rails wrangler: "Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we've gone ahead and more or less removed the need for hand-written client-side javascript entirely."

Ruby on Rails was off to a good start even before bringing Ajax on board; and it's only gone from strength to strength since. There's a danger, of course, that Rails could become a hodgepodge (cast your mind back to that Struts page). By baking in too much, it could move beyond the ken of the lightweight coders giving it lift. That said, given the sensibilities of those at the helm, I'm not terribly worried.

2005-03-31 19:12:18
Has there been any guidelines created for the safe use of XmlHttpRequest?
2005-04-01 09:28:09
For whatever it's worth...

Nice article, with the obligatory minor nit: CRUD is "Create, Read, Update, Delete", not "Connect...".

2005-04-01 10:40:32
For whatever it's worth...
Whoopsie! Pure typo, I assure you. Fixed.
2005-04-01 21:05:31
Seems the acronym AJAX gets tossed around anyplace one used to refer to DHTML. Is Rails actually passing XML around, or is this simply JUDO?

Or, maybe AJAX is already deprecated to mean 'Any use of the XMlHttpRequest object.' Pretty much ruins it as a meaningful new term, but of course it ups the trendiness factor.

2005-04-02 14:01:18
Downloading XML vs. JavaScript?
Have people experimented with having the server generate the JavaScript directly, rather than having the server generate XML, and client-side JavaScript interprets it into JavaScript commands? I know of at least one company doing the former with great success, but the AJAX buzz seems to be centered on the latter.

The latter seems to be a bit more reliant on client machine speed than seems prudent. I'd rather have the heavy iron on the server do the JavaScript creation, personally. It also seems easier to write.

Have people considered or measured the impact of this difference?

2005-04-03 01:31:50
Generating Once is Not Enough
I never liked the concept of code generators that much. The generation of crud-performing code will help you on you way, no doubt, but imho is not that revolutionary. For Perl and PHP similar packages exist.

Now what would be really cool if you could add your customizations (custom validations, form lay out tweaks) and than add some fields to the table and generate the crud code anew, your custom changes would survive and still work happily with the newly generated crud-code.
I think this realistically can be done by treating and storing the customizations as differences to the generated code (akin the patch mechanism).

Food for thoughts:
Direct2Web generates a crud app and allows you to override some defaults, via a GUI. You can, for example, hide some fields, change captions (default is the column name of the table) and set some input elements properties (like field size).
These customizations are stored separately, and survive changed to the data model.