The chocolate in this equation is Ruby on Rails
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.
: 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”
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).
; 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.
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
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.