Prosthetic Conscience

Web templating systems: be opinionated enough, but no more.

There’s some current discussion in the Django community on templating systems on Jacob Kaplan-Moss’s website and elsewhere.

I agree with the general argument. There is a rather fine line between putting too much power into the templating language, so that it either becomes a programming language in its own right, or simply a means of embedding primary-language code in the templates, and putting in too little, so that you can’t do more than variable substitution. That’s not a big insight in and of itself. I think almost everyone knows this by now.

What I think is significant is this:

1. Django’s templating system hits the sweet spot for web templating. Through a combination of good taste and (probably) luck, the Django developers have produced a templating system that strongly encourages web developers to put their controller logic and their view logic in the right place.
2. Django’s templating system is just tightly coupled enough to make people think twice before using something else. You certainly can use other view technologies, and it’s not really hard to do so (just do everything your other template system to produce a string or a file-like object representing the content of the response, and pass it as an argument to the Django response object you’re going to return).

   But neither the documentation nor the code for Django imply anywhere that other templating systems are just as good, just as suitable, or just as well-integrated into Django. The documentation mentions that you can use them, but only gives examples of the Django templating system. The code contains many shortcuts for using the Django templating system (e.g. render_to_response()) that can’t be used with other systems.

I think the latter point should really be emphasized more. The core Django developers like to talk a lot about how Django is loosely-coupled. And that’s sort-of true, and it’s a good thing. You don’t have to buy into everything to use Django. Django applications are just plain python code; they’re written not a special mini-language. But, Django is tightly coupled enough that there is only one obvious way to do it.

Here’s what I mean by that. In my work life, I’ve been learning a more corporate-friendly web development platform, the Spring framework for Java. Mostly Spring is a good thing. It manages to drag corporate web development halfway from J2EE-hell to Django in the same way that Java dragged corporate programmers halfway from C++ to Lisp. Once you get past the Enterprise Architecture Astronautics (not as bad in Spring as in other Java frameworks, because of the extensive use of interfaces rather than inheritance) and reams of XML configuration files (apparently significantly reduced in Spring relative to other Java frameworks!) it’s actually not bad, and developing for Spring MVC is very much like developing for Django while wearing mittens – you use the same patterns, but it takes twice as long to write.

But, the frustrating thing about Spring is that it is completely non-opinionated. How shall you do database access? They don’t care, and not only do they provide wrappers for the top 10 ORM systems as they’ll as plain JDBC, they support multiple completely different styles of using one of them, which require different layers of proxy objects and (of course) different XML configuration. And view technologies? They don’t much care which of those you use, either – pick one and use it. All this may make sense in an environment where the ORM layer and view layer can be mandated by corporate policy, but it’s no way to build a framework developers can be passionate about.

(Side note: for the templating language to use with Spring, I’ve settled on Apache Velocity. It is much like the Django templating language in scope, in that it interpolates variables and their properties, offers conditional constructs and iteration over collections, and so forth, but does not constitute an entire embedded programming language, or make it too easy to drop into the implementation language. Like Django’s templating language, it is a plain text language that is not tied to generating XML output. It doesn’t have two of the nicest features of Django’s template language, template inheritance and block substitution, but these are very easy to implement yourself by following certain conventions. Velocity is much closer to the templating sweet spot than JSP/JSTL.)

Django has been accused by passionate users of other Python web application frameworks of suffering from NIH Syndrome; or to put it another way, of being too opinionated. But the NIH components of Django (the ORM and the template system) provide very good implementations of that functionality for most of the target audience. If your needs are complex enough that you have to use something else, then you probably also have the skills to deal with the consequences (for example, SQLAlchemy can map existing databases that Django’s Models can’t – but if you use it, your app doesn’t get Django’s admin functionality, and probably can’t use generic views). So it goes. But the risks of being not opinionated enough are worse:

• The framework is harder to learn, because the documentation of different components may be spread across multiple projects, and new developers may have to learn multiple components in the same category in order to choose which best suits their project, instead of just diving in with a well-designed default.
• Different projects using the same framework will tend to be written in different dialects or subsets of the framework (e.g. Hibernate-Spring-Velocity vs. JPA-Spring-JSF).

So it’s not just that Django’s templating system hits the big bulgy middle of the bell curve, but that the project as a whole does. Opinionated, but not too opinionated. Enough salt to bring out the flavors, not enough to overwhelm them.

[ Posted: 09:56] | [ Category: /computing/django] | Permalink | Comments: 3 ]