I started using Django in June for a side project. A friend told me about it, he wanted to use it for a project we were going to do and it seemed great. Unfortunately, none of those projects went live (for non-technical reasons). A few months later, I am helping another friend with django-based website, and I also redid my personal website in django (albeit a very peculiar use of django) and I have other plans for django websites based on the framework I built for myself.
Two months ago, I decided to rewrite a website I manage (PAPS) in django. It was drupal-based, which had served us well, but it was, by now too old and inflexible. One of the things that disturbed me about it was that I had started tweaking the code. Not much, but enough that I was afraid to upgrade and lose those changes.
Also, I wanted recaptcha on signups, openid logins, twitter integration and a bit of a feeling of modernity. I worked on it a few hours per week, in the evenings, but I didn’t make much progress until I switched to Pylons. By then, I had invested a month into the project, but kept getting stuck and moving forward only at immense effort.
First, the good: its documentation is deservedly regarded as impeccable and an example to us all. Its really easy to set up a very simple website and have it just work fast.
Now, the bad: One of the major reasons why I thought that django was so great was the vibrant community of people writing apps. However, I think that this also exposes django’s basic architectural flaw: the app system is not the right system to break up functionality. This is why there is so much talk of reusable apps: most existing ones are hard to reuse.
I first tried pinax or one of the content management systems. As usual, you get a working website instantly, but then you hit a productivity barrier very fast. Then, I tried a bunch of apps to get the pieces of functionality I wanted and get them to play together. What I wanted to avoid was to fork the code and
adapt it to my project. Then, I would be forced to maintain it and diverging from the main tree.
I tried. I really did. But I could never really get open id to work. I gave up on almost all of the apps I tried too. They would have a structure that didn’t fit into the rest of my application, I would need to tweak the templates (most by reading the code to see what was going on, which names it exported). I would need to fix the urls and url names. I would basically be forking each app to work with my desires instead of re-using it.
Fundamentally, the app model is the wrong abstraction for reuse in web-applications. I don’t have an answer, but I know that the app model does not work. How does, say, recaptcha authentication fit into the app model? What are its models, its views, its templates? It’s better handled as a different sort of reuse. What if I want to have a photo gallery and have the insertion of new photos trigger a tweet? I always end up taking someone’s code and modifying when what I wanted was to take someone’s code and call it.
What finally broke the camels back was when I was working with a django model and thought Sqlalchemy would be so much better. So, I decided to try Pylons.
Later that evening, I had ported almost all my existing work to Pylons. The next day, I had made progress. Also, I finally stopped feeling frustrated.
Pylons seems to get a bit less attention. The reasoning seems to be: django is better for simple sites, Pylons for complex sites. Most sites are simple. Therefore, django is more popular.
What I finally figured is that, if you’re writing most of the code yourself or editing other people’s stuff so badly that you might as well start from a couple of snippets, what is django buying you?
I can use sqlalchemy and I can use mako as a templating engine. I never really liked django’s ORM nor its templating engine. I know you can change the template language, but then other apps get very unhappy. Use best of breed for your tools instead of not-invented here is a good principle.
The debugger that comes with Pylons is awesome: if there is an error in your code, you can actually get an HTML+Ajax python shell on the webpage where you can inspect the state of the programme. SQLAlchemy’s error messages are beautiful. Here’s a recent one (from FormAlchemy): No session found. Either bind a session explicitly, or specify relation options manually so FormAlchemy doesn’t try to autoload them.
Here’s a screenshot of the debugger.
The contrast with django is immense. After months of daily use, I still feel stumped trying to decipher its error messages. Not always, but enough times that its frustrating. Just yesterday, another friend called me up on a Django problem. manage.py was not finding settings.py anymore because django plays around with the paths and the imports in a weird way and there was an impossible to understand relationships to recent changes because it worked in previous versions.
There is nothing wrong with magic in a system (rarely do you hear someone complain that their framework is too magical for working with files, just let me see the disk sectors). But unfinished magic is very frustrating. Unfinished magic most often manifests when the error messages are not magical. So, it just works or it just doesn’t work. As if your operating system spat out a bunch of references to virtual file systems and inodes when you mistyped a file name instead of saying File mixpelled.txt not found. Django has too much unfinished magic: if you make a little typo, then you get an obscure error in a place unrelated to your typo. SQLAlchemy is finished magic: half the time it even suggests a solution to
Then there are the little irritations in django: the
Sites app is obviously something that solved a problem in django’s original environment, but is a nuisance for the other 99% of cases. The fact that the username cannot be an email: Such a limitation is out of place in a general purpose framework.
I do miss the admin interface.
Django is good if your website is simple and Pylons is better if it is complex. I still agree with this statement, but I have lowered the bar for simple dramatically to mean “almost static” webpages. Pylons has a slightly higher learning curve and takes a bit of time to get to something that works well, but, if you know django, you can start writing code very very fast because most of the concepts are so similar.
The debugger on Pylons is so nice it makes it worth the switch.
Right now, unless my site was braindead simple, I would never go back to Django.
Follow me on twitter: @luispedrocoelho