The inundation of Ruby on Rails related articles and discussion has finally provoked me to go see what all the hype is about and then to figure out why the damn thing isn't called Python on Rails.

First, I want to mention that the main Ruby on Rails site is very nicely done. The video covering getting started and hype and philosophy are extra nice touches. Some may call this superfluous, and maybe it is, but I like it anyway. Being able to watch someone setting stuff up and coding a quick app is way more interesting then I would have thought.

After trawling through the main documentation trying to find The Essence without much luck, I decided that I'd shift over to the blogs, mailing lists, and forums looking for commentary from the Python world. Googling for "Ruby on Rails" +Python came back with notably little real discussion.

Actually, there's a lot of Python on ??? type questions with the same answer every time:

Python has many web frameworks that provide Ruby on Rails like functionality.

Perhaps this is the real problem Rails solves. When you want to build a web application in Python, there's quite a bit of web framework research and evaluation required before you can start thinking about your real problem. Once you feel comfortable with a web framework, the ramp up time for new projects decreases a bit but the first step is a big one. This seems to be keeping people away from Python for web related work. The feeling I'm getting around Rails is that it let's you skip the tool selection phase and dive right into problem domain.

As is often the case when I'm looking for quality commentary on Python related issues, I arrived at Ian Bicking's weblog where he provides some thoughts and analysis on Rails' popularity and how it might relate to Python.

I got the feeling that Ian wasn't all that blown away by Rails:

I've looked a little at Rails. It's not super special.

Okay, what's it doing that has everyone so excited about then? I'm not seeing the run of the mill Enterprise Scalable Solution marketoid fluff. I'm seeing people like Matt Mulwig and Simon Willison (not to mention del.icio.us popular) point to Rails.

Lessee... Rails seems to have:

  • A simple object publisher. There's a ton of these in Python. It also perhaps includes some sort of MVC system, where the object picks up a template automatically if it exists. These exist as well, though I think MVC efforts can become overly ambitious or overly restrictive fairly easily.

  • An object-relational mapper. I'd say this is close to SQLObject, though SQLObject is in some ways more powerful.

  • A templating system. Looks like ASP. There's lots of templating languages in Python; the simplest (e.g., embed Python code) can be problematic because of Python's significant whitespace. But anyway, we have lots and lots of these, and there are real reasons for why there's multiple templating languages. Spyce is probably the closest to Rails.

All three of these pieces fit together really well in Rails, which is perhaps what it offers that Python doesn't have.

Finally, The Essence. That's the best concise description of what Rails provides I've found and seems to go along with other bits and pieces I'm seeing.

But wait, there's more. Ronalda M. Ferraz follows up Ian's post and claims that he missed the point. I personally think Ian got it but I have to agree with Ferraz that the value in having a tight framework stack was underestimated.

Unfortunately, Ferraz implies that Rails couldn't be done in Python because Ruby favors the natural emergence of such cohesive and complete libraries.

I never saw a gauntlet I didn't like and I think a full Rails-like stack in Python would be a useful tool for my box so I'd like to throw out a couple of talking points to try to spark some discussion around this.

Pieces, Parts

We need a good object publisher, object persistence layer, and templating system together in a single package.

Object publishers I have experience with are Quixote and CherryPy. Both are really nice pieces of software. mod_python has an object publisher too but it has some issues. There's no room for multiple object publishers, we'd need to pick one or write another. I'll just throw out that Quixote's license is not GPL compatible, which makes it less of an option in my opinion.

Popular pure template languages include Cheetah, PTL, TAL, and I'm going to throw Kid in there too because I'm a shameless, self-promoting bastard. Is there room for more than one template language in a Railsish package? I don't know, maybe.

Object persistence is the area I'm most shaky on. I generally write my own data access code (and hate every moment of it). SQLObject springs to mind immediately and I'm not sure we should rule out ZODB. It may be nice to have the stack work with either an object back-end or a relational back-end. Having played with ZODB a bit recently, I think it has some serious advantages over relational storage but those come with some cost as well, so I don't think you can give up relational database support.

A Bunch of Parts Does Not a System Make

IMO, the real breakthrough with Rails is that each of the layers in the stack come bundled together and each understands the others fairly intimately. This combined with the dynamic aspect of the language allows pieces up the stack to provide sensible default functionality given concrete pieces down the stack. For instance, in the TODO list tutorial, once the table is created and the initial set of skeleton code is in place, you get a very basic set of pages that handle CRUD for the object without actually having to write any code. The role of the programmer is then to tweak the vanilla experience by overriding certain methods in each layer of the stack.

Project Organization Is Hard

This may sound silly but I waste a ton of time trying to organize my project's source files:

  • How should database scripts, templates, other web resources, scripts, documentation, etc. be organized?

  • How should my packages be laid out? Do I create separate sub-packages for model, view, and controller? How about just separate modules? Or should I organize by object, keeping the model, view, and controller implementations in a single module? I've tried all of these approaches and found that each has pros and cons but that consistency is always king.

Another aspect of Rails that I appreciated is that it seems to promote—and possibly even require—a strict organizational structure of source files. This structure can be generated for you by helper scripts.

This is the kind of stuff I think is underrated. It significantly lowers the barrier to entry for new programmers to get moving with the framework and lowers the amount of time it takes for experienced programmers to create new projects.

I think that's pretty much everything I wanted to get out here. I'm hoping this leads to some good conversation. What I'm really trying to get a feel for is if anyone else thinks something like Rails would be useful for projects they've created in the past / planning for the future or is what we have today good enough?