heyPanda

Originally posted December 30, 2007 at masonbrowne.info:

I pre-ordered my copy of the book (hereafter referred to as Pro Django, as that's what Borders had it listed as) a couple weeks ago. I've been anxiously anticipating the printed version ever since the online version went stale. After receiving a phone call from the store, I went down to take a look at it.

One large Oreo Javakula and nine chapters later, I must say I am impressed. I own quite a few Rails books, but none of them approach their framework with the same level of thoroughness and trust in the reader's intelligence.  The two authors assume a certain level of competence and prior experience with programming, which does wonders to the amount of information they can pack into the 432 page book.

While working with the folks from the Capistrano Documentation project, some comments arose as to how current the book is with Django's codebase.  While I can't attest to its completeness with regards to the project's subversion trunk, it appears as though the print edition was given a thorough scrub, making it a more accurate and up-to-date reference than the online version.

I can't recommend this book enough to anyone interested in working with the Django web framework.  If you have any experience with Python, you will find the book informative and easy to follow.  Not only does it teach one how to use the features Django gives you for 'free', but also goes to adequate lengths in informing the reader on how to extend the framework's components to fit his or her needs.

Different Methodologies

Most of the Rails books go the route of building an application tutorial-style.  While useful for the beginner, it doesn't begin to introduce the "special cases" where surface-level instruction breaks down.  While I believe in catering to the "90% case", I also believe that a work regarded as the "definitive reference" should offer some clues to the user wishing to exploit that last 10%.

The fact that Pro Django takes these extra steps is, I believe, in part due to architectures and belief systems of the frameworks themselves.  While both Django and Rails end up being tacked on as language extensions in the form of a package and gems, Django's roots are much more apparent.  When you're working with Django, you know you're working with Python.  After the magic-removal branch became the main course of development, a lot of the "black magic" that I had originally labeled as attempts to simulate a Rails-esque environment went away.  As a Django developer, you're responsible for importing any components you'll need during the course of writing your application.  In other words, it takes a rather "whitelist" approach, which has the added effect of keeping overhead low.

Rails, on the other hand, does its best to create a DSL for web development. While an admirable goal, it also involves a large amount of work be done in-framework before your code ever gets a look at it. Additionally, interacting with your application domain outside the actual Rails framework can become an issue.  In order to gain the majority of the benefits Rails provides, you must actually load up the entire Rails environment.  Not exactly efficient.

Of course, in the end it's a matter of taste.  I value the speed with which I can develop in Rails, due to its mantra of "convention over configuration".  Knowing I don't have to manually hook up my URLs to code, as petty as it sounds, is a great comfort to me.  Knowing that my models are in my current namespace is a great comfort to me.  Knowing that every Rails application is mandated to have a certain file structure is a great comfort to me.

On the flip-side, knowing that Django is "just another package" is a wonder.  Knowing that whatever I import is the only thing imported is a wonder.  Knowing exactly where to find every Django component is a wonder. Knowing that I can write an application once, and use it in multiple projects without changing any of the business logic, or even moving the application source, is downright magical to me.

I will continue to investigate both options as more resources become available to me.  I have until now resisted the urge to use Django due to its pre-1.0 status. However, with Leah's decision to use Django for Pownce, and the arrival of The One Django Book to Rule Them All, I find myself open to new ideas.