Django: First Impressions

Django Software Foundation logo.

The Django Software Foundation does not endorse or sponsor the author or this blog.

Over the last week I spent several hours going through the Django tutorials. I do not have any prior web development experience, and I had expected it to be much harder to use than it actually was.

Django Reinhardt. Image: Wikipedia.

Above: Django Reinhardt. Image: Wikipedia.

Django, named for jazz musician Django Reinhardt, is a Python-based web framework. The main features of Django are its data-model syntax, syntax, database API, administrative interface, use of URLconf files, view-template system, caching framework, and syndication framework for RSS [4]. The data-model system uses Python classes that are subclasses of django.db.model and are processed as if each attribute of a model were a database field [5]. This integration with the database allows the database API to conduct lookups with dot syntax (e.g., Computer.objects.get(id=1)). The URLconf system maps URL regular expressions to Python views that generate pages in response to a request matching that URL pattern. The view-template system (views and templates are both Python classes) has view files either raise exceptions, or load a template and use it to render a page that is returned as a HTTPResponse [4].

One of the major principles embodied in Django’s design is the DRY principle, or “Don’t Repeat Yourself.” Dave Thomas (no relation to the “Wendy’s” founder) describes it as the idea that every piece of project knowledge – code, database schemas, unit tests, and build system – should be represented in only one place in a software system. This reduces the amount of duplicated code that would otherwise have to be maintained in parallel [6]. In Django, this is implemented as “Every distinct concept and/or piece of data should live in one, and only one, place [3].” This commitment on the part of the developers was demonstrated in the tutorials by the ability to have urls.py files reference each other and by the emphasis on using generic views. Though I had some issues setting up the tutorial’s generic views, I do support this idea in theory – having worked on several Java student projects where code was copied and pasted around in order to reuse methods in otherwise unrelated classes, I have seen the problems uncontrolled code reuse can cause even in small projects.

Django’s developers claim that it follows the Model-View-Controller (MVC) architecture pattern, except that the “view” is the Python function that describes which data is presented and is associated with a URL, and the “controller” is provided by the framework that sends requests to the correct view. The view actually is dependent on the template to describe how the data is presented. The developers’ response to questions about the MVC “inconsistency” they are sometimes accused of is to collectively shrug and say they prefer that the framework works in some way that makes sense to them instead of being bound to an arbitrary standard [2]. Django’s widespread adoption points to most of its users not much caring about this minor inconsistency very much. If one is a “perfectionist with a deadline,” the perfectionism must frequently be moderated to the deadline for practicality’s sake, and so long as Django works and does so consistently, the developers in effect argue, it does not matter so much what things are called. If something were widely supported and worked in a documented, consistent way, I think I would be satisfied with it even if it did not explicitly meet a standard.

XKCD #927

Above: XKCD comic #927, “Standards,” by Randall Munroe. In the end, the Django designers went with their own implementation and decided to stick with it.

Were I to have to build a data-driven website of medium complexity, I would probably choose Django because I have some familiarity with it and Python (When all you have is a hammer…) and because it has a reputation for scalability, being originally designed for a large news site. Like most web frameworks, Django operates at a high level, making some customization difficult. Most of the database work is handled behind the scenes based on the models, views, and templates, and the authentication system is provided by the framework. As with other high-level tools, it is easy to pick up the basics but the ability to customize it is limited. Competing Python frameworks include Pylon (now Pyramid) and TurboGears 2, which claims to offer more JavaScript support and better support for multiple databases. There are many frameworks for other common web development languages (PHP, ColdFusion, and Ruby) and Wired Magazine’s Webmonkey site compiled this list in 2010 [7]. An informal 2006 comparison of Ruby on Rails and Django concluded that Django had weaker Javascript and AJAX support, but that the preconfigured administrative interface in Django took less time to configure than in Ruby [1]. Both of these articles are probably long outdated by now, and there are many factors that can affect what a particular site requires, so in the end the best solutions to deciding among frameworks are probably to pick one in the language you know best, or to set up a sample application in each framework and compare your results.

Works Cited

[1] Askins, Ben and Green, Alan (2006). A Rails/Django Comparison [Online]. Available: https://docs.google.com/document/pub?id=1ys7fEX-ZqROYb4rUJXvDnBJU_vNiqT75ecT5mLiytCk.*

*Linked to from an official Django blog, which describes the author information.

[2] Django Software Foundation (2013). Django appears to be a MVC framework, but you call the Controller the “view”, and the View the “template”. How come you don’t use the standard names? [Online]. Available: https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names

[3] Django Software Foundation (2013). Design Philosophies: Don’t Repeat Yourself (DRY). [Online]. Available: https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry

[4] Django Software Foundation (2013). Django at a glance [Online]. Available: https://docs.djangoproject.com/en/1.4/intro/overview/

[5] Django Software Foundation (2013). Models [Online]. Available: https://docs.djangoproject.com/en/1.4/topics/db/models/

[6] Venners, Bill (2003, March 10). Orthogonality and the DRY Principle: A Conversation with Andy Hunt and Dave Thomas, Part II [Online]. Available: http://www.artima.com/intv/dry.html

[7] Webmonkey Staff (2010, February 15). Get Started with Web Frameworks [Online]. Available: http://www.webmonkey.com/2010/02/get_started _with_web_frameworks/

Advertisements