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.

12 thoughts on “Python and the One Web Framework”

  1. Very good points, and agreed from someone in the Zope community. I saw some of this discussion take place and I don’t see the point about worrying about “one single web framework” to rule them all either. Even if it were a good idea, which I don’t think it is, it is not possible to accomplish it in practice.

    What would be good of course is the different Python web frameworks working together and exchanging thoughts, ideas and code. And this is what’s happening; a number of frameworks are using WSGI, for instance.

    And on the code-sharing level, Twisted uses Zope’s interface implementation, Zope is using Twisted, and close to TurboGears, here at Infrae in a new project we’re using SQLObject in Zope (and others are doing it too), and a lot more… Very good.

    In the Zope community we’re now actively reaching out to other Python projects, not only as in “you can play with our code”, but also as “we play with YOUR code”. You can argue it’s something that should’ve been done earlier, but something we’re also finally ready for with Zope 3, mentally as well as technically.

    Let’s enjoy our strength in diversity. After all, there’s more than one way to do it! If that statement stolen from our Perlish brothers isn’t applicable to the Python language, it surely is to Python frameworks. 🙂

  2. I’m new to developing Python webapps. I have knowledge on the language (Python that is) and web skills of PHP + Java development (Tomcat).

    I’m thinking about doing some website with python. How should I start. Should I go with cgi/mod_python or is there some good frameworks to build my webapps upon?

  3. I have noticed a pattern where you seem to not discuss plone or zope at all. I guess because it is quite a different style to what you are doing.

    So far plone+zope is by far the most dominant web framework for python in terms of sites deployed, number of users, and features. You can see this by studying their mailing lists, irc chat rooms, and the vast number of third party products for plone at http://plone.org/

    I would guess even more popular than ruby on rails. It also has some very high profile sites using it.

    I don’t like it in general, but it is very good for certain types of sites and is a constantly improving, mature technology. It can do vast amounts of things that turbogears, django and the other new frameworks can not do.

    Plone+zope is quite different from the style that turbogears/django/subway are all going down. So I think it is great that they exist, and that eventually for this style of web framework one or two of these frame works will be dominant.

    Yah for diversity.

    Yah for turbogears, and subway. Since I use a lot of shared components as these projects I win because those components should get better documented, bug fixed, tested, and optimized.

    Similarly how twisted, django and plone+zope share other parts we all use. Like the database drivers, and python itself. Zope and twisted share parts too.

    Other web frameworks, like mighty, webware, peak, etc also contribute to the other projects. Through ideas, specifications, and shared code.

    All the different python web frameworks also help in another respect. Getting python recognised on webhosts. So we all have a better chance of using python compared to either php, or java.

  4. What Python does need, if it is to have any lasting impact in web development, is a simple, single deployment mechanism, like Java’s jars and wars, or Rail’s Switchtower. It isn’t practical for ISPs to provide mod_python and FastCGI and Cherrypy proxies and whathaveyou.

  5. Martijn: I agree absolutely in sharing code wherever it can be done without sacrificing the user experience that makes your own tool unique.

    Petteri: I’d recommend TurboGears for rapid, fun web development in Python. Admittedly, I’m known to have something of a bias in that area 🙂

    Rene: I haven’t generally been discussing Zope/Plone not only because it’s a bit different from what I’m up to, but also because it simply hasn’t come up. I get asked a lot more about Django.

    It’s certainly not a matter of me being unfamiliar with Zope. I released one of the earliest Products based on ZClasses, and even worked on porting Zope to Jython (pre-Python 2.2, so that had some interesting challenges). I’ve watched Z3’s development along the way, and even broke ZCatalog out from Zope3 for standalone use.

    So, I’m certainly aware that Zope is out there and that’s it’s big and has a big following. That may just be more evidence that there’s plenty of room for Python to grow and become a heavy-duty force on the web even without a “single web framework”. “Yah for diversity”, as you said…

    Mark: While I’ve heard of it, I haven’t looked closely at Switchtower yet. I’m certainly familiar with jars and wars. Eggs can actually help and potentially work like jars and wars for deployment, to an extent.

    From the hosting companies that I’ve worked with, I can say that they’ve been supporting Rails deployment (sans Switchtower) through FastCGI and SCGI, and it’s generally been working for them. TurboGears can be deployed the same way. Switchtower may make things much easier, though, and deployment is definitely an area that is ripe for improvement.

  6. Mark R:
    Exactly. However, having wsgi and flup at one’s disposal, the Python community is close to this goal now as never before.

  7. Mark:

    As tazzzzzzz sort of says, Switchtower is actually more akin to ‘ant’ in the java world — “build management” (well no compiling of course) and managing checkouts, file copies, restarting processes, etc.

    Rails still needs to be _deployed_ (process[es] started to serve requests) using FastCGI (most often), or more recently, SCGI (yes, from Python-land — from Quixote folks — with a Ruby driver/adapter). Lots of Rails-folk have turned to lighttpd (instead of or behind apache) for its tiny size and speed, and built-in FCGI abilities. It’d be great if python/ruby had something as generally easy as WARs — I guess wsgi is getting pretty close…

  8. Hi Kevin!

    I just want to state my excitment over the following paragraph:

    “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.”

    Thank you for showing great insight!

  9. “””
    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.
    “””

    And there’s one more thing. This will sound trivially, but still: Development of a web application, especially, for an enterprise-level intranet, is the product of team work: a part of the team makes data (most often, sql) back-end, another does dhtml front-end and the rest glue them together. Therefore, the web application framework must make life easier not only for programmers, but also for DBAs and view designers: No web application framework should compel either sql-wizards or dhtml-masters to learn profoundly the very programming (-scripting) language the framework uses. I guess no Oracle DBA is happy if he/she is made to do the job in Python/Ruby… Therefore, the approach of Rails to employ what’s already done in sql should prevail.
    Of course, if the talk is about a personal project, it becomes an advantage to do most of the stuff using only the favorite (scripting) language.

  10. Note that TurboGears is also designed to stay out of the way. Unless it’s changed, Rails templates are not particularly great for designers to work with. Kid templates allow designers to do the markup as needed with nice placeholders for the dynamic data.

    SQLObject allows the database to be defined in Python *or* the database, which is a good feature.

  11. “””
    Note that TurboGears is also designed to stay out of the way. Unless it’s changed, Rails templates are not particularly great for designers to work with. Kid templates allow designers to do the markup as needed with nice placeholders for the dynamic data.
    “””

    Yes, of course. The Python indentation made the Pythonland inhabitants to go beyond what was a usual way to do templates. Both Kid and ZPT are, as of my experience, excellent.

    “””
    SQLObject allows the database to be defined in Python or the database, which is a good feature.
    “””

    And this deserves a dedicated article in the TG documentation, as well as in your forthcoming TG book. Also, standard ways of deployment should be well documented: you might even want to distribute TG0.9 with flup…

  12. I’m looking at both RoR and Turbo Gears as a replacement for my own framework written in PHP (Death to Zend!!). I’ve only toyed with Turbo Gears a little bit. I’m starting with RoR as it’s reached 1.0, once threw it’ll be TG time. Frankly RoR has alot going for it, Unit Testing, good build tools, but I think the biggest thing it has is a large group of very qualified developers with an almost religious devotion, and a coherent meme structure. This is not to be underestimated, alot of us programmer types like to think that technical superiority is the sole measure of a technology. But if that was the case we’d all be using J2EE, and Apple would have been dead long ago. Even us ‘puter weenes tend to group around things we can quickly put our hands on, and technologies that are easy to navigate. Neither the Ruby nor the Python world are completely there yet, both lack a CPAN equivelant and mostly both give the impression of a bunch of rag tag developers doing their own thing. Rails is driving a coherent structure into the Ruby community. I hope TG can do the same to Python.

Comments are closed.