In this week’s edition of II’s summer guest blogger series, Richard Cornish discusses Django, both providing examples of Django projects and a brief history of how it came about. Cornish is an interaction designer at the Lawrence Journal-World, where Django was developed.
You’re probably pretty tired of your newspaper’s content management system.
You’re cramming photo features, event listings and obituaries into headline, byline and body fields. You thought the Web was going to be cool and cutting edge, but everything feels like jamming the proverbial square peg into the round hole. It’s slow, ugly and painful, and graduate school is looking a lot more attractive.
You think there must be a better way. You’re not alone, and there is.
Web developer Adrian Holovaty wrote “A fundamental way newspaper sites need to change” in September 2006 and set off a small fire storm in the journalism blogosphere bubble. Holovaty’s premise was that newspapers are collecting incredible amounts of valuable data and then discarding almost all of that value by jamming all of its information into the form of a story, namely a headline and a body.
The first and most important lesson in understanding the Django Web framework is that things in the real world are different from one another and therefore have different characteristics to which they can be referred. An article has a body, but a drink special does not. An event listing has an ending date and time, but a photo does not. A politician has a party affiliation, but a weather forecast does not. Cramming and stuffing every piece of information a journalist collects into the article format kills the ability to create truly engaging and information-rich Web sites.
Journalists perfected the art of the article because for the last two hundred years, the article was the most reasonable format in which to distribute news. Printing the equivalent of the phone book every day for readers was not economically practical or desirable, and so the simple format of a headline and some body text became the dominant practice by sheer inertia.
But when faced with the golden opportunity to accurately organize on the Internet the information they painfully collected, journalists clung to the article format. The editing process also stripped facts that some people might have found useful, for the purpose of fitting text into a pre-existing column onto a broadsheet newspaper template. The edited article was fitted for a print product first and saved onto the Internet second, a place with nearly limitless room or constraints on relationships.
The articles were fit for human consumption, but they took little advantage of computers to sort and organize the information, which could have given greater meaning and depth to readers. Ultimately, Django was the byproduct of solving this deep and serious problem.
Django’s beginnings started in late 2002 when Rob Curley (Wikipedia) was assembling a team of Web developers and designers to create an innovative news platform at the Lawrence Journal-World newspaper in Lawrence, Kan. He hired:
Holovaty and Willison started using PHP, but switched to the Python programming language because of its cleaner syntax and efficiency. The team applied best practices to its Web applications and eventually created a Web framework to meet its journalism newsroom deadlines. The extraction of this generic, reusable code became Django. At its simplest level, Django a collection of shortcuts and helpers that make Web development faster and easier, but more importantly, it allows Web developers to respect the data they manage by elegantly separating them by characteristic and modeling the relationships between them. The New York Times picked up on the newspaper’s success and called it “the newspaper of the future.”
You can learn more about Django’s beginnings at its FAQ and from these videos:
Snakes and Rubies: Holovaty and Ruby on Rails framework creator David Heinemeier Hansson discuss the pros and cons of each of their frameworks. Because this is an introduction to Django, I recommend watching Holovaty’s presentation, which despite being 40 minutes, is some of the best 40 minutes you can invest in yourself. Also available on Google Video.
Google TechTalk on Django: Co-framework creator Jacob Kaplan-Moss discusses Django at the Google Headquarters at one of its TechTalks. Kaplan-Moss’ presentation is a little longer than Holovaty’s and covers similar ground, but also details some of Django’s more technical points, although it is slightly outdated.
Django roughly follows the model-view-controller software architectural pattern, which separates Web development into three loosely-coupled components. Django calls these components by slightly different names: the “view” is called a “template,” and the “controller” is called a “view.” Instead of MVC, the Django equivalent is MTV.
The framework separates these components to make the code more manageable: It allows Web developers to work on the back-end code to which they are best suited, and Web designers to work on the front-end code and the user interface to which they are best suited. The loose-coupling of these components creates an implicit workflow that avoids the messy PHP/HTML soup through which most Web developers and designers have labored.
Other niceties include beautiful URLs, an RSS framework, a production-ready admin for data entry, internationalization, and a Django development ecosystem of free applications. You get a lot of bang for your buck.
You might think Django is full of pixie dust and magic ponies, but it’s not perfect.
The biggest drawback of any framework—Django included—is the overhead. As much as a Web framework tries to automate the repetitive, tedious code of Web development, there will be inevitable parts of the framework you do not use. Although you will download these parts, the biggest cost is its memory footprint in the form of RAM on your server, which can run several megabytes per process. It was such an issue that popular Django host WebFaction released tips on how to keep your memory usage down.
Another drawback is the inability to easily make changes to the database after its tables have been created. Creating models is fairly easy but if you want to change the database later, you might need to roll up your sleeves and break out your SQL skills. You can change the models and run the sql command to create some of the statements, but it has difficulty in defining table relationships. dmigrations is a project trying to tackle this problem.
Lastly, Django is in active development. Although an active community is generally good, Django is constantly maturing and changing. It has backwards-incompatible changes and even future backwards-incompatible changes. It is generally recommended to download the latest stable, official version and not the latest development version, whose code might not be stable for a production-ready Web site.
Web developer Cal Henderson covers what he sees as drawbacks in his delightfully named presentation “Why I Hate Django” from DjangoCon 2008. Generally speaking, not everyone needs a tank to go to the grocery store.
Don’t take my word for it. Check out these Django Web sites, up and running on the real World Wide Internets:
If you’re starting out, you won’t make anything on the level of these examples, but the foundational knowledge you generate from building smaller, simpler Django projects is knowledge upon which more involved projects can be built. Like Python, Django generally pushes you into the direction of best practices most of the time, so little of what you learn won’t be valuable.
You can download Django from the official Web site and get started with its tutorials. The tutorials are part of the larger documentation, but I recommend reading the Django Book before the documentation. Like a lot of learning in software, the beginning of your journey will be better served by a narrative and not a glossary.
Keep in mind that Django was developed by Web developers for Web developers, especially those familiar with Python. Django assumes some knowledge in installation and configuration, and few Web sites cover such foundation. If this article finds a receptive audience, I can further write a more practical walk-through of installation of the framework and development of applications.
If you’re a Web designer, then you’ll get a lot of free best practice development perks without committing to becoming a full-fledged Web developer. If you’re a Web developer, then you’ll still get a lot of free perks and the ability to develop more in less time. Deciding which camp you fall into will make your expectations more realistic. Django won’t cook your bacon for you.
If you’re at the very beginning of your Web development path, have only basic (X)HTML/CSS knowledge, and you want to fully embrace the Web development life, I recommend reading How to Think Like a Computer Scientist and Dive Into Python, which can be read during Django development. My advice is to practice patience and persistence. In my experience, understanding Django comes in small doses with occasional waves of revelations. Web development is a journey and its skills will not come overnight.
Django is a powerful tool for people serious about making robust and information-rich Web sites, but like all tools it is a means to an end. A technology should never be self serving but rather help people make sense of the world around them.
Richard Cornish is an interaction designer at the Lawrence Journal-World in Lawrence, Kan., where the Django Web framework was created. His first love is design but a close second is the Old Navy track jacket that he wears almost every day. It’s a security thing.
Discussion
No comments for “A gentle introduction to the Django Web framework”
Post a comment