Python and the One Web Framework

Ruby’s rise seems to have some people in the world of Python nervous. Without question, Ruby’s increase in popularity can be largely attributed to Ruby on Rails. Though I could be wrong, it seems like many Python people look at the fine bits of code that exist for Python and think “Python can do that! The only reason Ruby is getting users is because there’s only one web framework to use”. This thought then gets extrapolated to the notion that we in Pythonland need to somehow create one web framework “to rule them all”.

Ruby gets some converts who like the way the language works: “Perl, only better” or features like Ruby’s blocks. Or, maybe those people don’t like Python’s significant whitespace. Whatever the reason, creating a Python web framework to rule them all is not going to change the minds of these people because they’re picking up Ruby for Ruby, not for Rails.

So, eliminating those folks from discussion, I guess the thinking is that people are moving from language J with framework S to Ruby On Rails because Ruby has only one framework to choose from. Of course, that’s not even true: there are several web frameworks for Ruby. Ruby on Rails is just the largest and best known.

People aren’t choosing Ruby over Python because Ruby has one obvious choice for a web framework. People are choosing Ruby On Rails because it will help them get their projects done, and they know it will help them get their projects done.

Java, as a language/platform, has been quite successful despite having a variety of ways to write webapps: servlets, JSP, Struts, Tapestry, WebWork, JSF, etc. People aren’t migrating to Ruby because they’re tired of having to choose a web framework. People are choosing Rails because it’ll get the job done faster than the technologies they were using in Java.

It all boils down to user experience. In the case of a web application framework, the user is a developer of webapps. Anything you can do to make the developer’s life easier will win users: better and easier APIs, convenient tools and better docs are three examples.

There’s no “official” backing for TurboGears, and it didn’t come out of a committee of Pythonistas trying to achieve world domination by “creating” the “One Framework”. And yet, TurboGears is gaining users, many of whom are refugees from PHP and Java projects. This is purely market forces at work: people are coming to TurboGears and Python because they meet a need and at a reasonable cost (and if you don’t think open source web frameworks have a cost, I think that’s a good topic for another article). As with Rails, people come to the website, learn about the project and gain confidence that the TurboGears will meet their needs now and in the future.

In a nutshell: if it makes sense for Python to have one dominant web framework, it will happen naturally through the choices people make every day when deciding how to get a project done. Rather than spending my time thinking about how to create the Python web framework to rule them all, I’m spending my time doing whatever I can to make writing webapps easier.