Where is Django’s blog application?
In terms of people looking for sample code or example applications to use/learn from, “where can I find a good Django-powered blogging application” is probably at the top of the frequently-asked questions list both on django-users and in the IRC; part of this is simply that, right now, there is no “definitive” Django blogging application; there are a bunch of them available if you go looking, but you’re not likely to get anyone to recommend one of them as “the” Django blogging app (unless the person doing the recommending happens to be the author of one of them).
In a larger sense, though, I think there’s a big gap between what people want/expect/look for from a Django-based blog and what feels “natural” to do in Django, and that gap is probably the reason why there isn’t — and may never be — a definitive Django blogging application. As it turns out, this also leads neatly into some important ideas in designing Django applications and some speculation on an important shift in methodology, so let’s take a deeper look.
How I built this site
When I sat down to rewrite my Django-powered blogging application, I had a specific feature list in mind and started out implementing things on it one by one, but along the way an interesting thing happened: instead of ending up with a single all-in-one application to handle everything I wanted, I kept spinning off separate applications to handle specific bits of functionality. Most of the apps I’ve released over the past six months — things like comment_utils, the contact-form app, etc. — started out as features which were going to be integrated into my blog app, but became applications in their own right.
The reason for that is pretty simple: Django encourages a development model based around tightly-focused “pluggable” applications. I needed a contact form, for example, but that’s something I’m going to need for lots of different projects, so I spent a couple of nights making it a bit more generic and reusable, then released it as its own application. Ditto my template utilities and comment-moderation code. When I wrote the app that powers djangosnippets early in the year, I did the same thing: user registration was something I knew I’d need all over the place, so tying it tightly to the snippets app, when I could just as easily break it out into a reusable application, wouldn’t have made much sense.
So when I did finally finish my blogging application, it was pretty lightweight; the code is online (though unsupported and undocumented right now, aside from docstrings embedded in the code itself), but you’ll find that it’s really just three models and some wrappers around generic views. Everything else was supplied by other applications; django.contrib.admin provides the admin interface, django.contrib.auth does what little authentication I need, django.contrib.comments provides the comments system, and a combination of other contrib apps and my own and other folks’ third-party applications round out the full functionality of this site.
In general, that’s what I personally want from a Django blogging solution: something that can be plugged into any site I happen to be working on, and which is happy to “do one thing and do it well”, trusting that other applications will take care of functionality outside the direct scope of writing a blog.
But that’s not the only way to do “blogging”
Meanwhile, most popular blogging software — Wordpress, Movable Type, Textpattern, etc. — is oriented around almost the opposite philosophy: the blog application is a monolithic all-in-one system which provides everything: blogging, user auth, templating, admin interface, plugin API, the whole nine yards.
There’s nothing wrong with that, of course, and the popularity of software like Wordpress is a testament to how effective this methodology can be, which is probably why so many discussions of Django-based blogging software end up involving the phrase “Wordpress clone” at some point. Having a single piece of software to install is an extremely powerful technique for improving adoption.
But it’s not something that really seems like it’d fit well with Django: you could write a monolithic Wordpress clone using Django if you wanted to, but you’d be reinventing an awful lot of wheels and tightly coupling them all to each other, which seems like it goes against general best practices for developing Django applications. Or, perhaps, focuses on a different use case than Django typically does: Django came out of an environment where the ability to put a site together by combining a default set of reusable “stock” applications and a few customized site-specific apps was essential, and that sense of being focused less on monolithic “all-in-one” applications and more on sort of “reusable building blocks” remains in Django (and is generally a good thing, if you’re a web developer looking to build things on a deadline).
Which brings us to the gap
I think this points to the primary reason why there’s not a “definitive” Django blogging application: writing one app which would handle all the things expected from a traditional blogging package like Wordpress simply doesn’t feel natural in Django. Again, that’s not to say it couldn’t be done, just that there’d be an inevitable temptation to start spinning functionality off to separate applications. I’ve been there, I’ve done that and I know that sooner or later you just get fed up feeling like you’re going against the grain.
And from the perspective of a developer using Django, a Wordpress-style self-contained “all-in-one” solution probably won’t be as attractive as something which can be plugged into an existing site and take advantage of other standard and/or popular Django applications. An app that requires its own administrative interface and user auth system separate from django.contrib.admin and django.contrib.auth, for example, would always be a second-class citizen in the larger ecosystem of Django applications.
How to resolve this?
At work, we develop, use and sell an online publishing system, geared towards news organizations. It’s called Ellington, and it’s the system from which Django was “extracted”, in much the same way that Basecamp is the system from which Rails was extracted. Ellington is not a single application, though; it’s actually a collection of Django applications, each of which focuses on a narrow aspect of doing online news, but all of which complement (and in some cases depend upon) each other. That’s been a great model for us, because it opens up the ability to build sites by mixing and matching a subset of the standard Ellington apps, or to sell “editions” of Ellington focused at different types of sites.
Ultimately, I think the only way to resolve the tension between the desire for “all-in-one” packages and pluggable “building-block” apps is going to be this sort of approach: rather than a single definitive “Django blog” application, for example, I think it’s much more likely we’ll see a collection of applications which, taken together, provide all the key functionality (while allowing a certain amount of mixing and matching in order to customize the finished product). I don’t have any idea what the packaging for such a thing would look like, since I’m almost certain that all of the apps won’t be developed by the same person or group of people, but it’s something I’ve been thinking about a lot lately, and I’d love to hear ideas :)