Frameworks matter, too

Standard

Peter Hunt puts the focus on successful web applications in How Python wins on the Web. He cites the success of Plone, MoinMoin, Trac, Mailman PyBloxsom and the non-web-based BitTorrent. He cedes the web application framework “market” to Rails and suggests that Python will “win” by having the best apps out there. I think he’s half correct. Ultimately, it’s the apps that people use and having the best apps will increase Python’s user base. But, the frameworks do matter, too.

The types of apps that Peter is talking about are “canned” apps. Install them, tweak some settings and go. But, there are many apps out there that need to be custom written for the task. By saying that “We won’t win in the Rails generation”, Peter says that we might as well give up on frameworks because the custom apps are going to be written in Rails.

I think he’s wrong. Java, PHP and ASP dwarf Python and Ruby in usage. People using those languages are starting to seriously look at doing things in a more agile way (in the case of Java and C#) or in a more structured way (in the case of PHP). Python, overall, has far greater usage than Ruby. Despite Python’s deeper penetration, people have been choosing to code their apps in Ruby because of Rails. For custom apps, clearly, the framework matters. Rails helps people get their work done faster. Give people a similarly productive experience in Python, and you’ll attract Python people and Java/PHP people who need to code the many custom apps that need to be written. I have seen this to be the case on the TurboGears mailing list.
If I suddenly said, “oh, Peter’s right. I’ll just start coding custom apps in Rails and drop this whole TurboGears thing”, then of course all custom development would go to Rails. (Except for the fact that TurboGears has achieved enough mass that it would go on without me…) But, I like programming in Python. Lots of other people do, too. And I want to have a productive time programming in Python. So, there’s value in a framework like TurboGears.

Back to the canned apps of the sort that Peter was talking about. He’s right that today Python has more successful canned apps out there than Ruby does. But, Rails makes programming an application easier than doing everything ad-hoc. If all of the Python apps continue to be ad-hoc, how will they keep up with folks that are getting things done more quickly with Rails? There are wikis, blogs and even a Trac-like system written in Rails. If those developments move at a higher velocity than the Python ones, eventually they’ll take over. Once upon a time, I used Movable Type for my blog. WordPress came along with a nicer interface (and an easy migration) and now I’m running WordPress. There’s no reason to assume that the existing successful Python projects will remain so indefinitely. (They certainly can, if they continue to be great at what they do!)
Many people have written about how much they enjoy using TurboGears and how they get things done quickly. Many of those people are writing custom apps, so clearly Rails isn’t getting everyone. Additionally, canned apps written with TurboGears are starting to appear. There are developments going on with CherryPy that will make it easy to wire up TurboGears apps easily and naturally and to use PasteDeploy if you want to run a non-TurboGears app next to it.

In summary, applications are ultimately what matter. The whole point of a framework is to help people make their apps more quickly. In that regard, frameworks do matter, too.

8 thoughts on “Frameworks matter, too

  1. Pingback: 42
  2. One thing about PHP : you can download a good application, install it and configure it in minutes on a gadzillion of free or low-cost shared hosting providers. Try doing that with Java, Python or Ruby. You almost always have to pay for a dedicated server or virtual private server…

    I have joined the mod_python development team about one year ago. One item on our todo list is “make mod_python a lot more shared hosting friendly”. It’s not easy at all, because you have to find a balance between having objects stay around in memory and having separate instance of Python so that different applications can’t mess with each other. That’s why mod_python can spawn multiple interpreters in the same process, but it’s not totally fool proof.

    This is a difficult subject and it requires elaborate solutions ; Java does it with multiple ClassLoaders, .NET does it with Appdomains, and yet low-cost shared hosting providers vastly shun those environments. As for Ruby, well, I’m not proficient enough, but it seems to me that the problem exists – and I guess that Ruby support is even scarcier than Python support for shared hosting providers.

    My point is that you can be online with your WordPress blog on your own domain in a matter of minutes (the only slow thing is DNS updating), and that may explain the quantity of easily set up canned app that exist for PHP.

    Other platforms require at least a virtual private server where you can start a daemon process. Frameworks matter in the sense that any framework that has a strong support on low-cost hosting provider is bound to “win” by popular demand.

  3. Deployment *is* a consideration, but keep in mind that Rails adoption has been quite good despite a deployment picture that is not the prettiest.

    TurboGears will probably never run on the very cheapest of the hosting companies, but you can already run it without spending *too* much money. I’ve seen virtual private servers for $20/month. DreamHost is cheaper than that, and there’s already folks running TurboGears there:

    http://trac.turbogears.org/turbogears/wiki/TurboGearsOnDreamHost

    I’m certain the experience can (and will!) be improved so that installing a TurboGears-based blog will take just a few commands at a command line. (Something that can also be automated via a web interface, for hosting companies that want to do TurboGears directly.)

  4. Usefull web frameworks provide a profitable way to develop web applications.

    Successfull frameworks like Microsoft’s .NET, Sun’s J2EE implementations and the many LAMP stacks share the same single characteristics: they are profitable. Those frameworks provide a different jumpstart for web developpers, and their success is independant of the relative quality of their design and implementation. But be it PHP or JBoss, they are all profitable.

    For instance, proprietary frameworks are more expensive to learn, apply or run than most LAMP stacks, but their application also bear bigger price tags. If you can invest time and money in J2EE APIs and expenses, then you can sell expensive applications to some big bank.

    Any web application can be designed simpler, implemented quicker, run faster on cheaper hardware and free software. But developers are strongly constrained by the profitability of the product they sell, so unless they own and rent it, they should pick the largest and oldest framework adopted by their potential customers.

    The need for a single Python framework is driven by the quest for a profitable Python version of the LAMP stack meme. TurboGear does try to articulate a ground-breaking API, but it aggregates a profitable framework out of existing Python libraries.

    However, I’m convinced that a greater web framework is possible for Python.

    Because the CPython VM itself has all the quality of a profitable framework. It is the oldest and most widely deployed Virtual Machine implementation. It has the most diverse set of C libraries bindings and runs on the largest range of operating systems.

    CPython can also compete against Java, C# or Apache, not just PHP.

    As Medusa (http://www.nightmare.com/medusa/) illustrates, a full CPython web stack can be profitable too, provided that you can ride the riddle of asynchrony, sell special-purpose high performance web servers (like http://www.ironport.com/) or develop your own framework on top of it (like http://zope.org/).

  5. re the deployment: actually, you can run Python web apps that support CGI at most masshosting providers I have seen, it is just more difficult than dropping files into a folder via FTP (you have to find out the path of the python binary or do other things to get a sensible CGI environment).

Comments are closed.