Inspired by Guido van Rossum’s plea to be taught web frameworks here are (in no particular order) ten reasons why he — and you — should use Django.
1. Django works — right now
Don’t be fooled by the fact that Django’s first release was in July. It’s been under heavy use for over two years, and I’m confident saying it has no show-stopping bugs.
I’m tired of hearing that that SomeAwesomeFramework™ will be “great when it’s finished”. Django is finished, now — all the changes we’re making in the run up to 1.0 involve stabilizing APIs and improving the cleanliness of the internal code.
2. Deployment is a breeze
The web framework world is full of sad tales of deployment woes. You can even read horror stories about deploying Rails, the leader of the dynamic web framework pack.
Not only is there a well-established way to deploy high-traffic Django sites, but Django sites are very stable. We do over 15 million hits to a day to about ten sites, and that’s a single Django installation (one web server, one database server).
3. Your site won’t go down
Django sites survive Slashdottings (chicagocrime.org), Farkings (ljworld.com), and rabid NCAA Basketball fans (kusports.com).
(Funny story about that: a few weeks ago the editor of ljworld.com asked me to look into why we had 3 million more daily hits than usually. Turns out we’d been Farked, and I hadn’t even noticed.)
4. Django is fast
Every bit of the framework is designed with efficiency in mind.
I’ve seen benchmarks that peg Django’s template language at four times faster than Kid and six times as fast as Cheetah. In fact, it’s SO fast that we’ve found that caching compiled templates is actually slower than re-rendering them on every request.
Django’s ORM is similarly extremely careful to perform as few database lookups as possible, and to always make it obvious when database hits are happening.
And if Django still isn’t fast enough, it’s stupidly easy to cache performance-intensive bits (or even the whole site). One of the available cache backends is memcached which drives LiveJournal and Slashdot itself.
5. Django scales
From personal sites running on shared hosting to small band sites to huge databases of public info to social networking sites with over 500,000 users, Django handles it all.
At the top end, you’re only limited by your hardware budget.
6. Django’s admin will blow your mind
The most boring part of writing content-heavy websites is developing admin interfaces. How many times have you written a form validation function?
Well, Django’s admin is the most amazing thing to happen to content-driven sites since the invention of the database itself.
Seriously — even if you don’t want to use Django for some reason you owe it to yourself to check out what a site administration interface should look like.
7. You don’t need to go whole-hog
As I said above, Django’s admin interface will blow your mind. Luckily, you don’t need to port your legacy sites to Django just to use the admin interface; in a few moments you can introspect your database and have a awesome admin interface to your old data.
I know quite a few people who have started major Django projects this way.
8. Django plays well with designers
Programmers have criticized Django’s template language for not being Pythonic enough. There’s a simple explanation for that: the template language isn’t meant for you. Our new designer Jeff Croft picked up Django’s template language in about a day, and moved on to getting real work done.
Sure, if you’re building a site all by yourself the overhead of learning a template language might seem dumb, but when you get bought by Yahoo you’ll be glad you can hand off the design to someone else so easily.
9. Django comes from the Real World
Every single feature in Django exists because it solves a real world problem. If you spend any time on django-dev you’ll see Adrian repeatedly ask “what real-world problem does this proposal solve?”
Django rose out of the insanely tight deadlines inherent to the news industry — our deadlines are mere days, if not hours — and it will let you build huge amazing sites far faster than you ever thought possible.
At work we’re about to launch the best local TV station site you’ve ever seen, but what you’ll miss when you see it is that it was built in just a few weeks.
If the Romans had used Django, they would have built Rome in a day.
10. We’re here to help
I’m very proud of the fact that Django’s community is lively and extremely friendly. Whether it’s on django-users, django-dev, or the IRC channel, you’ll find smart people to help you out.
It might seem trite to say it, but I think our community is our biggest asset.
That and a lead developer who speaks Ukrainian.
Comments:
Is MS SQL Server going to be supported by Django? That's basically the number one reason why I can't try it out. Client constraints dictate that I can't use another supported DB.
Hey Sean -
As of mid-October Django does have support for MSSQL through the "ado_mssql" database backend. None of the Django developers are windows users, though, so the level of support is unfortunatly less than for open-source DB packages, but I know for a fact that it works.
Please give it a shot and file bugs if anything breaks.
django is nice, no doubt about it. but there are things to consider (please correct me if i´m wrong):
- the community is biased towards developer-stuff and not very supportive when it comes to user-related issues.
- the admin-interface is great, but hard to adapt. when its sufficient enough for your needs, go for django (it´s a real plus). but when you need to re-build it yourself (because it lacks some features), you may think twice.
- no API
- limited out-of-the-box authentication
good stuff (IMHO):
+ URL dispatcher
+ performance
Let me add how important it is that Django works as advertised. This is far less common than you might expect or hope for--whether the software is commercial or open source. This makes up for a whole lot of design quibbles one might have.
In response to Janik's 4 points:
- I guess it depends on what you mean by user-end issues--for a framework like Django, developers ARE the end users of the product...and there's definitely great support both on IRC and the mailing list (and the wiki) for those of us who develop WITH Django instead of actually developing the framework itself.
- I actually do just that, use Django to make customized form pages for an internal data entry suite. While it definitely does feel at times like I am reinventing the wheel, for the most part it's really easy to reuse what they've done for the admin. For example, the same engine that runs form submission and validation is exposed and easily usable in your own custom pages.
- This again depends on what you mean. The API is well documented on the Django website, and while they're continuing to improve and solidify it prior to the 1.0 release (especially the "magic removal" branch which aims to, well, remove the magical parts of the ORM) it's quite useable. If you mean a docutils-like full-coverage API, then no, that's not technically there, but the current docs suffice quite well for the time being, IMHO.
- I can't speak for the auth since I don't use it myself, but there's a TON of discussion about it on the mailing list. It's there, and it's simple without being too limited, as far as I know, and it is definitely in the box. It may not work perfectly for your specific needs, of course, but it is there.
I'm sure (or better, I know since I'm following its developments) that Django is an excellent framework with excellent developers.
Anyway I still can't see any good reasons behind your attitude of claiming that SomeAwesomeFramework™ (and we all know what framework you're referring to) it's not.
People have different needs and like different things.
What is this? A game where the python framework with more users wins something?
Get realistic and let people decide what's the best for their needs, in the end it's always python and we should be happy.
Thumbs up for providing a nice list of feature you should look for on your framework.
Thumbs down when you are bashing others frameworks.
Ciao, and keep up the great work (even more if they are python-brothers).
PS
Before linking Peter's blog have you at least read it's update on that post?
"UPDATE: It took me a few days to figure the problem out: I had an extra .htaccess file I didn't know was there, causing mischief and interfering with whatever I did in the main config file. I've got rid of it and turbogears/ cherrypy is working fine."
Hmm someone's been drinking the DHH Kool-Aid: "Well, Django's admin is the most amazing thing to happen to content-driven sites since the invention of the database itself." ;-)
On this point though, while very cool, myself and others have had questions (I think Janik above also) about the situation when the auto-admin gets you 95% of the way to what you need; whether one should try to hack/bridge the remaining 5%, or if it's time to use Django's libraries to write your own admin that does 100%. And I'm wondering how the new-admin branch that was merged changes/helps this (the wiki had vague statements like "making extending the admin easier"). Any examples for those just getting into the codebase?
'Cause it seems if it gets you 95% of the way, and that 5% can't be bridged cleanly, then it's more akin to Rails' scaffolding feature, in that it's a handy way to get up and running but not useable as a production UI/app. If you only need what it does, then agreed, it's great.
thanks
Michelle: honestly, I wasn't refering to TurboGears in particular wit the SomeAwesomeFramework crack. Sure, it was in my mind, but so was Catalyst, Seaside, and others. My point is that there's a lot of partially finished products out there, and I wanted to make sure that everyone knows that Django *is* finished enough to be used for real.
Bashing other frameworks isn't my intent; provide reasons why you should use Django is. The fact is that deployment, stability, and speed are actually very hard -- even with intrenched tools like RoR -- and it's important to note these are solved problems in Django.
I really don't see this as a competition. However if you decide to use or not use Django I'd like it to be for the right reasons!
ToddG: Yeah, maybe it's a bit over the top, but c'mon, it's so hard to avoid the hyperbole. And actually I have to stick by that comment: you can't even imagine how much time Django's admin saves me. I couldn't live without it.
As for the questions about he auto-admin: yes, it's not going to do everything for you. In particular, it assumes that you have people you *trust* that update the data on your site. If that assumption doesn't hold true, then yes, you'll need to write custom views for that.
The new-admin stuff (that was introduced in 0.91) makes modifying the admin screens very easy -- I hope to document this more shortly -- but doesn't make the basic assumptions any different.
Luckily, the form/validation framework is pretty damn easy (see http://www.djangoproject.co...) so building your own form views for public consumption is quite easy.
No generic admin interface, no matter how good, can do all your work for you, but I'd like to think that it's pretty easy to pick up where Django's admin lets off and do the "other 5%" yoursef.
(I've been asked a few times about these situations where "the auto-admin gets you 95%" but I've never actually seen any specifics about what people are having difficulty with, so I can't comment further on that.)
regarding "well, django´s admin is the most amazing thing ...": while overpraising djangos admin-interface (which is good in my opinion, but has some severe issues - see Todds posting), it´d be nice to give some details on what it does exactly (and more important, _what not_).
quick note to jacobs last comment, especially
... 'I've been asked a few times about these situations where "the auto-admin gets you 95%" but I've never actually seen any specifics about what people are having difficulty with, so I can't comment further on that' ...
i´ve posted an issue on the mailing-list a couple of days ago. right now, it´s not possible to edit/delete multiple records at once - which, in my experience, is a very common task (a so called "real-world problem").
Ah, yes it's Patrick that was the "other people" I was mostly thinking of.
"No generic admin interface, no matter how good, can do all your work for you, but I'd like to think that it's pretty easy to pick up where Django's admin lets off and do the "other 5%" yoursef."
Of course -- that's where my question comes in: what I had asked on that thread was how best to do that 5% -- tying custom views into the auto-admin, or re-writing everything with custom admins and not using the 95% the auto-admin provides? It looks like tying in to the auto-admin isn't the easiest thing.
To use a bad analogy, is it better to "hack in" the last 5 feet of a bridge over the river, or rebuild the whole bridge using custom views/manips? Wow that's a bad analogy...
Patrick: yes, deleting multiple objects at once in the admin isn't easy; yes, it's on the old TODO.
ToddG: Actually, adding your views into the auto-admin couldn't be easier; just use the staff_user_required decorator from django.contrib.admin.views.decorators (and then extend the admin templates if you want a consistant look and feel). Then it's just a matter of writing whatever view you'd like to present in the admin.
So, to following your analogy (which isn't all that bad): build the last five feet yourself -- it's actually very easy.
sorry for maybe being to small minded here, but ...
... "yes, deleting multiple objects at once in the admin isn't easy" ... "build the last five feet yourself -- it's actually very easy" ...
well, it´s obviously not. moreover, talking about "real-world problems", so far nobody (including your above posting) has commented on the issue of editing multiple records in the admin-interface.
please, don´t confuse potential users with phrases like "djangos admin will blow your mind" without any details and limitations. that´s just tedious.
Sean: couple days ago I posted another patch (http://code.djangoproject.c...) to utilize another MS-SQL connectivity layer (pymssql/freetds). It's useful if you connect to SQL-Server from a Linux/UNIX box. It passed all Django's unit test cases except two minor one regarding datetime field by then. I made it for the same reason that my client's environment also dictates MS-SQL. It works pretty well in small scale, but I haven't seriously use it too much because my client haven't been fully convinced to adapt Django over existing Java stack.
Guido doesn't seem all warm and fuzzy about the way Django has done things. He went so far as to call parts of the implementation 'un-pythonic'.
I do not believe your 10 reasons address his main concerns. Lets see which way the dutch cookie crumbles ;)
Hi Jacob, do you mind if I translate your 10 points to the Czech lang. and put it on my blog?
Radek - of course not! That sounds awesome.
Er, on reading my comment it doesn't sound so clear: I mean of course *I don't mind* -- please go ahead :)
"please, don´t confuse potential users with phrases like "djangos admin will blow your mind" without any details and limitations. that´s just tedious."
If I sell you a prefab house that doesn't have a window where you want it, you can install a new window. That's still cheaper and faster than building your own house.
That said, that particular window is in the blueprints for future versions of the admin.
>to huge databases of public info to social networking sites
Judging by .jsp extensions of its pages, grono.net is Java based..
Patrick,
I'm using Django right now for my in-house Finance department to "bulk" edit multiple items. You'd be surprised how I'm doing it, though. I'm generating an XML file and letting the user download it from the website... Then they use Excel for the "bulk editing", save again as XML, and repost back to the server. I'll document blog/this when I'm done. I *could* try to emulate the bulk editing features of a spreadsheet with something like TrimSpreasheet (http://trimpath.com/project...), and I hope to do that someday... but those "real world" finance dept. employees prefer the Excel interface... So "let them have cake", I say! By limiting the use of Excel to its strong GUI features for bulk editing (filters, sorting, searching, etc). I get the best of both worlds. And after the users are done, the results get posted back to a nice, clean, normalized relational database. No yucky spreadsheet files with massively important un-auditable data lying around on everyone's harddrives.
- Jason
Jason, Using Excel as a familiar front end for finance people to do the "bulk" data manipulation sounds wise.
Can you give us some clues on the standards (defacto or indep) you used to move data from XML to Excel (and back)?
I've not yet read the Danjo tutorial, but can or does your app just use the usual Python lib modules for SAX or DOM/PULLDOM style XML parsing? Lastly, what shortcut did you take for generating the XML?
@just 3 cents:
You seem to hit the nail on the head. I've often seen ads like "big company uses our product" when in fact the big company might well have been too big to not use that product (because you can't rule out usage in some corner of it). I dislike such ads very much, but maybe there is some more detail for which they use it?
I *hope* grono.net doesn't use django. Did you look at the html source for those pages? I think it warants a moment of silence for the unfortunate devs who have to maintain that thing.
Thanks for open sourcing this great solution framework. I love Django! I have a sample site that is running over 100,000 pages using Django at:
http://www.securitybuzz.org/
Okay, this has won me over. Heading over to the Django site as I'm typing this. :)
@sean:
Sorry, Django has very poor support for SQL Server. The patch below makes it work together with SQL Server but still not fully functioning:
http://code.djangoproject.c...
(No built-in paging support for records)
I am not a professional programmer, but I use PHP to construct my site since 2002. It contains only 10+ pages(.php), using mysql. It works, still earning me a living. For small site I don't need framework at all.
But recently, I begin to start planning a new project, that is, a content management site. I feel that using page by page PHP for that will be a HELL job, so I seeking for the help with a framework.
Cake, Symfony, seem to be too complicated for me, making more problems than solving my problems. Code Igniter, with very handy document, but still HELL using for big content management.
Ruby on Rails, I know that piece of x's existence two years ago. But until now, I STILL can't understand what the HELL it is taking about(may be I am stupid). I just know the deployment is another HELL.
Finally, I was stopped by Django, a framework that based on a language(Python) that I had learnt(beginner level). Just because I understand what it is talking about, thanks for the good documentation. It seem to be a promising framework for content management.
Although the author of this blog may seem to over advocate, Django really is a good framework to follow. Browse the list of Django powered site at http://code.djangoproject.c.... Compare that of other framework, this help you to make decision on framework choice.
Many thanks for the inputs folks.... I would have almost certainly preferred Aaron Swartz' Web.py for my project but for the excellent activity in the Django community and the swift response times for the tickets. Plus of course, the proven scalability of the framework in commercial deployments. Keep up the good work folks!
Timmy Jose.
(BTW : I am a big fan of Django Reinhardt myself and knew that your project was probably based on the maestro's name!)
Leave a comment: