Why I switched to Pylons after using Django for six months
mutualinformation.org
mutualinformation.org
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'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 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.
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?
If you take care to understand SQLAlchemy well, it won't get in your way either.
*(I concede that Pylons doesn't have a good automated admin feature.)
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.
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.
Simply the fact that it's a minimalistic framework (not another abstraction layer on top Python)
B) Use PISTON for APIs: he could have had it working WAY easier
C) Use SOUTH with the ORM. The ORM wouldn't make much sense on its own unless you like wiping your database a lot during development.
http://ericholscher.com/tag/largeproblems/ "Large Problems in Django: Mostly Solved"
It is a shame the tutorial doesn't point out South and Piston, everyone should be using them.
Otherwise it's crippled in comparison to Jinja or Mako - with large amounts of un-Pythonic boilerplate if you want to write template tags.
To an extent you can replace it but again you will have trouble with those "reusable" apps.
- 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?
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.
Don't ask me where it is, but, if you find it, it's worthy of a blog post ;-)
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.
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.
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.
What kind of software developer is afraid to (or don't know how to) do that?
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.
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.