Django evolution

Before we dive into more code, we should take a moment to explain Django’s history. It’s helpful to understand why the framework was created, because a knowledge of the history will put into context why Django works the way it does. If you’ve been building Web applications for a while, you’re probably familiar with the problems in the CGI example we presented earlier. The classic Web developer’s path goes something like this:

  • Write a Web application from scratch.
  • Write another Web application from scratch.
  • Realize the application from step 1 shares much in common with the application from step 2.
  • Refactor the code so that application 1 shares code with application 2.
  • Repeat steps 2-4 several times.
  • Realize you’ve invented a framework.

This is precisely how Django itself was created! Django grew organically from real-world applications written by a Web development team in Lawrence, Kansas. It was born in the fall of 2003, when the Web programmers at the Lawrence Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build applications. The World Online team, responsible for the production and maintenance of several local news sites, thrived in a development environment dictated by journalism deadlines. For the sites — including LJWorld.com, Lawrence.com, and KUsports.com — journalists (and management) demanded that features be added and entire applications be built on an intensely fast schedule, often with only days’ or hours’ notice. Thus, Adrian and Simon developed a time-saving Web development framework out of necessity — it was the only way they could build maintainable applications under the extreme deadlines.

In summer 2005, after having developed this framework to a point where it was efficiently powering most of World Online’s sites, the World Online team, which now included Jacob Kaplan-Moss, decided to release the framework as open source software. They released it in July 2005 and named it Django, after the jazz guitarist Django Reinhardt.

Although Django is now an open source project with contributors across the planet, the original World Online developers still provide central guidance for the framework’s growth, and World Online contributes other important aspects such as employee time, marketing materials, and hosting/bandwidth for the framework’s Web site (http://www.djangoproject.com/).

This history is relevant because it helps explain two key matters. The first is Django’s “sweet spot.” Because Django was born in a news environment, it offers several features (particularly its admin interface, covered in Chapter 6) that are particularly well suited for “content” sites — sites like eBay, craigslist.org, and washingtonpost.com that offer dynamic, database-driven information. (Don’t let that turn you off, though — although Django is particularly good for developing those sorts of sites, that doesn’t preclude it from being an effective tool for building any sort of dynamic Web site. There’s a difference between being particularly effective at something and being ineffective at other things.)

The second matter to note is how Django’s origins have shaped the culture of its open source community. Because Django was extracted from real-world code, rather than being an academic exercise or commercial product, it is acutely focused on solving Web development problems that Django’s developers themselves have faced — and continue to face. As a result, Django itself is actively improved on an almost daily basis. The framework’s developers have a keen interest in making sure Django saves developers time, produces applications that are easy to maintain, and performs well under load. If nothing else, the developers are motivated by their own selfish desires to save themselves time and enjoy their jobs. (To put it bluntly, they eat their own dog food.)

Version History

Version Date Notes
0.90 16 Nov 2005
0.91 11 Jan 2006 “new-admin”
0.95 29 Jul 2006 “magic removal”
0.96 23 Mar 2007 “newforms”, testing tools
1.0 3 Sep 2008 API stability, decoupled admin, unicode
1.1 29 Jul 2009 Aggregates, transaction based tests
1.2 17 May 2010 Multiple db connections, CSRF, model validation
1.3 23 Mar 2011 Class based views, staticfiles
1.4 LTS 23 Mar 2012 Timezones, in browser testing, app templates.
1.5 26 Feb 2013 Python 3 Support, configurable user model
1.6 6 Nov 2013 Dedicated to Malcolm Tredinnick, db transaction management, connection pooling.
1.7 2 Sep 2014 Migrations, application loading and configuration.
1.8 LTS 1 Apr 2015 Native support for multiple template engines. Supported until at least April 2018
1.9 1 Dec 2015 Automatic password validation. New styling for admin interface.
1.10 1 Aug 2016 Full text search for PostgreSQL. New-style middleware.
1.11 LTS 4 Apr 2017 Last version to support Python 2.7. Supported until at least April 2020
2.0 2 Dec 2017 First Python 3-only release, Simplified URL routing syntax, Mobile friendly admin.
2.1 1 Aug 2018 Model “view” permission.
2.2 LTS Apr 2019 Supported until at least April 2022
3.0 Dec 2019
3.1 Aug 2020
3.2 LTS Apr 2021 Supported until at least April 2024

Back to Tutorial

Share this post
[social_warfare]
MVC
Getting Started

Get industry recognized certification – Contact us

keyboard_arrow_up