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.

(Note: I really, really like Ruby and Rails. Anything disparaging that I say about either of them should be taken with several grains of salt. If I seem to be encouraging Pythoneers to crush Rails, it’s simply because I love both, and want all frameworks to be constantly innovating.)

Everybody with the slightest interest in web development has heard of Ruby on Rails. It thrust Ruby into the spotlight, created a hype machine that stubbornly refuses to go away, and made David Heinemeier Hansson a celebrity. I adore Rails - it’s by far the best web framework for simple CRUD apps. However, as a Python devotee, it hurt me deeply to see Ruby stealing the spotlight. As such, I embarked on a quest to find out why Rails is winning; I looked at Django, Turbogears, Pylons and web.py. After months of building the same simple CRUD app, I came to the following conclusion:

Python can beat Rails. It can grind it into a pulp in every way concievable - speed, elegance, coolness, extensiblity, organization, AJAXness, beauty, and flexibility. It can send Rails crying home to David while Guido basks in the Web 2.0 spotlight. But right now, Rails is thoroughly torching all of the Python web frameworks. The following is a list of recommendations that, if applied to a Python framework, could dislodge Rails from the position of King of the Web Frameworks.

(more…)

(Disclaimer: Python is my favorite programming language; however, I do criticize it in this article. Please redirect flames to /dev/null.)

I’ve been comparing web frameworks lately, developing a relatively simple CRUD database-backed application that can support a few bells and whistles. I’ve checked out Ruby on Rails (who hasn’t?) Django, and Turbogears in my search, and realized something as I was hacking together some templates in Kid:

Python, a far more restrictive and inflexible language - one that would seem, on the surface, to be worse for web application development than Ruby - is better for programmers, designers and security by nature of its inflexibility.

Let me explain what I mean. When designing ‘views’ - the web pages that users will see - that need to be updated with data from a given database, it is natural to break the Model-View-Controller paradigm and embed some controller logic into the application. After all, it’s so much less effort to embed

<% found_books = Book.find_all(”title = ?”, given_title) %>

into your .rhtml files then to go back into the controller file, change the return types, and make sure everything works correctly. However, Python is whitespace-sensitive, and therefore is much more difficult to embed into HTML. As such, you can’t write the mixture of Ruby and HTML that makes Rails so easy to use.

This is a good thing. I am a strong advocate of separating the model, view, and controller; by the very fact that I can’t write a combination of Python and HTML, I am forced to go back into the CherryPy/Django controller codebase and write a properly formed, secure, and elegant SQL query. Normally laxity wouldn’t bother me, but I believe that any large web application will grow into a hideous, Nylartothepic tangle if the MVC rules are not followed to the letter.

I still love Rails, but I love the templating systems in Python even more. Because Python is so restrictive, people had to write templating systems the Right Way - and that’s a good thing for everybody.