I could probably learn a lot by re-reading Tony Marston’s article comparing his web application framework to Ruby on Rails. Marston’s work is always careful and well thought out. He describes his framework in detail and he is able to justify the decisions that he has made. He makes good use of well-known and successful design patterns to solve the main problems that web application frameworks need to deal with. It’s clear that he’s put at least as much careful thought into his framework as David Heinemeier Hansson put into Ruby on Rails.

Yet, all the same, I do not think I would ever use his system. Most of the problems that I need to tackle do not require such a careful and complicated system. Most of the quick hacks which make Ruby on Rails seem like such a breeze are perfectly acceptable to the work I do. Consider Marton’s criticism of naming conventions in Ruby on Rails:

RoR uses what is termed as “convention over configuration”, which means that instead of having to build a mass of configuration files which identify the structure of your database, by using certain naming conventions the framework is able to deduce the structure for itself. Unfortunately I find that these naming conventions are far too restrictive, and I am not alone. These restrictions mean that existing databases which have not been built using these conventions, which covers 99.99% of all databases, will not work with RoR, at least not without jumping through a lot of hoops. You have to know what the RoR conventions are, realise that your database does not conform to these conventions, then hunt for ways to tell the framework “don’t do that, do this”.

[For instance:]

Primary keys must be auto_increment and named ‘id’

This for me is an instant turn-off. There is no such rule in any DBMS, so for a piece of software to insist on such rules simply proves to me that the author of that software still has a lot to learn:

* A primary key does NOT have to be called ‘id’.
* A primary key does NOT have to be auto_increment.
* A primary key is NOT restricted to a single field.

I’d agree that Ruby On Rails philosophy of “convention over configuration” is mostly of use in greenfield projects that have no pre-existing database whose table names one must conform to. However, for me at least, this means little. When I’m working on an existing site, I tend to use whatever framework was already on that site. If I’m working on a new site, then Ruby on Rails’s naming conventions don’t seem like a restriction to me and offer me a speed benefit, so why wouldn’t I use them?

It’s possible that Marston’s system would be of more value to me if I were developing software, rather than websites. His focus seems to be websites that are really software packages, as he sort of says on several pages. For my work, which is websites, something like Ruby on Rail’s quick hacks are preferable to his more flexible, but complicated system.