Thoughts on Ruby on Rails

I have been learning about Ruby on Rails, the ultra-hyped ultra-popular web development framework that has become almost synonymous with the recent resurgence in interest in all things web related (aka “Web 2.0”).

Ruby on Rails is best summarized as a set of tightly integrated tools that are specifically designed to enable the rapid and convenient development of websites according to a series of best-practices in this art, including the use of a “model-view-controller” architecture and unit tests, while avoiding a number of common pit-falls with less proscriptive architectures such as PHP.

Many of the ideas behind Rails can and have been applied to languages other than Ruby, but Ruby’s flexible nature make it particularly suited as a form of “meta-language”, one which can easily be modified and extended in a dynamic way. I should say that people with a preference for compiled rather than interpreted languages may question whether these capabilities are advantageous in a language, but I would rather avoid getting into the static versus dynamic argument here.

As an example of this flexibility, consider the Object.find_by_FIELD() method, which can be used to query a table in the database and retrieve an object containing a field that corresponds to a particular value. The FIELD string can be replaced by any of the table’s fields – meaning that the name of the method is parsed by rails at runtime – something that will probably horrify users accustomed to static programming languages like Java or ML.

Rails makes extensive use of these (what I’m calling) dynamic method names, and while it leads to readable code, it very much limits what can be validated by the parser. Fortunately, Rails’ support for unit testing may mitigate this (unit tests being the standard response to this type of criticism made against dynamic programming languages).

In the same way that Perl tends to be much easier to write than it is to read, ditto for regular expressions, I get the sense that Rails is significantly easier to read than it is to write – you need significant knowledge of the framework to really get stuff done. This means that all of those videos that demonstrate the creation of a blog in 10 minutes using Rails are somewhat disingenuous as they do not factor in the weeks of study and experimentation required to build up a sufficient level of expertise.

Rails main contribution is not to be afraid to streamline for a particular class of tasks as much as possible, rather than keep a framework as generic as it can. It is definitely worth taking the time to understand, but I wouldn’t expect any major new insights about website design from learning it. I think the Google Web Toolkit is a much more interesting and innovative proposition, although its current lack of proper Mac support is preventing me from digging into it further at this time.

Leave a Reply

Your email address will not be published.