The web development world is about to enjoy one of those chocolate-and-peanut-butter moments, the convergence of two individually flavorful technologies–Ruby on Rails and Ajax–to form a scrumptious new taste sensation.
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.
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.]]>