It seems like a lot of people get frustrated with Django because it isn't the Framework for Copy & Paste Coders Who Like to be Spoonfed.
To some degree, this is a failure of the Django community's messaging. Django is highly modular and, if anything, disassembles gracefully as you start running into more complex scenarios (even more so in 1.2 than 1.1).
It's best to think of Django as a robust set of wheels you don't have to reinvent for each new site you build, and a toolkit for building new wheels you can not-reinvent next time around.
All of the above is painfully obvious to anybody who has spent a decent amount of time with Django, but might not be so clear to somebody just finding their way or using Django in a limited fashion. I'm sad to see that somebody had a poor experience with Django, but this post is basically a lot of whining about an inability to figure things out and use the framework as intended.
I think your sentiment here is pretty correct. We have been using Django to build SWIX ( http://www.swixhq.com ) and for the most part we find Django to be a blessing. It does much of the heavy lifting and helps us keep all our code modular and loosely coupled(at least when we are doing it right).
I've built one very complex site using Django, and it's worked great.
For the authors specific complaints:
- We found a nice reusable app. for recpatcha that basically just boils the whole thing down to a form field. It works flawlessly.
- I implemented twitter/facebook connect integration with no issues (all using the standard auth system, and two apps)
- We've done things like dynamic custom forms that work just beautifully.
It's a pretty long list of things that we've been able to accomplish with Django. We're really happy with it, particularly since the 1.1 release. It has a ton of flexibility, while still virtually automating most of the things we do often.
It's certainly not turn-key, but we've done this without modifying one line of django code.
In the near future I'm hoping to be able to take some time to open source some of this work.
Would I like commonly repeated problems to be solved elegantly so I can easily integrate them into my project without digging through poorly documented source code? Yes.
I've built a couple of reasonably complex Djamgo apps, and as much as I like Django, all the points author makes are very true. That said, by the time you have swapped out the template language and the ORM you are basically no longer using Django; I think it's fair to say that if find yourself needing to do those things, you're much better off with Pylons.It's a question of the right tool for the job.
I do agree heartily that Django apps are not an effective level of abstraction as on might hope. Personally I usually just stick to using various libraries and writing my own code to do the Django-specific parts.
I just switched the other way - from Pylons to Django - for a work project, for pretty much exactly the same reasons that he describes - inflexibility. In my case, lots of boilerplate for admin screens plus SQLAlchemy felt like too much magic. Particularly when trying to run functionality tests against my app, there were a few too many weird errors, with no obvious way to fix them (the solution was normally to move the database commit around), when the application worked fine. Django tests on the other hand, Just Work(tm).
So far I haven't run into any lack of flexibility on Django's part, and I've been using it for fairly serious stuff (mainly as a general-purpose CMS, heavy admin screen work). From the look of the original author's sites, the things that he's doing aren't too different, so I'm not sure what the problem is. Perhaps he just prefers the way Pylons does things?
Pylons is awesome because its purpose is to provide me with the magic that makes Python websites easier and that's it. After that, it leaves me alone to write Python. It doesn't impose a certain toolkit on me; though Pylons suggests a certain ORM and templating language, there is no obligation to use them, and everything will swim along just swimmingly if I want to use something else. These things are all replaceable and interchangeable.
In my mind, Pylons is what a framework should be. It gives you a handy set of conveniences, functions, and configurations designed to overcome and share much of the monotonous and repetitive solutions necessary to reach the specified end (in Pylons's case, developing web apps in Python) and then it gets out of your way.
When I write Pylons, I am mostly writing Python; it's just like any other Python application, except in the places where I want a shortcut specific to the web-based nature of my program, and then it's an elegant, unassuming function name or shortcut that doesn't get in the way or announce itself.
However, when I've used other frameworks, like Rails and CakePHP, I've felt more like I am writing programs in Rails or CakePHP than "real" Ruby or "real" PHP. They all seem to demand a way of doing things that's quite different from the usual flow of those languages, and the resulting apps don't feel like apps anyone who reads Ruby or PHP could follow. CakePHP particularly has its own implementation of almost everything and relatively few lines of pure PHP ended up in the codebase.
Worse, those frameworks were tightly coupled with their custom ORMs, templating languages, and other important affixes that really deserve their own projects. Pylons's assumed toolkits are full-fledged, external projects, and if I don't like their suggestions of Mako and SQLA, it's really easy to drop in whatever suits my fancy. It's done in the normal Python way. Pylons isn't going to give me any extra guff over it, and it doesn't care if I use SQLAlchemy or DB-API directly or whatever I want to use.
I really love Pylons for all of this. I hope more frameworks start adopting these philosophies.
I think it was more that the automated web testing part of Pylons wasn't particularly well integrated with SQLAlchemy. So (eg.) it's basically impossible (AFAICT) to populate the database with preexisting data and then directly call the controllers, since when you commit the data in your controller, you can't access the database afterwards when you get back to your controller. Instead, you get lots of odd tracebacks - things like "Instance <Foo at 0x103779f90> is not bound to a Session". It also means that you can't do rollback type testing - you have to stick different data in, or blow it all away and recreate it manually.
Django on the other hand, has fixtures, which you can create from your existing database, and use rollbacks, so they're really fast. Combine that with the test client, and I can just write my test cases and forget about setting stuff up. People often go on about Django's admin interface, but I find that the rest of the framework is written to the same sort of standard, so there are lots of hidden gems (like fixtures) just waiting for you to find them.
I think it's better to keep additional logic in your page view functions instead of letting it bloat the template html. Why use a two pass method to parse your custom template logic into python code when you can just write the python code in the view functions?
Wow. In summary, he switched from Django to Pylons because:
- He couldn't figure out how to modify his Pinax project
- He couldn't get django-openid to work
- There's no debugger on Django exception pages
- Something about magic imports?
You don't have to fork Pinax to add/remove apps to it. You don't have to fork django-openid to use it in your project, just override the templates. Recaptcha fits into the app model very easily: it's just another auth backend. You can get a debugger on your exception pages by installing django-extensions.
As a Django developer myself, I totally agree with some of his frustrations. For example one very common problem I run into with Django is that a typo in a urls.py file will manifest itself as a URL reversal problem with the first attempt at URL reversal. The error always point to the same file and it's never the file with the problem, or even the same type of file. Not helpful.
While I agree that the problems could have been worked out with more knowledge of the framework, it doesn't help to gloss over the issues. For almost all of the problems he mentioned, Django's got a lot of room for improvement and especially those who love it should admit that.
It should be possible to add a pdb.set_trace() or ipdb.set_trace() to the part of Django that traverses the URL tree. Then it should be possible to watch every URL be evaluated until one matches your request.
Don't ask me where it is, but, if you find it, it's worthy of a blog post ;-)
The debugger he's so fond of is actually the Paste debugger (paste.exceptions.errormiddleware.ErrorMiddleware). See http://gist.github.com/326254 on how to use it with Django WSGI deployments.
Secondly, Django is nearly unparalleled when it comes to CMS-based work. It probably is the wrong choice if you're looking to build the next Google, but for anything involving a system where the administrators are computer illiterate, it's always a winner.
As for the entire reusable apps thing, I have to agree. It's good for namespacing, but other than that, it doesn't have many benefits.
Just spent a week refactoring our Django projects into apps. Nice timing.
The more I think about it, the less sure I am that the django-app is a good model for any organisation of code (not just third party reuse).
In my mind web apps consist of [parts of] pages / templates, menus, forms, and url structure and underlying models. Django forces me to separate these concerns. A Good Thing. Then it turns around and forces me to define a group (app) and lump a bunch of them together again.
I disagree. It certainly doesn't force you to do anything. I am working with a team on a legacy web app we are converting to Django. Because of the legacy nature we have had to extend and override some of the functionality provided by Django and have found it an easy and logical process.
And grouping models/forms/views/templates etc certainly has made sense for us considering the large amount of code we are dealing with. Finding the relevant section of code is a painless experience.
I do agree with the articles complaint about obscure import errors. My solution when dealing with that is to drop into the shell and do the import there to get a better error message. Not ideal but so far it has been the only pain point we've had to deal with.
Good call on the apps. I think we can agree the idea of reusable apps hasn't really worked out. Still, I don't see how this tips anything in favor of Pylons. As for the debugger, I've been using pdb extensively. Errors thrown by templates are very annoying however, showing a huge stack trace through the template rendering scope and nothing to do with whatever caused the error. To solve this I've had this at the bottom of my urls.py (http://dpaste.de/9Emp/). It prints out exceptions straight to runserver. Also useful if you're letting project managers test your site and they come across a bug - you can just inspect it right away.
In python world, rack is WSGI. Pylons is built around wsgi concept, thus has access to wsgi apps. I'm not sure how Django handles WSGI entry points. It's been a while since last time I worked on django app.
I agree with his complaints about reusable apps to an extent, but I feel a lot of the fault has to do with the design of the apps he referred to. I feel that the good apps are the ones that focus on a very narrow scope and try a singular problem (Paypal integration, Twitter integration, etc). Pinax tries to shove every social media idea at you. Other ones like Satchmo (shopping cart) even have their own templates and styles, sorta like a CRM where you're kinda meant to use the Admin to manage your shop. I think you can get decent flexibility with Django as long as you choose simple apps.
I've always liked the Django debugging information and haven't had too many problems. I agree that it's very possible for many to feel limited by the ORM and standard templating system.
"I agree that it's very possible for many to feel limited by the ORM and standard templating system."
For me Django 1.2 is smoothing both of those over. The raw_sql method lets you construct your own select statements and turns the results into python objects. Also the if tag is much better. If template tag creation got cleaned up, I would have almost no problems at all with the template system.
To some degree, this is a failure of the Django community's messaging. Django is highly modular and, if anything, disassembles gracefully as you start running into more complex scenarios (even more so in 1.2 than 1.1).
It's best to think of Django as a robust set of wheels you don't have to reinvent for each new site you build, and a toolkit for building new wheels you can not-reinvent next time around.
All of the above is painfully obvious to anybody who has spent a decent amount of time with Django, but might not be so clear to somebody just finding their way or using Django in a limited fashion. I'm sad to see that somebody had a poor experience with Django, but this post is basically a lot of whining about an inability to figure things out and use the framework as intended.