Designing a web framework: Django’s design decisions

Description:

Since its release three years ago Django’s grown by leaps and bounds; it’s now part of a highly successful new generation of web development tools.

However, it hasn’t all been smooth sailing for the Django team. As any Open Source community does, we’ve needed to make a series of tough decisions along the way. These decisions have shaped Django’s internals, public APIs, and community.

In this session I’ll look at several of these decisions and — more importantly — the ramifications of our choices, both positive and negative. Some of the decisions I’ll talk about will be:

• Pragmatism vs Methodology. Django doesn’t subscribed to any particular Methodology or paradigm. Case in point, our take on the MVC (Model-View-Controller) pattern has seriously angered some MVC proponents. Prescribed methodologies can be useful when they help get developers all on the same page, but they can also get us into unproductive “architecture astronaut” situations.
• “Magic” vs “boilerplate.” Django tries to let you be concise and avoid repetitive coding, but this often means delving into deep “magic” — metaprogramming — that can make the internals confusing.
• “Full stack” vs. “best of breed.” We’ve choices to implement much of Django from scratch, which gives us absolute control over API and design. However, an alternate strategy (taken by other Python frameworks) pieces together existing components, leaving far less code to maintain.
• “Sensible defaults” vs. “opinionated software.” Ruby on Rails managed to grab quite a bit of mindshare with its approach of “opinionated software”. Django takes a different approach: we try to be agnostic, but still select reasonable default behavior. It’s often easier to simply dictate “correct” behavior, but this turns off many users.
• “One obvious way” vs. “pluggable components.” Choice is wonderful for experts, but it intimidates new users. Finding the middle way between this Scylla and Charybdis of software design is a never-ending struggle.
• Centralized, “BDFL” development vs. decentralized, democratic development. Stealing a page from the Python community, we’ve opted for a tightly controlled meritocracy with a pair of “Benevolent Dictators for Live” (of which I’m one). This gives us a huge amount of control, but requires that we wield it carefully.
• “Long tail” vs. huge scale. Django’s currently used on some moderately large websites, but its penetration is nothing compared to something like PHP. Should Django — or any project — strive for these rarified heights, or be optimize for the common case?

Slides: