NOTE: I posted an updated review about django, some of the shortcomings I point in this post are no longer there. Django gets better every day.
I have been into web development for years, and let me tell you, I never liked it too much. I’d rather be coding backends or things that just work in a server without human intervention. I find writing forms and validations in PHP (my prefered web development tool for years) tedious and boring. It is also “unnatural” (although not impossible) to have true separation of logic and presentation in PHP, it is a quirky, messy language.
Since I was already using Python for virtually everything but web development, I decided to give it a try.
The world of web development in python was like a jungle, there was Zope and lots of different little tools with a small user base and little documentation. I decided to give Zope2 a try but it is extremely complex and overdesigned, it felt like Java. Avoid Zope and Java for small/medium web development, it is like cracking a nut with a sledgehammer.
I finally decided to use clearsilver for templating and since I didn’t like anything pythonland had to offer me at the time, I wrote my own framework. I wrote it specifically to be used with clearsilver. Clearsilver is great: it is made in C (fast), it is language agnostic and has great apps using it, like trac and google groups. It was even considered by Yahoo! to be used in their migration from yScript (they use PHP now).
Problems arised. There was a new project with a tight deadline and I was devoting more time in my framework than in the project itself. A customer doesn’t pay you to write frameworks, he pays you to get his problems solved. And to make things worse, my framework had no documentation and I had to work with other programmers. It was then when I decided to ditch my framework and look for something better.
Ruby on Rails
Everybody was talking for months about how cool Ruby on Rails was, so I took a look. It has a nice video, lots of hype and killer apps like basecamp and backpack. Rails is written in Ruby so I had to learn a new language. No big deal, until I find out that Ruby’s syntax is not that clean and that it’s community is very japanese centric (there is nothing wrong with this but the only word I know in japanese is “karate”).
I decided to ignore Ruby for the moment and focus on Rails. What i noted:
- Very simple to install and set up new projects
- You create a database and it’s tables, and Rails will handle them
- Things get messy when you want to write SQL instead of using the framework to access the data model
- URL generation is simple but not flexible
- Rails templates looked ASPish, horrible, almost cthulhian. I couldn’t stand the sight of them. There is too much code in them and worst of all, I couldn’t find a way to change the template system (Clearsilver in Rails anyone?)
Needless to said, I didn’t like ROR, I needed something else.
TurboGears
It was in that moment that Jj pointed me to TurboGears, a ROR-like framework made in Python. Instead of reinventing the wheel TurboGears just reuses some well known Python tools like Cherrypy and SQLObject, and others not so well known like the Kid Template and the Mochikit Javascript library. I really didn’t try this one too much because:
- It really feels like a lot of little parts put together, you can feel the glue.
- It needs Python 2.4. I have customers still using 2.3. Enterprise versions of Linux ship with 2.3. This may not be an issue if you are coding your own blog in your basement, but it is in an issue in the real world.
- Because of cherrypy, it doesn’t work with mod_python. The recommended setup is to use the built in httpd in cherrypy. No thanks.
Is there a turbogears-powered-site supporting heavy traffic? Yesterday turbogears.org was slashdotted but according to what Kevin Dangoor said on #turbogears@freenode, turbogears.org is actually 100% static pages on apache.
Django
It was then that I remembered about this “Rails Killer” written in Python I read about on slashdot some months ago. Django was developed at World Online in Kansas, and has been in use in high traffic production sites (lawrence.com, ljworld.com) for two years. Their FAQ states that django sites weathered traffic spikes of over one million hits an hour. Chicagocrime, a notorious Django powered site, has been slashdotted three times. Django sites have been recognized by their great content and design. So django has real sites using it and it scales well. I downloaded it and tried it, what I found out:
- Installation: The installation of the framework is trivial
- URL structure: The urls are defined with regular expressions. This is unbelievable flexible and very useful if you are migrating from a previous site and don’t want to lose your URl estructure. Pretty (or ugly php-like if you want) URLs without messing with mod_rewrite
- No SQL CRUD: An excelent model api, you can develop a whole application without writing a single line of SQL. You just define your data objects as Python code and django will create the tables in the database and all the queries you need. For instance:
polls.get_list(pub_date__lte=datetime.datetime.now())will translate asSELECT * FROM polls_polls WHERE pub_date < NOW();It is much more flexible than SQLObject. - Admin site: Django gives you an administration site, for free. Complete with search features, user permissions and customization. And the admin site is actually a django app itself, so you can reuse portions of it in your project.
- Generic views: one of my favorite django features, generic views are nothing but an abstraction of the most used patterns in web apps: list/edit entries, listing entries by date, and CRUD operations.
- Nice templates: The templates look nice. And the nice thing is that you can use something else, like this implementation of Zope3 Page Templates for Django. Key features here: filters and template inheritance.
- mod_python: According to the documentation, Apache with mod_python currently is the preferred setup for using Django on a production server.
There is more, like the five built-in caching methods, the (imho misnamed) “Middleware” (low lever request filters), a nice session framework, great forms support, and much more. I was going to use django with clearsilver templates, but I’ll stick with django’s templates. They are better, look cleaner and I don’t think there will be a big performance hit with built-in caching. Even the guys behind trac, my favorite clearsilver app, are planning to use django templates or even rewriting everything in django in the future.
Of course not everything is perfect in django:
- Documentation is still incomplete, sometimes you’ll have to read the source code if you have non-trivial stuff to do
- Since it was a in-house project, internationalization and localization is lacking.
- The database api is not very pythonic, but it makes perfect sense since SQL can be quite complex.
- There is no support for Oracle
- If you change your data model, you have 2 choices to update your database:
- Perfrming a manual
ALTER TABLE - Recreate the database with django, losing all your data
- Perfrming a manual
- It has no cool video. This may sound silly, but I think more people will be interested in django if they see how it works with their own eyes (like with Rails and turbogears). Since the django tutorials are very extense, I think this presentation can be used as a good overview of django features.
- Django apps are not easy to deploy. Maybe Python Eggs can be of help?
The django community is working in these issues and even have patches in django’s trac. I’ll try to help as soon as I finish this project I’m working on, the one I rewrote in django. Like Ken Thompson once said:
One of my most productive days was throwing away 1000 lines of code.
He couldn’t be more right.
Comments (27)
Interesting article, but I think you didn’t fully examine some things or consider the consequences of other design decisions.
In RoR, URL generation is very flexible and even programmatic to an extent with their routes system. It also lets you generate URL’s in templates so that you can move things around without breaking any URL’s. Compare to Django, where you write a regexp to match a URL, and hard-code URL’s into your templates. If you move a directory of templates, or the URL needs to change, that’s a lot of text replacing since you have no URL generation.
I agree to a large extent with your views on RoR’s template system, it has its issues. Regarding TurboGears, it makes more sense to evaluate it in relation to Kevin’s reasons for creating it. Off the top of my head, I believe it was because he wanted something light-weight, excellent AJAX integration with JSON, easily deployable and usable for an end-user, and a XML-valid template language.
I’m curious why you believe the SQL model API for Django is more flexible than SQLObject. They obviously have different design approaches, whether that plays out in your favor or not depends on what you want to do and how you insist on doing it.
Regarding Django deployment, hopefully the work going on now with regard to WSGI, Eggs, and Paste will soon make it a snap to distribute and update Django applications. I know I’m looking forward to deploying Django applications for various roles on some sites I run. :)
Ben:
This post isn’t an in-depth analysis, it is just what I could find out after some days of playing around full time with the frameworks, which also says a lot of their documentation.
I really liked how Routes turn a URL into a request object and the dynamic generation of URLs in the templates. But what I meant by “not very flexible” was that, and please correct me if I am wrong, I can’t generate a URL that is not in the form of
/foo/bar/meow. This is complicated if you want to migrate an existing application with nasty URLs.I was going to point you to a Python implementation of Routes but it seems that it has been written by you :-) I’ll post it anyway since somebody may find it useful: Routes in Python.
About SQLObject, I am actually using it in non-django development, it is an excellent piece of software. But IMHO django ORM’s abstraction is a little higher than in SQLObject. For instance django adds dynamic methods so if you have a model “foo” that has a foreign key “bar”, django will add methods like “add_bar()” and “get_bar_count()”. And it will also add methods depending on the current field datatype, be it DateField, FileField, ImageField, etc. Django has also a clean syntax for JOINs, take a look at this snippet from the tutorial:
# Find all Choices for any poll whose pub_date is in 2005.
>>> choices.get_list(poll__pub_date__year=2005)
[Not much, The sky, Just hacking again]
Joins in SQLObject look almost like a join in SQL (from the SQLObject docs):
MyTable.select(MyTable.q.name == OtherTable.q.value,
join=LEFTJOINOn(MyTable, alias, MyTable.col1 == alias.q.col2))
It is all a matter of personal taste, SQLObject has on it’s side a more pythonic syntax and an OR operator for queries.
There is also a nice comparison of django and ROR in magpiebrain.com.
I am currently writing a web app in django. Turbogears has just come to my attention. So I took a quick look at it.
I will be sticking with django because as you say it has proved itself in high traffic production environments.
The one thing I may take from turbogears is the Kid templating. This is much more elegant, designer friendly and pythonic than django’s somewhat weird templating. It is trivial enough to plug a different template language into django.
1) Cherrypy 2.1 supports mod_python
2) Have a look at Subway
Django doesn’t *officially* support Oracle, but code to support has been submitted to the project. (I wrote it). I’ve been playing with Django for the past 3 months, and have been on Oracle since I wrote Oracle support for it. I’m working with the Django devs to get the Oracle support officially commited to source control… so it’s coming… hopefully soon.
steve:
You may want to take a look at this: using kid with django
Anthony:
1) that is great :)
2) It’s too late, i’m now a devoted djangonaut. Subway and turbogears should merge imho.
Jason:
That’s great. ms_sql.ado support (#225) is in the main trunk now. The more databases supported the better.
I wrote extensions for Clearsilver on Rails. The exercise inspired me to dump Rails.
The only way to get it to be fast was to completely hack out most of ActiveRecord’s functionality and deliver HDF from queries from ActiveRecord itself. I attempted to add an hdf=>true flag to ActiveRecord, but that was a mess of code that ended up being slow. In the end, the point of continuing was fruitless. All I’d be getting out of Rails at that point was a controller layer and having to switch to Ruby.
Django has now fully i18n support !!!
Catalyst is the only framework you need. And yes, I know Python and Ruby.
django has i18n now
Django and turbogears are just both icky.
First off, neither one uses distutils so they annoy me during installation. Django, in particular, couldn’t handle the –prefix=/opt setting at all. Scratch that, it installed but it didn’t work. On the other hand, turbogears did handle it but it f’ing littered my site-packages directory with layers of crap (*chuckle* I saw the guy who did turbogears wanted something lightweight–8.5MB of download is considered lightweight these days).
From what I can tell, neither one plays well with a legacy database. If they’re going to keep their own metadata around, they can do it *outside* the database I’m querying. Why? I get to talk to a system on another machine and I have *views*. Even if I thought it was a good idea to keep the frameworks meta-data there, I couldn’t.
Turbogears 20 minute wiki tutorial is probably broken with 0.9a6 since the quickstart command created a file that couldn’t be loaded due to a syntax error.
On the other hand, django drove me away with its DJANGO_MODULE_SETTINGS setting that it wasn’t at all obvious how to set. More remarkably, it said it wasn’t set even though it was (which probably means I set it incorrectly but it’s unclear how much f’ing around I’d need to do to get it to work).
I guess I’ll look at clearsilver.
I have a question regarding using Django vs. TurboGears. Can either of them do things with databases that are already existing? Or do they require that you create your own database? I know with TurboGears, you use SQLObject as the Model, but can it just interface with the databases that I already have?
Lisa:
You can easily do that with Django: Integrating with a legacy database.
About SQLObject, it has more restrictions than the Django, but is still has some support for legacy DBs: Legacy Database Schemas
Lisa and tabo: TurboGears has support for SQLAlchemy instead of SQLObject. SA is more flexible/advanced thatn SQLObject and has better support for legacy schemas.
thanks for your help tabo and arnar!
The Amnesty campaign “Irrepressible” runs TurboGears.
http://irrepressible.info/
So does my own site, which receives quite a load. Your judgement of TurboGears is pretty… unfair? Have you even really tried it?
Patrick:
I wrote this post in october, the first week after the first version of turbogears was released. That was the turbogears I used. And yes, I _really_ gave it a try, it just didn’t fit with the way I work.
I am sure Turbogears has improved a lot in all these months, but I am extremely happy with Django: it has more momentum, very notorious python programmers using it (David Ascher and Fredrik Lundh to name just a few), great designers like Jeff Croft, and even the BDFL seems to like it.
I know this article is old, but FYI, current versions of TurboGears do support mod_python:
http://www.turbogears.org/docs/deployment/mod_python.html
Hi there I just got here by google I know this is old but you should take a look at TG now.
because the 3 bullets you got there are no longer true.
actually the third one was never true
umm it seems someone took out this so here is the google cache link http://72.14.209.104/search?q=cache:2bzK40tsKVsJ:www.cherrypy.org/wiki/CherryPyProductionSetup+cherrypy+lets+face+it+apache&hl=en&gl=do&ct=clnk&cd=1&client=firefox-a
http://www.cherrypy.org/wiki/BehindApache
You are giving Cthulhu a bad name by teaming it with RoR!
At our company, since a couple of weeks we have loud discussions about frameworks. Since years we’re using Zope and Plone and we’re growing more and more unhappy with the speed. Of course we have Plone priests defending it, but we also got people who use Java for their own stuff. I personally am tired of Textarea and Ultraedit and vim. It’s 2007 and I like to start using an IDE.
Al:
Try the new Komodo IDE 4.0
No, I have no relation with ActiveState, but that’s what I’d use if I wasn’t a happy vim user.
This is nice overview of why Django really is the best choice for python web frameworks. (the python part is kinda redundant; why use anything other than python?) Another thing to note is that Guido has used django in his new source control project for google. Mondrian I believe it is called. There is a google video out there.
Django supports Oracle with cx_Oracle.
http://www.djangobook.com/en/beta/chapter05/
You may want to take a look at Gluon http://mdp.cti.depaul.edu which is very much inspired by Rails and Django, it is in Python, and allows you to do all development, maintenance and deployment via a web interface.
I don’t agree at all. Security is always an issue ( slord@mandalorian.co.uk )
Trackbacks/Pingbacks (12)
[...] http://www.larsen-b.com/Article/216.html http://tabo.aurealsys.com/software/xmms-pl-patch/?p=101 [...]
[...] http://www.larsen-b.com/Article/216.html http://tabo.aurealsys.com/archives/2005/10/11/django-or-why-i-chose-it-over-turbogears-and-ruby-on-rails/ [...]
LOOK AT THIS LINK
La primavera llega con…
Django, Or why I chose it over turbogears and ruby on rails
I have been into web development for years, and let me tell you, I never liked it too much. I’d rather be coding backends or things that just work in a server without human intervention. I find writing forms and validations in PHP (my prefered w…
[...] tabo @ aureal on Django, Or why I chose it over turbogears and ruby on railsPatrick Ungsater on Django, Or why I chose it over turbogears and ruby on railshyper on LovelyDaniel Adams on Wordpress UpdateJulián Hernández on Django, Or why I chose it over turbogears and ruby on rails [...]
[...] tabo: Django, Or why I chose it over turbogears and ruby on rails. That was pretty much what I have been through. I was also at a stage deciding on a frame work for a new project. While I have done most of freelance web development on PHP previously, as a Python developer of almost 6 years, I decided to look out for a Python-based frame work this time. [...]
[...] Sí, el título es una mención directa al post de Tabo, “Django, Or why I chose it over turbogears and ruby on rails.” [...]
porn pic…
yswpelytimo uvsrmbfnu pyxhwuye …
[...] Django, Or why I chose it over turbogears and ruby on rails [...]
[...] Picón on why he chose Django over Turbogears and Ruby on [...]
[...] Django, Or Why I Chose It Over Turbogears and Ruby on Rails [...]
[...] here comes the question: Django or TurboGears? Some articles give the comparison (Jeremy Jones, Gustavo Picon). I might be using both of them later. Let me see which one I will go for. Django is not its 1.0 [...]