The sound of silence echoing off the streets is due to a number of projects in both my work and hobby arenas that have been chewing away at my time, as well as a general lack of discussion topics. Nonetheless, without any further ado, today’s post.
I might be a bit late to this bandwagon, and this might be a blast from the past for some of you, but I thought I’d post my impressions on Ruby on Rails after having used it for a week and a half now. Forthcoming as well are my impressions on working with the Facebook platform.
I’ve mentioned to several people that I’ve started developing with Rails, and the general reaction seems to be uniformly “Oh, Rails? I’ve heard a lot about it, how is it?” Note the complete lack of specificity – no one knows exactly what is great about it, only that it is buzzworthy. Having now used it for a week, and having developed extensively with ASP/ASP.NET and hacked PHP sites for ages now, I think I have a fairly decent impression on its strengths and weaknesses, as well as how it stacks up with the competition.
First, let’s get Rails’ biggest benefits over with. These are two in number as far as I’m concerned, the first of which is that ActiveRecord rocks. ActiveRecord is easy to describe yet hard to quantify; it has an entire subdomain of its own over at the Rails website, and for good reason – the point of ActiveRecord is to embody the DRY (Don’t Repeat Yourself) principle in the data layer of the application. A normal web application will feature several layers of architecture, starting with the DB layer (the actual storage itself), then the Data Access layer (the factory classes that grab data), then the Business Logic layer (the classes that represent the database classes field-for-field, and methods for getting to and from the Data Access layer). This process involves multiple repetitions of the same information, especially that of the fields each object is associated with. ActiveRecord quite simply collapses this entire model into the database – you create a database table, and through their naming guidelines, declare a class that the database backs. That’s it. You can also specify validation, relationships, and other metadata in the class, but there is no need to redeclare the fields, or create any access methods. Since the data classes inherit from ActiveRecord, nearly anything you’d ever want to do is baked in. On a related note, Migrations are a neat idea: they are essentially versioning Ruby scripts that up- or down- grade your database schema as you change it. The benefit is that if data itself needs to be migrated, you’re already in ruby script, and that sort of thing is baked in.
The second huge benefit of Rails is that it follows MVC patterns to the letter. Because of this, the naming of your pages (called actions), backing code, and helper methods all fall right into line without any fuss. It’s a small feature, but it simplifies the process greatly, and there aren’t too many cases where you’ll want to break out of it.
Rails in general tries to be automagical – things are taken care of for you. The best example I can think of is that the addition of an AJAX-ified autocomplete box takes one line of code in the controller backing code, and one line of markup, which simply prints the box. This general air of niftiness pervades through a majority of Rails’ features. However, Rails won’t do anything for you unless you know the magic word to ask for. It’s very particular about exactly how everything should be given to it, and if it doesn’t like what it sees, it balks. This can lead to long, frustrating sessions of debugging, ending in (true story) “can it really be that simple…?” moments of realization.
Thus we get to the final bit of my impressions: how it stacks up with the competition. Rails is more or less on the extreme end of the spectrum from PHP – whereas in PHP, you lovingly craft everything you need from hand (or download someone else’s code), Rails tries to abstract it away for you. ASP.NET lies in the fuzzy middle – it tries to make web development follow a more desktop paradigm, which is both neat and confusing at the same time, and therefore in doing so it also abstracts many things away for you. However, ASP.NET has a very different philosophy as to how it should treat these abstractions – it allows, sometimes even forces the developer to customize every last aspect of it through various means, and therefore it becomes complex, cluttered, and bloated very quickly in many real-life scenarios. Rails, on the other hand, lays down the law of development and how you need to be doing it. Which one is better? That comes down to your own development preferences.
So far, for all the time I’ve wasted trying to figure out Rails’ quirks, I firmly believe that the time I saved from having to write database access code has more than made up for it.