Ruby on Rails has been the darling of web development for a while now, thanks to the highly successful pioneers such as 37signals and the frustration with Java J2EE for web based user interfaces. However, it looks to me as if this may be changed by progress in the world of python.
The current state of play is reviewed in an excellent (large 400mb) screencast by Sean Kelly of the Jet Propulsion Lab. In it he compares
J2EE, Rails, Zope, TurboGears and Django for both hello world and a time tracker.
Of these Rails is clearly a good choice for the simple tasks that he has time for in the screencast. Zope also does excellently while both TurboGears and Django are clearly contenders (even though they were very early releases at the time the screencast was created eg see INET6: Making a Time Tracker in TurboGears for an update).
So it might seem that Python has a number of alternative frameworks all of which are not far from Rails in capabilities (and thanks to the growth in FastCGI support, due to Rails, hosting is becoming much easier for Python applications). But this does not appear to be much of a threat to the dominant mind share that Rails has been getting. In fact the variety of Python solutions has oft been seen as a disadvantage for Python.
However, things are changing (and doing so at a rapid pace). For example see this mailing list thread started by Kevin Dangoor after PyCon in the last week (with contributions from Ben Bangert from the Pylons project).
Again the very dynamic progress of TurboGears has raised some concerns about stability (is it CherryPy or RhubarbTart, is it SQLObject (1.0 or 2.0) or SqlAlchemy?). Kevin is doing a great job of keeping things together and also of moving forward with new tools, but at the same time some things may not be possible in the future when compatibility with earlier versions will be an issue.
However, as I have been reflecting on these issues that are often seen as negative (too many frameworks, lack of stable tool set) I have come to see things differently.
Hence, I am not concerned by the multitude of frameworks nor the stability that can be in tension with the availability of new tools and libraries. I think that this is demonstrated by some of the latest changes that Kevin writes about in the thread mentioned.
Anyway, to get to the points (as if I can):
- The problem of too many frameworks is now transformed into a powerful flexibility as they can be combined in a multitude of ways within one server (even within a single application) via paste and the WSGI specification.
- The problem of fixing the tools and libraries of a framework in order to maintain stability and compatibility is no longer a problem as we can use new frameworks, libraries and tools within the same application/server. So we gain the stability applications need while still being able to make use of new techniques etc.
So now the perceived disadvantages of python (too much choice, lack of stability) get turned around into advantages. In a world where flexibility and agility are so important I believe that Python has a winning and lasting combination solution. There are the options that will provide very rapid 4gl solutions (like TurboGears) and which achieve this through tight integration and some loss of flexibility (and later some restrictions on the speed with which they can introduce new ways of doing things due to the need to backward compatibility), however, it will be always possible to add flexibility through the ability to mix and combine at the Paste/WSGI level.
In my understanding that this is not well supported by Rails as a) there is no alternative to Rails written in Ruby and b) no way to combine alternatives even if they did exist.
Obviously my point is not as clearly made as I would like. I do believe that Python has
a number of frameworks that can compete with or even be a little better than
Rails. Robert believes Django to be the best of them. Fine. I have no problem with that.
However, a slightly better Rails than Rails will not bring people to
Python in anything more than a trickle as the original Rails will still have the
brand awareness and momentum.
What may work is having 3 or 4 options, all as good as Rails, with
slightly different emphases that can be combined within a single
application or server. This is where Python is far more capable than
Rails. When Rails can’t do the job or Rails is slow to bring in a new
technology to avoid breaking compatibility then Python will shine as
that is when you can add a new framework to your app that does not have
the backwards compatibility issues of the older ones.
For example suppose you have used TurboGears with SQLObject and then
have a task that SQLObject cannot currently model (or a database it
does not support), simply switch to a different framework which allows
you to use a different ORM for that task only. This option is not
available with Rails and to my mind is a wonderful marketing point.
Hope that clarifies things.