Keith Watanabe * NET 2.0

A long debate about what to teach my friend's daughter led me to give Ruby on Rails a try recently at home while at work I started fumbling around with Django.  At first glance, both frameworks are very similar in that they are targeted at agile development for the web, most notably CRUD style development.  Both have a powerful scaffolding type of architecture where you create model objects that in turn instantly become editable web objects.

Both also employ scripts that do more heavy lifting for you.  For instance, creating applications via the command line as opposed to having to edit files from scratch.  Also, both have built in web servers that allow developers to utilize their local environments when creating web applications.

But that's probably where the similarities at the heart end.

Rails focuses more on convention for coding practices.  For instance, the model objects expect a certain naming convention and employ columns like "id" to handle the primary key.  On the other hand, Django is useful for legacy systems where it can "discover" schemas and quickly adapt itself to more complex scenarios (such as having non-surrogate keys).

I think Rails feels more mature and polished compared to Django.  For instance, it instantly builds unit tests for your models (and controllers I believe) whereas Django doesn't do that automatically.  Also, Rails has some pre-built, commonly used functions like login screens that you can install.

However, I found Rails to be a bit inflexible because of its design to force developers into using its conventions.  Legacy databases would suffer greatly if they didn't follow the database naming conventions for Rails.  Also, the scaffolding part, while not having worked with it extensively, seems more appropriate for simple CRUD based systems.  For example, it seems that if you have a backend system that requires various administrative menus to populate and control data for lookup tables and such, Rails is a great choice.  For scalable websites and legacy applications, Rails might suffer from the lack of flexibility in this area.

My personal preference is simply to stick with my own framework.  As well supported as these frameworks are with their communities, my biggest problem is that you're still limited by what the community deems as important.  Rails works in a restricted setting but I'm required lately to build more complex applications.  For me to port my stuff to Rails makes little sense.

Still though, it's nice being able to try out something different.