Framework Comparison Video

Sean Kelly has posted an interesting comparison (warning 60 min video!) of Rails, TurboGears, Django, Plone, and Java Sevlets/JSP, and full fledged J2EE development.

There is a lot of interesting commentary on this movie floating around out there, so I thought it might be worth while to try to gather some of that commentary in one place.

Overall, I think the message of the video is: The “Dynamic Language Frameworks” are all demonstrably better than their Java counterparts for web based application development. These frameworks allow you to make small incremental changes to the user interface as you test your ideas with real users.

And this conclusion is exactly right — user interface design is hard, and it requires the ability to iterate and deploy incremental improvements.
But before I move on to other people’s commentary, let me say a couple of things from my own perspective:

  1. Plone rocks for a certain set of problems, which it can solve out of the box.
  2. Sean uses TurboGears 0.8. Had he used the newly released 0.9 he would have been able to get authentication and automatic CRUD. Someone made his application with something like 9 lines of TG 0.9 code! :)
  3. Rails and Django also have internationalization frameworks now too (For those of you where this is important, I think Django and TurboGears do internationalization better than Rails because of Python’s Unicode support).
  4. His application is pretty trivial — a real test for these applications would look better for the TurboGears framework.

On the web people have been saying (I’ll do my best to be complete, and get the attribution right):

  • He’s very kind to Zope/Plone, if you step out of the Plone box then the cliff is indeed there but if you stay inside Plone everything tends to look like Plone and act like Plone and that isn’t that useful. That said, I’m sticking with Zope. — Simon Lucy
  • This Lessig-style presentation is mostly good, especially if you want to compare J2EE to web frameworks in general… it clearly shows how using any of these frameworks will drastically decrease your development time and lines of code, and generally make your life a lot more fun. — Jeff Croft
  • I should point out, though, that his version of Django was a little outdated, and his impressions of it had a few inaccuracies. Django’s got excellent i18n support, and for a while now it’s been able to use it without a database. Still, as long as someone’s not using J2EE, that’s a win for all of us dynamic-language freaks :) Jacob Kaplan-Moss

My complaint (and it is a minor one) is that Sean seems to get a lot of things wrong about TurboGears, Django, and Rails, so it’s not very good at providing insight into which of these frameworks is going to be the best fit for your particular needs.

Most of the problems I have with his analysis stem from the fact that these three “dynamic language frameworks” are growing and evolving very quickly.

TurboGears, Rails, Django, Plone, and Zope 3 are building the future today. I’m most connected with the future of TurboGears, and I have to say that the changes that are coming present a lot of exciting possibilities. If this is any indication of what is happening in Django, Zope and Rails, then the future of Python web development frameworks looks very bright indeed.

11 Responses to “Framework Comparison Video”

  1. 1Paul Everitt

    Hi Mark, nice post. Although I’m a Zope/Plone guy, I’m really happy with the progress that TurboGears and Django have made. I’m glad to see the points you make about 0.9′s improvements. I think TG has a really cool message.

    For the last 4 years, I’ve run the Zope track at EuroPython. This year I felt that the Python web frameworks should hang out with each other and learn from each other’s good work. Not to mention, find places (WSGI, eggs) to move Python-in-general forward. So I changed the track to be a web frameworks track, instead of Zope-centric.

    Things have changed with Zope 3, and that includes closed-world attitudes. Can you do me a favor and pass along the information about the track inside the TG community?

  2. I totally agree, we need to work together everywhere that it makes sense. And I haven’t noticed any closed-world attitudes from the Zope community lately, and I’ve already started spreading the word in the TuboGears world. There are a lot of smart people working on Zope and we should do what we can to take advantage of the thinking and work they have done in the TurboGears community.

    I would also say that for all of this to work our communities need the maturity to appreciate the value of approaches other than our own especially when differences philosophy mean that continuing to work separately is the best choice.

    At PyCon I helped to arrange a dinner meeting with all the web framework guys I could find. Kevin Dangoor, Jim Fulton, Ian Bicking (paste), Adrian and Jacob (the Django guys) and a few others were in attendance. It really was was a good time, and I think it helped to build the relationships which will be important as we start trying to work together more.

    TurboGears is moving towards having WSGI in the core, and we have always been committed to Eggs and have worked to drive that forward.

    I am also very enthusiastic about the componentization, and WSGI support that has happened in Zope 3, and I think the eggification of Zope 3 components will encourage re-use of some of those components outside the Zope world.

    I think this is a fantastic time to be involved in web development in python, and I am excited about all the interesting things going on in the Zope community and the rapid progress of Django. TurboGears. If these three projects continue to develop as they have been,(along with twisted) I Python will have fantastic development story for every kind of web application imaginable.

    I’m also convinced that different markets require different development stories, and python’s web framework diversity can be an advantage rather than a disadvantage. This is especially specially if we can use WSGI, library re-use, and eggs to make our frameworks play together well on the application level.

  3. Nice post, thank you for sharing us this, I watched the video it is cool, I love that every “Java-only” or “C/C++-only” developers to see this, it is the time for “fanatic-one-programming-tool-only” people to know that programming languages are just tools, and Python is a great tool ;-)

    Keep it up.

  4. 4bactisme

    Why no php framework in the test ??

    There are many php Framework and some might be better …

    Take a look at simfony or cakePhp, Php it’s easier to sell to one companie …


  5. 5bactisme

    But its a very good video, i will show the link at other friends ;)

  6. Bactisme,

    I didn’t create the video, I only commented on it!

    But, I agree it would be interesting to see how simfony and cakePhp compare the these other dynamic language frameworks.

    I think this video is interesting, but I think the real revolutionary concept is that even for large complex applications these next generation frameworks are easier to maintain than their Java counterparts.


  7. Hi Mark,

    I am a disgruntled Lotus Domino developer that is being moved from asp, and that has dabbled in ruby on rail and has done php.

    Annoyed by the slowness of development of Domino i came up with the idea of a Screencast racing competition whereby anyone can use whatever development environment to develop a simple application from a design spec.

    The rules are that you must start from a clean OS, then yum, apt get, WiseInstall. whatever is needed to setup and also Screencapture the work done on the application.

    The application should be something simple like the blog demo on

    The name of the competitioni cam up with is ScreencastRace2006. someone told me you have a similar idea, but i cannot find the blog page.

    I’m looking forward to your reply.

  8. A couple of things unmentioned for rails, some of them new:
    1) Database Migrations–you DON’T have to write sql to create the tables in your models for Rails, and this is one of the stronger features of rails–because migrations also allow you to version your database along with your code…
    2) Rails 1.2 supports internationalization
    3) Scaffold + Scaffold resource — you can create the demo you did above with one line of code–I can’t remember the field names, but effectively:
    ./script/generate scaffold_resource timetrack jobname:string starttime:datetime

    Done… full crud (you still have to run your migration — rake migrate VERSION=1 and setup your database in the configuration file).
    4) Maintainability: Ok, so you used a nice gui to setup your software… now what? When your database model changes, when your interface changes, support for REST, etc. Rails is built around the idea that you want code that’s easy and fun to write as well as extend and maintain…

    There is a point of too easy… if things are too easy the configuration, that you _will_ need to edit, is being hidden from you–and you’ll have to find it evenutally

    Oh and there’s also a plugin that allows you to build a graphical model and have it generate the schema for you…

    Other than that and it’s obvious python focus it was a good video. Would have been nice to see Rails, Zope, A PHP framework, and Java Framework like STRUTS just for the heck of it…

  9. A very nice video, with a few flaws. Like mentioned, the real point is not whether to use Plone/Zope over Django or Rails, etc, but whether or not to use J2EE over Dynamic Frameworks-and the Dynamic Frameworks clearly win. As to which to use, there are a few things to take into consideration:

    1. Language. If you already know Python or Ruby but not the other, you should use the language you are familiar with. While Rails has a lot of press, it is just as good as Django or TurboGears.

    2. Task. Like mentioned, Plone works good for some tasks, but step out of the box, and you may have issues. Similarly, internationalization may or may not be something you are looking for. Security is always a must. Never overlook it.

    Based on this, the best idea is to get some free space on a Linux desktop or closed server environment (if you are feeling adventurous, you can try Windows) and test them. However, be aware that if you are exposed to the internet (not behind a router or switch, making it possible for anyone to access your machine if you activate Apache or IIS) then you will have issues. Therefore, either disconnect or get behind a router and shut off any port forwarding on port 80. Also, the time saved by using Django/TG over Rails or vice versa is never worth the time spent learning a new language, or worse, training employees in a new language. Use what you know. (If you know neither, you may want to compare the languages first. I prefer Python because of its widespread use for much more then just web apps.)


  1. Framework Comparison Video…

    We didn’t get through the whole Ruby on Rails comparison video, but maybe you will…….

  2. [...] by Sean Kelly of Nasas JPL comparing Zope/Plone, Ruby on Rails, Turbogears and J2EE. 36 min long. Mark Ramm has a good follow-up article. Posted by waveadeadchicken Filed in web application frameworks, zope, turbogears, j2ee, ruby on [...]

Comments are currently closed.