3 ms·

That was pretty much my first impression of Django as well, and I bet it's the impression they want to leave. The reality doesn't really hit home for a few wee

That was pretty much my first impression of Django as well, and I bet it's the impression they want to leave. The reality doesn't really hit home for a few weeks. Django gives you all sorts of really cool stuff right out of the box that does nearly everything for you. The problem comes when you want to do something just that little bit different, and you find yourself unrolling every single piece of it one-by-one as you discover that these pieces don't fit your needs exactly. I also found myself baffled by the terrible decision to make everything revolve around function calls rather than a Request and Response object. No matter what happens in your page flow, you still need to return a HttpRequest object at the end of the day. No more Response.Write();Response.End(); from any point. You need to have every bit of code capable of returning in a way that triggers the thing above it to return in a way to trigger the thing above it to return a HttpRequest object. Makes debugging a serious pain. So yeah, if you're doing a simple CMS for a media site (which is what they wrote Django to do), it rocks the house. If you're trying to do any heavy lifting, it seems to fall apart pretty fast. I don't think I'd use it again.

nonrecursive 18y ago
Thanks for your comment. Zed's review got me pretty interested in Django, but since I'm not building any CMS's for media sites, I'll just stick with Rails and merb for now. Thanks for saving me some time :)
bluefish 18y ago
I've had a very similar experience, but I have been wanting to see how the more current versions hold up.
shimon 18y ago
I've been hacking Django apps around 50kLOC for a couple of years and have found it generally very well designed. It is true that the best-documented interfaces often don't meet your needs exactly, but I've had a lot of good results reaching into Django a bit. Sometimes this just means using some inconspicuous base classes instead of more "convenient" subclasses. Other times it results in some hacking monkey patches. But on the whole, I've found that it saves me time frequently, and in cases when it won't, it gets out of the way pretty fast. That said, it is still a full-stack framework, and it is definitely targeted at sites that mostly serve dynamic pages. Like all frameworks, it has its archetypal projects, and for Django it's blogs/CMS/online community apps. The further your project is from that archetype, the less useful the framework will be.
simplegeek 18y ago
I've not used Django but I'm intrigued by your thoughts. I want to stick with Python, do you've a recommendation for a Python web-framework?
cstejerean 18y ago
Interesting, I spent most of the last year working on two serious Django apps, both of which were very different from the kind of sites Django was first designed for. Replacing the things that didn't work for us with custom components was incredibly easy. By writing middleware and custom template tags we were able to quickly add the functionality we needed. Sure, there were times when we were frustrated by some Django design decision, but ultimately I walked away really happy with Django as a framework. In the past I have used Rails and Pylons and so far I prefer Django and will likely use it as a starting point for most of my web development, at least until I can start using Clojure more often.
njharman 18y ago
> No matter what happens in your page flow, you still need to return a HttpRequest object at the end of the day. I think you mean HttpResponse object. We must use Django differently (Do you use templates and contexts?) I don't understand what you are saying in your bafflement paragraph. And your evaluation of good for simple but not for heavy lifting is the exact opposite of mine. I love Django cause it makes the simple, simple and and the hard, possible. Each view function takes a Request + parameters and returns a Response. Simple, consistent, and flexible. Easy to write decorators. Easy to reuse view functions, easy to compose view functions from parts. Easy to ditch the whole thing and roll your own. Django is extremely well decoupled. It comes with all sorts of batteries included but it's very easy to take out a battery and use your own. Templates, storage, url routing are all easily replaced. Apps can come and go, middleware can come and go. And most the functionality admin/auth/caching/templates/storage backend/sessions/etc are split out into apps and/or middleware so it's easy to replace/extend if you need to do something special. Recent releases have made even made the admin much easier to customize without wholesale replacement. I've even used Django for non web apps. I didn't have to do anything particularly special. It just worked. P.S. If you think "media"/newspaper sites are simple, you don't know newspaper sites.
bokonist 18y ago
I've always found django pretty hackable. If you really want to break the flow of returning objects, you can always use threadlocal to store the request object, the template, or whatever else you want.

nonrecursive 18y ago

Thanks for your comment. Zed's review got me pretty interested in Django, but since I'm not building any CMS's for media sites, I'll just stick with Rails and merb for now. Thanks for saving me some time :)

bluefish 18y ago

I've had a very similar experience, but I have been wanting to see how the more current versions hold up.

shimon 18y ago

I've been hacking Django apps around 50kLOC for a couple of years and have found it generally very well designed. It is true that the best-documented interfaces often don't meet your needs exactly, but I've had a lot of good results reaching into Django a bit. Sometimes this just means using some inconspicuous base classes instead of more "convenient" subclasses. Other times it results in some hacking monkey patches. But on the whole, I've found that it saves me time frequently, and in cases when it won't, it gets out of the way pretty fast. That said, it is still a full-stack framework, and it is definitely targeted at sites that mostly serve dynamic pages. Like all frameworks, it has its archetypal projects, and for Django it's blogs/CMS/online community apps. The further your project is from that archetype, the less useful the framework will be.

simplegeek 18y ago

I've not used Django but I'm intrigued by your thoughts. I want to stick with Python, do you've a recommendation for a Python web-framework?

cstejerean 18y ago

Interesting, I spent most of the last year working on two serious Django apps, both of which were very different from the kind of sites Django was first designed for. Replacing the things that didn't work for us with custom components was incredibly easy. By writing middleware and custom template tags we were able to quickly add the functionality we needed. Sure, there were times when we were frustrated by some Django design decision, but ultimately I walked away really happy with Django as a framework. In the past I have used Rails and Pylons and so far I prefer Django and will likely use it as a starting point for most of my web development, at least until I can start using Clojure more often.

njharman 18y ago

> No matter what happens in your page flow, you still need to return a HttpRequest object at the end of the day. I think you mean HttpResponse object. We must use Django differently (Do you use templates and contexts?) I don't understand what you are saying in your bafflement paragraph. And your evaluation of good for simple but not for heavy lifting is the exact opposite of mine. I love Django cause it makes the simple, simple and and the hard, possible. Each view function takes a Request + parameters and returns a Response. Simple, consistent, and flexible. Easy to write decorators. Easy to reuse view functions, easy to compose view functions from parts. Easy to ditch the whole thing and roll your own. Django is extremely well decoupled. It comes with all sorts of batteries included but it's very easy to take out a battery and use your own. Templates, storage, url routing are all easily replaced. Apps can come and go, middleware can come and go. And most the functionality admin/auth/caching/templates/storage backend/sessions/etc are split out into apps and/or middleware so it's easy to replace/extend if you need to do something special. Recent releases have made even made the admin much easier to customize without wholesale replacement. I've even used Django for non web apps. I didn't have to do anything particularly special. It just worked. P.S. If you think "media"/newspaper sites are simple, you don't know newspaper sites.

bokonist 18y ago

I've always found django pretty hackable. If you really want to break the flow of returning objects, you can always use threadlocal to store the request object, the template, or whatever else you want.