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?

More on web python ruby coding

Comments

  1. What you need is a large dose of Django! (www.djangoproject.com)

    Check out the ‘Snakes and Rubies’ video floating around (Google Video has it) as well for some of the differences and some discussion, etc.

    — funduk on Tuesday, February 27, 2007 at 05:09 AM #

  2. I totally agreen on the fact, that starting python is quite confussing. If you wan’t to build someting, and not investigate different frameworks, you’re in some trouble.

    I have concluded my search by following the google app engine tutorials. And I intend to follow their suggestions all the way. I migth miss something, but do sincerelly hope they will keep om developing the stack they now have provided.

    — Nicolaj S. Lindtner on Tuesday, July 15, 2008 at 09:22 PM #

  3. Rails rules

    — Anonymous Coward on Wednesday, March 18, 2009 at 06:01 AM #

  4. I’ve been chewing on this for some time. I was trying to write a “framework” for the haXe platform that works similarly to Rails, then realised that it wasn’t such a good idea. Why? Well, I realised that, for the most part, developers are happy to use and reuse libraries that they feel comfortable with. There’s no point learning a new framework if you’ve used something for years and it works. What’s more, any framework built in haXe should ideally work for all platforms, as that’s what haXe is all about.

    My answer to this was to use what’s already there, but to provide the glue needed to make it more rails like, including libraries, generators, how-to videos and what have you.

    haXe already has a fantastic templating system called Templo, it has a super powerful yet lightweight ORM called SPOD and it has a port of PureMVC that compiles in haXe to C++, PHP, Flash 6 – 10, JavaScript and Neko. What more could you want? These libraries are already what existing developers are using, and they like them. Ergo, I’m now spending a lot of development time working on ways to make these libraries work closely with one another, and to shortcut ways in which developers can quickly create common application functionality.

    I’ve got a long way to go, but it’s a start.

    — Lee McColl Sylvester on Friday, June 26, 2009 at 07:20 AM #

  5. Last year I did a fairly serious REST web service project using Django. I loved it. I haven’t used Ruby on Rails, but I cannot imagine it being better overall.

    Python needs an answer to RoR; well, it has one, and that answer is Django. If you are considering doing a database-backed web project in Python, the only research you need is to read The Django Book.

    Full disclosure: I don’t benefit in any way from you using or not using Django. My current job is writing audio DSP code in C. I just really loved working in Django.

    — steveha on Thursday, July 23, 2009 at 05:29 PM #