Generic views suck

There’s a lot to like about Django. It’s Python. It has a large, fun community. It’s elegant. It simplifies web development, but Django never simplifies things to the point where it would kick you in the back later on : not too much magic, no cumbersome integration with a javascript framework (hello Rails!) and a lot of documentation.

There are two little things about Django that just feel so incredibly wrong to me, though. Number one: generic views. Number two: the flatpages contrib app. They both violate the “make it simple, but not simpler than it should be” ethos that is otherwise so engrained in the way Django is architected.

Don’t fuck with the mental model

Django is great in part because its elegant project structure makes it easy to remember where you’ve put stuff, and where to go look if something goes wrong, or when you want to add a new feature. Rafe Colburn, when talking about what makes a good programmer, says:

One attribute that I think may be important is the capacity to keep the details of a large system in your head. What I mean is, the ability when someone brings up a new feature, to quickly know exactly how it should be implement in the context of the existing system. Or, to be able to recall where the code is in the system that performs some function

And Django makes it easy to be a great programmer, because it gives you this very simple project structure.

The Django docs explain that generic views make a few simple, monotonous tasks more painless. You shouldn’t need any boilerplate code in your views to create what are indeed generic list and detail pages — there’s nothing really happening in the view anyway except fetching a few objects and pushing them to a template. True enough: in any application and website I’ve built thus far, I’ve encountered a few list/detail combos. Lists of users and their individual profiles. A photo gallery with an overview but also a page for each photo. And so on.

However, the trouble with generic views is that, in order to save on a bit of boilerplate, they completely mess up the Django’s simple mental model. Code suddenly lives in a whole different place not just depending on which purpose it serves, but  also depending on how simple or complex it is. That’s certainly a… quaint way of organizing code. The code for mixing stuff together can now live in both urls.py or views.py. Flatpages is just as annoying, and for entirely the same reason: stuff gets routed around using urls.py, or, oh, yeah , with this dodgy FlatpageFallbackMiddleware that magically transforms a 404 into something else entirely. Messing up other middleware in the process.

Both generic views and flatpages make it harder to be great. They raise a whole bunch of PEP 20 red flags, most notably: “There should be one— and preferably only one —obvious way to do it.” And what do you get in return? Close to nothing. Web pages more often than not grow beyond what generic views or flatpages can do for you, so at some point you’re going to break most of them out into real, proper views anyway. Why not do that right from the start?

Generic views and flatpages are easily avoided. You can just not use them, and code in Django as if they didn’t exist. So complaining about these little Django warts might be a bit inane. They just feel like cruft, though, something that might’ve made sense for The Lawrence Journal-World way before Django got opensourced, but today, it just encourages bad code organization practices. Don’t use ‘em, just don’t.

And that’s the word.