Will Python dominate after Ruby on Rails?

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.

I also think that Bruce Eckel is thinking along similar lines in  Python Directions and the Web Framework Problem (by the way I wonder if what he is suggesting will be found in SqlAlchemy).

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.

Of course as always Ian Bicking is miles ahead and is already at work on the next step in the process.

[Update]

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.

Comments

[Robert Walker]

I've heard both sides of the story, and being realistic, I'm starting to agree with the pro-marketing side vs the pro-technology side. Specifically, I agree 100% with the technical advantages and flexibility of Python's solutions. I prefer Python before anything else, and as a platform it is probably the most compelling of any due to its capability as a glue language with syntax that is efficient and readable. BUT, is it not true that we are trying to win *mindshare*? Aren't we trying to do more than preach to the choir? If so, the Python critics are 100% right: it doesn't matter if the WSGI toolkit approach and multitude of framworks gives the most power and flexibility, developers only want one end-all be-all solution for web programming. You're argument is only convincing Python programmers, not converting people who aren't. Think of how many web developers are used to using MS SQL Server because mindshare-wise it's the default, or Java because it's the mindshare default, or bundled-integrated-product-X because it's the default. For better or worse, Microsoft and the big corporations have made computer users default-happy, and Python can't straightforwardly give web developers a default, so they go somewhere else where they don't *feel* like they have to make decisions. To me, Django is the only real contender. Regardless of other people's preferences, it's the only one getting its act together.

1. It feels like a *product*. 90% of computer users of all skill levels prefer what feels like a *legitimate product*, rather than someone's side hobby program.
2. It's website looks *professional*, not cutesy or hobby-ish. So does its built in admin interface. Score +1 with the "enterprise" crowd's decision-makers.
3. It's *simple*. Sorry, Zope (yes, that includes Zope 3!).
4. It's used by real websites today. You can actually *show* them to people. But unlike other frameworks, those websites look professional, too.
5. I *feel* like I have power using it, and so I feel cool using it. Whereas Zope makes me feel dumb and lost, Turbogears makes me feel like I'm using Franken-code, etc.

Disclaimer: I'm actually a Linux, Free/Open-Source, Python zealot. I'm not actually trying to offend anyone or start a flame war. But at the same time, I know when it's time to face facts. I think we already won the technology race, it's only that it's really the marketing race we are losing pathetically. Python doesn't have to go with Django, but it better mindshare-sell something that *impresses*, for reasons *other than* technology (videos, "only badass pro's are worthy of using this framework", "only anti-enterprise rebels are badass enough to use this framework", etc.)

[DaveW]

Robert,

Obviously my point is not clearly made. I do believe that Python has a number of frameworks that can compete or even be a little better than Rails. You believe Django to be the best of them. Fine.

However, a slightly better Rails than Rails will not bring people to Python in anything more than a trickle as Rails will still have the brand awareness.

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 Rials. 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.

[Rob Walker]

As I stated before, I agree that the current state of Python web programming gives power and flexibility. With 3 or 4 frameworks as good as Rails or better with interchangeable parts, technologically Python is a compelling platform. And yes, we could market this, saying "Use Python, it has the most flexibility to let you choose whatever tools you want to use together for the problem at hand". It's a good message, only it's not the one people are concerned with when considering making the switch to Python.

My point is that my impression of the demographic of people that have chosen to migrate to Rails were previously the Microsoft, J2EE, or "Enterprise CMS" sort of crowd, and that message is not what convinces them to make the switch. My point with Django is not that all the other frameworks are bad, I just think that it's not a coincidence that Rails just so happens to be an integrated full-stack. I'm not saying that being integrated is better, only that the reasons people switch to Rails rather than Python is that Rails feels like a better version of the type of solutions they are used to: integrated software products. I don't think Python should make Enterprise integrated crapware, but the *feel* of the framework, its website, its training materials, etc. has to be culturally comfortable with those who are making the switch. I mentioned Django because it *feels* integrated, like it was designed from the beginning for its components to work together, despite the fact you can mix-and-match with Django just like any other framework. *Of course* I believe the toolkit approach is better, but I've had similar experiences with advocating Python as I've had with advocating Linux (both advocate the UNIX-philosophy toolkit-approach).

I have to show other programmers that they don't have to use Visual Basic, they can use wxPython and psycopg/pysqlite/whatever. Almost every time, the first thing they point out in their skepticism is a hundred points saying basically that "I know it works together, but it doesn't *feel* like it should. I'm just *used* to VB's single place to go for every task".

I believe this is a real phenomenon. These same programmers I tried to turn on to Zope in the past. Amazingly, they actually spent *several months* trying to learn it, even buying books, before finally giving up. Other frameworks at the time were barely given a second glance. Why? Because Zope looked like it *should be* the one-stop integrated-product solution, regardless if anyone knows how to get real work done with it.

I think the point the just-look-at-the-technology camp is missing is this: it's not that the Enterprise-framework-refugees want to ditch the *feeling* of being "Enterprise", they just don't want to program for 30 years for one simple program.

The sad truth is that those who have the power to make the decisions for a company to switch don't fully understand the technological differences between alternatives. They just know what they want a product *to do*. Rails won them over with its AJAX'y goodness, thereby jumping on the Google Maps hype bandwagon, and made them wonder why they spent so much time and money on their commercial CMS. And then hype bred more hype.

Case in point: If I hadn't read the Python webpage, I would never had known Python is used by Google (or by NASA, or by ILM, or...).

[riffraff]

Well, note that rails is not the only web choice in ruby land, there are quite a bit of them, beetween Nitro, IOWA, Wee, Camping, Cerise, narf, etc etc etc...

Just, rails is the one that has the stronger community, which I think is the key point: the bad point about having N different interacting modules in python land is that it's hard to have a coesive community, even if technically the module do not have any problem about being mixed in the same project

[scooviduvoctagon]

Why are you comparing Rails and Python? A web-application framework (rails), compared to a programming language (python) - makes no sense.

And you should realize that though the thing known as Rails is a package of related and complimentary technologies/libraries - it can be easily broken down into its constituent parts and mixed with other ruby-based options/solutions. As the poster above commented, ruby has plenty of options to choose from.

Also remember that, aside from the hype, and aside from the actual merits of Rails - a very large part of what makes Rails what it is, is due to the very fact that it is built from Ruby - a truly excellent language.

Finally, if your intent to compare Python to Rails, was to contrast the sheer amount of flexibility/options available - you would do well to take Catalyst into account; an mvc web-app framework built from Perl, which happens to have neigh _unlimited_ potential for options - it's a breeze to use the Catalyst controller with any number of ORMs or template systems or different views/models, in addition to a myriad of plugins; in fact all of CPAN is available.

But perhaps you're ignoring Catalyst because it is Perl, and thus off your radar due to A: it's not Python, and B: it doesn't have the hype that Ruby/Rails is currently enjoying.

[Rob Walker]

Scooviduvoctagon, I believe the reason why the article compares Python to Rails (and not simply Ruby as a web platform in general) is that the article is about a particular marketing point (although the technological side of a marketing point). He advocates a toolkit approach, which ties together mix-and-matched Python components, and so he's more concerned with Python's success in general as a web platform and therefore not so concerned with comparing individual frameworks. The fact about Ruby is that, despite being able to do the same toolkit approach (and the fact that there are many other frameworks for Ruby other than Rails), when it comes to *marketing*, Rails is what has mindshare as the One True Ruby Web Development Solution, and so that's how he's treating it. It's one *web platform* vs another, whether that platform is technolgically a single framework or a toolkit of frameworks united by a common language.

[DaveW]

Rob, Spot on. IMHO trying to market as "Rails done in Python" is not likely to be very exciting. Marketing as "Rails with choice" may stand a better chance.