Important Shock

Let’s say you came up to me and said “Patrick, I want to start a Web 2.0 company. I have some great ideas, good web developers, a firm grip on the quagmire that is public relations; in short, I have everything except a web development framework. Which one would you recommend?”

My answer would be this: Though Turbogears is worse than Pylons, it is nonetheless the best web framework.

You would probably inquire what the hell I was talking about. Well, let me elucidate:

I believe that one of the reasons for the massive success of Ruby on Rails is David Heinemeier Hansson’s damn-the-torpedoes attitude towards Rails’s scope. DHH, being an extremely opinionated person, refuses to incorporate things he doesn’t like into his framework - but he incorporates everything he does like into it.

ORM? Check. Database migrations for aforementioned ORM? Check. Embed Ruby arbitrarily into your views? Check. Built-in script.aculo.us integration? Check. Single-minded, near-zombielike focus on unit testing? Check. A bunch of nifty code generators? Check. Regular-expression-powered routing system? Check. Vastly needed improvements to the Ruby language? Check. (Whether ActiveSupport should be incorporated into the main Ruby code base is another blog post. Sneak preview: Yes.)

The list goes on and on - in short, Rails has a bunch of functionality built in, but just as much functionality left out. There’s no easy system for template inheritance, no userauth system, no multithreading support. Rails is a monolith - don’t like the ORM? Too bad. Don’t like ERb? No one’s making you use Rails; go back to Perl::Mason. Don’t like feature X? Here’s what DHH has to say.

And many people love the fact that Rails is a full-stack framework, that they don’t have to juggle dependencies between templating systems and ORM’s, that they don’t need to worry that easy_install or gem will break everything. Rails has that market covered.

But true web framework nirvana comes from freedom of choice. I should be able to say OK, for this next web application I need a really powerful ORM - SQLAlchemy should be fine. I like Mako, let’s use that. Routes is nice, we’ll take it. Oh, and I want an authorization system, and I’ll whip up some slick Javascript widgets while I’m at it.

I’ve been spending time in the #pylons chat room, and I feel that the people working on Pylons are close to realizing that goal - that a web framework should come in parts, like Legos, and that you should just plug components into as minimal of a base as possible until you get exactly what you want. WSGI can allow us to build interchangable parts - at least I think so, as I’m still not 100% positive what WSGI actually is.

But Pylons, ToscaWidgets, Migrate, AuthKit, Mako - they’re all very young projects, still struggling under the scarlet letter ß for Beta. The pieces aren’t ready to be put together yet - like Legos, you can’t build elaborate structures with misshapen blocks.

Pylons is representative of the freedom of choice that I want. But it’s not ready. Turbogears has echoes of Rails in its inability to use anything for the controller except CherryPy, but on the whole, it allows you to make some choices as to ORM, templating system, and what have you. And even the incomplete measure of choice which Turbogears offers allows it to dominate over Rails for all but the simplest CRUD apps. Pylons should win on principle, but when companies and jobs hang in the balance you can’t entrust all you have to principle.

When Pylons and all its corresponding pieces are ready, it will be a sight to behold. Until then, use Turbogears.