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.
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).
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").
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.
Has there been any guidelines created for the safe use of XmlHttpRequest?
For whatever it's worth...
For whatever it's worth...
Whoopsie! Pure typo, I assure you. Fixed.
AJAX or JUDO?
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?
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.