Target Audience
There’s a large body of technical information out there about content management systems and frameworks, but not much written specifically for decision-makers. Programmers will always have preferences, but it’s the product managers and supervisors of the world who often make the final decision about what platform on which to deploy a sophisticated site. That’s tricky, because web platform decisions are more-or-less final — it’s very, very hard to change out the platform once the wheels are in motion. Meanwhile, the decision will ultimately be based on highly technical factors, while managers are often not highly technical people.
This document aims to lay out what I see as being the pros and cons of two popular web publishing platforms: The PHP-based Drupal content management system (CMS) and the Python-based Django framework. It’s impossible to discuss systems like these in a non-technical way. However, I’ve tried to lay out the main points in straightforward language, with an eye toward helping supervisors make an informed choice.
This document could have covered any of the 600+ systems listed at cmsmatrix.org. We cover only Drupal and Django in this document because those systems are highest on the radar at our organization. It simply would not be possible to cover every system out there. In a sense, this document is as much about making a decision between using a framework or using a content management system as it is between specific platforms. In a sense, the discussion about Drupal and Django below can be seen as a stand-in for that larger discussion.
Disclosure: The author is a Django developer, not a Drupal developer. I’ve tried to provide as even-handed an assessment as possible, though bias may show through. I will update this document with additional information from the Drupal community as it becomes available.
Systems Make Assumptions
Every web shop has its favorite tools and languages. Settling on just a few keeps toolchains, deployment, and development workflows sane. At both the UC Berkeley Graduate School of Journalism and the Knight Digital Media Center, we’ve settled on a mix of:
- WordPress for basic sites and “modest” online publications
- Django for sites with more complex needs or non-standard data models
For example, it makes sense to build student magazines, handbooks, FAQs, and blogs with WordPress. But it’s simply not possible to build an equipment checkout system, or a course evaluation system, or a student/faculty/staff directory with WordPress — not while trying to preserve your sanity. That’s because WordPress assumes so much about the structure of your data — it thinks every piece of content has a title, a summary, an author, etc. Start to veer away from that basic data structure and you find yourself quickly needing a platform that doesn’t make assumptions about how things should be done. For those kinds of problems, we use Django.
Meanwhile, there’s a lot of Drupal momentum on the UC Berkeley campus. In fact, there’s a lot of Drupal momentum all over the world — e.g. the recent move of whitehouse.gov to Drupal. And with that momentum comes questions from supervisors.
“Why aren’t we using Drupal?”
To be clear on terms:
- WordPress is a simple content management system.
- Drupal is an advanced content management system.
- Django is a framework.
Frameworks operate at a lower level than CMSs, and provide less of a turnkey experience for basic sites. In contrast, a framework is a box of parts from which you build your dream CMS – the CMS that precisely fits your organization’s data model and workflow. But the lines aren’t always so clear. Django comes with a self-generating administrative interface that’s so good and so user-friendly that we find it works fine as the CMS for the vast majority of projects we work on. The self-generating administrative interface can be tweaked and customized, or ignored altogether. It’s an optional component – you’re free to use it, modify it, or ignore it completely and write your own CMS on top of the framework.
On the other end of the spectrum, Drupal has some framework-like aspects to it. It’s been said that “Django is a framework with CMS-like tendencies, while Drupal is a CMS with framework-like tendencies.” So before you protest that I’m comparing apples and oranges, remember that in real life, the lines are blurry, and that apples and oranges can be compared, if what you intend is to compare types of fruit.
Every assumption made by a platform can either be a time-saver or an obstacle when it comes time for your site to grow or evolve, depending on:
- The ways you want that evolution to happen
- The skill of your developers
By their nature, frameworks are more flexible than CMSs. They make NO assumptions about the shape of your content, the Ajax system you might want to use, which rich text editor to present to your content people, etc.
Here are some of the key architectural points that matter to us when selecting a publishing platform, with pros and cons for Drupal and Django. I’ve sprinkled in some comments and feedback from members of the Django developer community (relevant comments from the Drupal development community will be included as well).
Object Orientation
Python (the language on which Django is built) is extremely object-oriented, and thus so is Django. This means that data objects, querysets, variables, templates and arguments can be passed around in the codebase easily. This makes it easier to reduce or completely eliminate redundant code (Django subscribes to the DRY principle).
Drupal is generally not object-oriented. However, Drupal developer “catch” adds:
Drupal 7’s field and entity APIs are a step towards an ORM. Drupal’s database layer and many other subsystems including contributed modules like Views are object oriented to various extents.
MVC/MTV
Django uses the model-view-controller methodology (going by the name MTV in Django-land). This means that in Django, developers have almost complete separation of logic (programming), data structure, and display logic. MVC/MTV has emerged as a core aspect of modern programming practice.
Django is MVC from the ground up.
Templating System
Django is famed for its super-clean, inheritance-based templating system, which makes it almost trivially easy to nest templates within templates, use different templates for different parts of the site, and to completely eliminate any redundancy in template code. Working with Django’s templating system is often described as “a joy.”
In contrast, a common complaint about Drupal is that templates can be difficult to customize. In fact, there are entire books about working with templates in Drupal.
Said one Django developer on working with Drupal templates: “I always felt like I was shoving a square peg in a round hole.”
Drupal developer “catch”:
Drupal’s PHPTemplate theme layer gives you a lot of freedom to do processing in themes, which can be good or bad depending on situation/skillset etc. … However, even if you do have code which you need to share between themes: since at least Drupal 5, we’ve had theme inheritance (sub themes) which means if you have some central logic which would need to be re-used between multiple themes – whether that’s templates, CSS files, preprocessing etc. (either on the same site or completely different sites) then there’s zero need to copy this between them – you just have your base theme with that stuff in, then build a subtheme on top of it, subthemes can be as light as a single CSS file.
The theme/sub-theme system does give Drupal the ability to do theme inheritance. However, the basic methodology still allows for the inclusion of business logic in themes, which breaks the separation of presentation, content, and programming logic. The Django project is very strict about this, and has been very good at saying “NO” to proposals to make Django’s templating language include more options for direct programming. The Django philosophy is, “If you feel like you need to do some programming in your templates, you’re doing it wrong.” However, it is possible to create your own custom template tags and filters to extend Django’s base template language. Developers often share these custom tags and filters on sites like djangosnippets.org.
Once you head down the slippery slope of scattering code logic between internal functions and external templates (which should be kept simple enough for a designer to work on), you lose the clean separation of logic and presentation and no longer have certainty that certain kinds of code must be in certain places. My view is that Django’s insistence on keeping as much programming out of templates as possible makes people better developers, since it enforces “best practices” in programming.
Contrast all of this to WordPress theme development, where developers have to copy chunks of logic over to the new theme manually if they ever decide to change themes.
ORM
In Django, development begins by defining the data models that describe the organization, publication, or site. For example, these might be Stories, Authors, and Presses, or Equipment, Schedules, and Reservations, or Faculty, Students, Courses and Evaluations, etc. All of these have datatypes and interdependent relationships.
From that data model, database tables are auto-generated, and the system becomes internally “aware” of data relationships. To query for various sets of data, the Django developer uses something called the Object Relational Mapper, or ORM. So, rather than writing raw SQL queries, the Django developer writes “querysets” like:
1 | books = Book.objects.filter(author='Hacker') |
In a simple example like that, there’s no real time savings over writing the equivalent SQL. But when queries become complex, SQL gets difficult and error-prone, while querysets remain straightforward and readable. When developers can save time and reduce errors, organizations save money.
Drupal does not have an ORM.
Preston Holmes: For relatively “flat” data, Drupal’s CCK is usable by non devs to create custom content types, and the Views module allow for simple generic_view style pages. When it comes to more complex objects, Django’s ORM is far superior.
Starting with the data modeling process is a key point. Django makes no assumptions about the needs of your organization or the shape of your data, which means the end product should fit your organization like a glove. Django projects are built up to fit the organization, whereas Drupal developers often talk about having to remove or work around the things they don’t need. Many developers who have spent time in both systems say the Django methodology is easier and faster.
Performance
I don’t have numbers to support this, and it would be quite hard to test without building the equivalent test site in both Django and Drupal, but the conventional understanding is that Drupal has a lot of functional “layers” through which all page requests must pass. This results in a high query count and relatively sluggish performance. Granted, this limitation is largely moot given that all high-traffic database-backed sites rely on caching to keep performance up, but it goes without saying that a system that’s as light on its feet as possible is desirable. A Drupal site is probably going to require caching to be enabled with a lower amount of traffic than an equivalent Django site.
Bruno Desthuilliers: I recently had to work on a not-so-complex (functionaly-wise) Drupal project, and the response times on my local station – all caches disabled of course – turned the development process into a sluggish nightmare. Never had this kind of problems with Django, even for far more complex apps.
Learning Curve
Drupal is sometimes criticized for having a steep learning curve. But as someone who went through the Django learning curve last year, I won’t claim that Django’s is much better. This really depends on the pre-existing skills of the developer. In my case, my move from PHP-based systems to Django was my first exposure to object-oriented programming, my first exposure to Python, and my first exposure to MVC/MTV thinking. Not to mention learning the framework itself. I think we hear this complaint more about Drupal than about Django because there are more newbie developers in the Drupal world, while Django for the most part attracts more experienced developers.
In fact, I’d go as far as to say that Drupal has an advantage here for basic sites, where little to no customization is required. However, as soon as customization is required, you’re going to need an experienced developer on hand with either system. For systems flexible enough to let you build whatever you can imagine, there are no free lunches.
Rapid Development
Be careful of the term “rapid application development.” Without good skills on-staff, there’s nothing rapid about working with either system. But with those skills, rapid application development is no myth. I can’t speak for Drupal here, but a few recent rapid-development case studies are interesting:
- michaelmoore.com, recently rebuilt in Django in five weeks.
- texastribune.org, built from the ground up in just four weeks with Django.
- Mahalo Answers, built in 35 days with Django.
- baynewsnetwork.org, an RSS mashup and aggregation site with a complex back-end that lets member sites have multiple members and single members contribute to multiple sites — built in 3-4 days with Django.
- django-treedata: Winner of the recent DataSF public dataset Hack-a-Thon, built in 8 hours with Django (and another 8 hours cleaning the public data set).
Both systems have fairly steep learning curves. But once developer skills are up to speed, it’s amazing how easy it is to get the platform to do most of the heavy lifting for you.
Note also that both systems are sometimes distributed as part of larger bundled packages (“distributions”) which extend their capabilities. For example Drupal is part of CivicSpace, which is aimed at building civic/community sites, while the Django world has the option of deploying the Pinax project, which bundles together dozens of re-usable apps to greatly reduce time spent integrating parts into a cohesive whole.
Flexibility
This is very hard to quantify. Both Django and Drupal let developers work with data models any way they please. The question is, what happens when you need to change those models, or add new ones? How easy is it to create new views or slices of the same data? What happens to the logic that ties your data together when the platform is upgraded?
Both systems value flexibility highly, though both go about things in very different ways. What I do know is that when visiting journalists tell us about their Drupal experiences, a complaint we hear a lot is “Everything was fine until we tried to change xyz — then everything fell apart and we’re still trying to recover.” Again, much of this comes down to whether you have good developers on staff more than it does to the platform. Still, the fact that Django is so intensely object-oriented gives it a leg up when it comes to moving things around.
That’s not to say that a complex Django site is infinitely flexible. Even well-designed data models have interdependencies, and a change made in one place can have real ramifications for other parts of the system, which may or may not be easy to recover from. Managers should not be given the impression that just because you’re using a “flexible system” and that “anything is possible” that the webmasters can turn the whole thing inside out on short notice. Things don’t work that way.
Drupal has developed a bit of a reputation for being difficult to upgrade, since so much changes internally between major releases. No platform is immune to that problem, but I’ve rarely seen Django apps affected by upgrades. And when they are, the fix is generally minor.
Bruno Desthuilliers: From my experience, it can take more time doing “simple customizations” with Drupal than you’d need to implement the same features from scratch in Python/Django.
A recent Django success story was the 4-week (!) launch of texastribune.org. Asked why the Tribune chose Django over other platforms, developer Chase Davis replied:
We went with Django for two reasons:
1. We decided early on that the Texas Tribune needed room to evolve. It’s a startup, and nobody has any idea what it’s going to look like in six months. That being the case, our goal was to build them a sandbox — something that could evolve as their organization evolved. We settled on Django because we thought a framework-based approach would give them maximum flexibility, while keeping the benefits of stability and rapid development. If they need a new feature — no matter what it is — we can prototype it, built it and integrate it quickly. We’re not limited by pre-existing modules or dependency issues you find with off-the-shelf systems.
2. The Tribune’s plan going forward is to integrate tremendous amounts of data into their coverage. Their lawmaker directory is one example of that, but they have much more ambitious plans for campaign finance records, financial disclosures, lobbying reports, etc. Rather than segregating that data by walling it off in its own ghetto, we thought Django offered the best chance to integrate it with other content on the site. Drupal isn’t great for building data apps; Django is. If we used Drupal for the CMS and tucked Django data apps within that, tightly integrating the two could quickly become a headache. But with everything in Django, our data apps and CMS play together seamlessly. You’ll see a lot more examples of that in the months ahead.
Community Resources
This is one area where Drupal really has the advantage. Don’t get me wrong – Django has a great community of developers who are more than ready to help each other out, respond to questions on IRC or mailing lists, and a really active blogosphere. But while there are many sites listing re-usable Django applications ready to become part of any project, Django simply does not have the immense collection of downloadable modules present in Drupal-land.
That doesn’t mean we haven’t been able to find ready-made solutions for most situations where we’ve needed them, but there are areas where we’ve really felt the pinch. Case in point: I recently had to implement a survey system on a Django site. That’s an important and not-uncommon piece of software, and you’d hope to find yourself choosing between lots of options. Unfortunately, I found exactly one re-usable survey app for Django, and it was somewhat buggy.
On the plus side, the developers of django-survey responded literally overnight to the half-dozen bug reports I filed on it the first day, but it would be nice if there were several mature survey apps to choose from. That’s the kind of thing that happens when community momentum really takes off. Django’s momentum is increasing by the day, it’s heading in that direction, but Drupal definitely wins in this arena.
Still, there are community-provided apps and resources I utilize on every Django project I build. And nothing in this department has ever been a show-stopper for me. Keep in mind that, in many cases, just building the re-usable app you need when an existing one isn’t available may be easier than expected.
Popularity / Installed Base
By some measures, particularly for decision makers, popularity counts. Is the platform popular enough that I know it’s not going to be abandoned? Can I readily find qualified developers? Is the platform proven in the marketplace? Drupal developer Zack Rosen has this to say:
- Drupal by all measures of an open-source project is a magnitude larger than Django. Core contributors, community members, deployed sites, any way you want to compare numbers Drupal is a much more established project.
- Drupal is more proven in the market place. It runs magnitudes more websites (500,000+), and many of note. Whitehouse.gov yes, but Viacom, Warner Brothers, Yahoo, Wikipedia and others all run highly trafficked Drupal sites and have made strategic business decisions to invest in the platform.
- Drupal has far better commercial support in the marketplace than Django. There are many more (and more qualified) Drupal development shops and specialized service providers in the marketplace.
Excellent points, which I would qualify by noting that Django’s popularity is rising, along with the number of qualified Django developers on the scene, and the number of high-profile Django sites appearing (just tonight, the Mozilla foundation announced that it would be moving its addons site from CakePHP to Django.)
Language
After years of working with both custom and open source PHP code and applications, we felt that we had had our fill of PHP, which has a tendency to sprawl. Granted, sprawl is not much of an issue when working with pre-fab solutions like WordPress or Drupal, but Python’s syntax is clean and uncluttered, which speeds development time and encourages developers to think in more object-oriented ways. Simply put, clean code is easier to write and easier to maintain.
Mike Ramirez: Finally, there is the maturity of the language. PHP is still adding in features other, similar languages already have had. For example namespaces are just barely a year old in php, initial release in the dev versions, less than 6 months for the actual first appearance in a stable release. To quote wikipedia[3] on missing features from PHP: “PHP currently does not have native support for Unicode or multibyte strings; Unicode support will be included in PHP 6 and will allow strings as well as class, method and function names to contain non-ASCII characters.” Seriously, in todays global world and well, for the past what 10-15 years, hasn’t this been mandatory? I do not understand why web developers who use php, still do. I don’t understand why companies and schools support it.
People often work in PHP because it’s the default, and easy to gravitate towards. But that doesn’t mean life couldn’t be a lot better with a cleaner language to work with.
Security
Security is a multi-headed hydra, and affects all web applications, large or small. SQL injection, form sanitization, cross-site scripting, and many other attack vectors require web application developers to stay up to speed on current security trends and to examine old code for new vulnerabilities. It’s a constant chore.
One benefit of using a mature framework or CMS is that many of the most common security issues are handled by the system itself. This doesn’t mean we can afford to get lazy about it, but it’s good to know that hundreds of people smarter than oneself have pored over the code to identify and mitigate security issues.
That much is true of both systems. However, it’s also true that Drupal has a history of security issues, whereas similar issues in Django are extremely rare. This is in part due to the fact that Django has a lower public profile, and in part because Django makes fewer assumptions about where things live and how they’re configured. In other words, less about a site’s setup is known to a would-be attacker since sites built from a clean slate by various developers share less in common with one another.
There are other factors that may contribute to Django’s excellent security track record, such as its URL mapping system, which simply prevents access to URL patterns that haven’t been predetermined by the developer, and its exceptional form generation and handling system.
Still, I don’t want to emphasize the security point too much – all systems can be vulnerable if you do dumb things with them, and vice versa.
Drupal developer “catch” adds:
The Drupal security team regularly releases SAs for security issues which in some cases are theoretical, in many cases have never been exploited (simply reported after code review), and very often require either authenticated or some level of administrative access to a site. Additionally, the 3-4,000 contributed modules are hosted centrally on Drupal.org, not distributed around the web, and have the same rules for security announcements as Drupal core, handled by the same process. The number of security announcements for Drupal core itself is relatively low given code base and deployments.
Deployment
On the other hand, PHP-based systems have a slight leg up in deployment. Since virtually every web host offers PHP hosting. In contrast, setting up a Django system on a server will take some level of fiddling that may not be familiar to the typical web developer. Fortunately, a growing number of web hosts specialize in Django hosting, which makes this problem go away in many use cases.
Preston Holmes: “Where Drupal has its single biggest advantage, is that a technical user, a sysadmin etc, can get Drupal up and running. Someone doesn’t have to know PHP AT ALL to get drupal going. This is because Drupal has a decent admin-UI – where modules are pretty much drop in, activate and configure. Setting up even a basic Django site REQUIRES someone who has some programming skills, even if thats just a matter of setting up the settings.py file.
But the Python/Django deployment hurdle is not huge, and is a one-time problem to solve. Once Apache has been configured to work with Django, you don’t need to think about it again. This hurdle affects hobbyists, who tend to look for a simple button in their web hosting control panel, far more than serious sites for whom server configuration is just part of doing business on the web.
Developer Feedback
I asked members of the django-users mailing list who had done development work with both Django and Drupal to provide comarison-oriented feedback for this article. Here are a few of their comments:
Preston Holmes: What happens is that non-developer/technical decision makers will evaluate Drupal and think that all their needs will be met out of the box. When they find out they aren’t, they need to hire developers, and then those developers have to massage existing modules to customize and tweak. Then at some point they have this monster of hodgepodge code. But its that entry point that is the key to Drupal’s popularity. … I don’t think people appreciate how much Drupal development is spawned by this existence of a usable entry point for Drupal by non- developers. (and that it has 1-click installs on hosts, and in general uses the far more common infrastructure of PHP-MySQL).
Javier Guerra: “Many people feel they have to code less to write their own Django-based CMS than to customize an existing one. If that’s your case, you’re a lot less likely to break something when going with Django.”
Clifford Ilkay: “On balance, I’d say Django is the more flexible and powerful of the two but Drupal gives the *illusion* of productivity quicker. With Django, I build up from a base, whereas with Drupal, I seem to spend an inordinate amount of time trying to figure out how to make it *not* do something I want done differently. Django is lean and simple by comparison to Drupal, which is neither lean nor simple. Both have very active and helpful communities.”
Anon: “If I had the choice, I’d pick Django simply because I prefer Python to PHP and find Django to be more productive. Prototyping and debugging PHP is very crude by comparison to Python. Much of Drupal’s convoluted architecture and reliance on naming convention “magic” to provide quasi-inheritance is due to the limitations of PHP. I often say, half-seriously, that Drupal is good despite PHP, not because of it.”
Alexandru Nedelcu: Development in Django is a lot easier, because the modules are more generic and the development process is more predictable because of its simpler architecture.
Mike Ramirez: Django has made making web apps almost trivial and the most time I spend now, is on the UI (both Dojo and JQuery make this almost trivial also), rather than the back-end.
Preston Holmes: Both have the problem of often complex dependencies. The biggest problem with Drupal is its relatively fast moving core – so that modules for the “current version” are hard to find, or often abandoned. Also Drupal modules almost always seem to do 80% of what you need.
Milan Andric: Drupal might get you quickly to Point A, but the problem is in customization, pushing a site to do *exactly* what you want (nothing more or less) … My main problem with Drupal has been all the time spent removing stuff. The best tool for web developers right now is a framework, not a CMS. Regardless of the language it’s written in.
catch: Drupal 6’s API was officially frozen 2.5 years ago and Drupal 7 has been in rapid development for more than 18 months, with probably 1-3,000 patches committed by this point.
Preston Holmes: (On the ease of getting the system to do highly custom tasks): Django just wins this so hands down. Here is part of the reason why. Drupals assumptions translate into your code having to jump through a lot of hoops – where as in Django, you make the assumptions and you make the hoops.
Conclusion
Drupal represents a middle ground between framework and CMS that we’ve chosen not to take. Drupal is far more capable than a CMS like WordPress, but also much less flexible than a pure framework. But more importantly, the facts that Drupal isn’t object-oriented, isn’t MVC/MTV, doesn’t have an ORM, and is generally less flexible than a pure framework, not to mention our preference for working in Python over PHP, all contribute to our decision not to use it.
In the end, a good developer can do good work with just about any system, while a bad developer can make mincemeat of even the best system. It’s not all about the platform. But modern tools and best practices in platform design go a long way toward ending up with a cleaner, faster, better-designed architecture that precisely matches the needs of your organizations, with no assumptions or historical baggage to work around.
Note: Public comments below may be incorporated into the document above. Thanks for your feedback.
Update: This post sparked an interesting thread on the WordPress Hackers mailing list.
Hi,
interesting article.
I’ve been eating bread and PHP for 7 years now and I deeply tested drupal two times in the same period of time.
The last time I evaluated drupal I decided to give up and made the switch to python and (geo)django.
I cannot say that the move was really smooth (I found python far more complex than PHP) and my productivity is still ~ 50% than with PHP but it’s quickly increasing and I’m very happy of my decision.
Django is a great product, and geodjango is a complete solution for geospatial enabled complex websites.
Maybe check out django-cms.org. With this you get a CMS on top of a framework.
Hi Scott,
For a future revision of the article, it might be worth asking a Drupal user community about their experiences with Django. I think with your current survey, you’re going to see a disproportionate number of users who’ve abandoned Drupal, but not the reverse. Personally, I’ve tended toward Drupal more than Django solely because I’m more comfortable with PHP-on-Apache than Python; I like the general style of sticking folders files into directories and having things “just work”, while mod_python has always seemed to require a lot jiggery-pokery. I don’t know what the state of the art is here, though.
I can tell you that when you stare into the Wordpress code base abyss, it stares back at you.
Hi Michael – Yes, I’d very much like to get feedback from a Drupal person who also has Django experience. So far I haven’t turned up anyone, but the invitation is open. Actually, it kind of sounds like you might be that person :)
I know what you mean by “drop things in folders and they just work” way of working with PHP. Django abstracts that kind of thing away, which can be disorienting at first. Having to understand the Python path stuff can be a hurdle for new users. I hardly think about it anymore.
@Michal
Apache with mod_wsgi is recommended for serving Django over mod_python. It is pretty easy to configure but not as simple as just dropping php files onto your server. On the other hand if you use a hosting company like Webfaction then it *is* just as simple – create your app through their UI and then upload the files. They handle configuring and administering the server.
[...] Birdhouse offers another example of Django versus Drupal: Every web shop has its favorite tools and languages. Settling on just a few keeps toolchains, deployment, and development workflows sane. At both the UC Berkeley Graduate School of Journalism and the Knight Digital Media Center, we’ve settled on a mix of: [...]
I understand the basis of your comparison, Django versus Drupal. For a lot of people, Drupal is the best known and most sophisticated piece of software written in PHP. The PHP frameworks, such as Symfony, are less well known, though they offer a closer comparison to Django. I tried to summarize my thoughts about this on the Symfony Nerds site:
http://symfonynerds.com/blog/?p=301
Good evaluation. While I don’t know Drupal several acquaintances are big users.. I believe from all I see that the Django framework is becoming the mainstream solution for a wide variety of reasons. Flexibility, community, and scalability, including Google app-engine are amazing. I believe that we will see Django making increasing inroads to the enterprise space, I’m trying to get it into the banking space.
[...] more here: Drupal, [WordPress] or Django? A Guide for Decision Makers Comments0 Leave a Reply Click here to cancel [...]
Comparing a CMS to a framework makes no sense, no matter how hard you try. What you guys really did was answering the question: “how the internals of Drupal compare to Django?”. And of course it’s going to suck, because one is a complete application with it’s own assumptions, while the other is an amorphic collection of reusable parts.
Would make a bit more sense if you compared Drupal to Zope, at least.
You might want to rewrite this; let’s be charitable to PHP:
On the other hand, PHP base systems typically enjoy a huge leg up in deployment, since virtually every shared web host offers a ready to go environment that makes starting with PHP as easy as including a pair of tags.
Setting up a non PHP framework like Django on a server is roughly the same work effort as setting up PHP properly, if you are managing your own box. If one is subject to the tender mercies of a shared hosting provider, you may be provided with a suitable environment for Python/Perl/Ruby, or you may need to help them help you with information and a tutorial, or you may have to go shopping for a provider that has moved into the 21st century. Fortunately here in 2010 there are plenty of good providers who understand that the web is much more than mod_php running on Apache.
What is important to remember is that nothing in the PHP language itself that sets it apart when it comes to deployment.
Henrique – I respectfully disagree, for the reasons already given. 1) Both systems are part CMS, part framework, so it’s impossible to draw distinct lines in the sand; 2) Regardless how you want to label them, both are simply systems used to build sophisticated web sites, and can be evaluated in terms of site building speed, flexibility, security, etc.
If you want to make it more fair in this context, I could have compared django-cms.org to Drupal so it’s head-head CMSs. But the results of the comparison would have been exactly the same.
Michael Watkins – I don’t think I implied that PHP the language has anything to do with PHP systems being easier to deploy, only that ubiquity of PHP hosting is really important.
[...] post: Drupal or Django? A Guide for Decision Makers — scot hacker's … By admin | category: Drupal, Object, cms | tags: bush, cms, cvs, days, document, lay-out, [...]
shacker: I didn’t mean imply that at all, but as PHP the language and PHP’s more or less default deployment approach are two concepts often conflated, I wanted to suggest you might draw attention to this in your comparison.
As I suggested earlier, setting up PHP from scratch (for someone who is taking charge of their server environment themselves) is about the same level of work effort to do properly as is learning about the various deployment options for Python or Ruby and implementing same. When you look at PHP in that light–if you strip away the default deployment advantage and merely look at distinctive language features–you’ve ensured the evaluation arena is level.
I’ve got experience with both, and yeah, it’s apples to oranges. But, whether Drupal considers itself just a CMS or a Framework, the reality is people are using it to build sites that go beyond Drupal core and they are using it ways that are more suitable to thinking about it as a Framework, so it seems fair to evaluate it in those terms.
I tried leaving a longer comment here, but your site thinks it’s spam (maybe the length?). So I put my thoughts on the issue on the Django users list, but even just including a link to it seems to get this post marked as spam. Oh well, maybe you could edit this and add the link if you think it’s worth it.
Michael, surely the fact of widespread PHP deployment is a historical circumstance that decision makers will want to throw into the mix of factors they consider when deciding on a technology? Think about the equivalent desktop comparison – can you imagine a software company trying to decide between Objective C and C#, but not taking into consideration the fact that Microsoft Window has around 90% market share on the desktop?
So the fact that Drupal has a volunteer security team, which routinely reviews reported problems and issues public patches and security alerts, is supposed to imply that Drupal is somehow less secure?
I suspect it’s true that the Django mailing list reports fewer security issues than Drupal’s. Because Django is a framework. It does fairly little out of the box. There is nothing more secure than the feature that exists only in one’s imagination. Drupal is an application. Stop comparing apples to oranges.
If you want a Django-based CMS, you have to write one, or download one written by someone else. The proper question is: Is this Django-based CMS code being routinely reviewed by third parties for security problems? If not, that code is getting a lot less review than Drupal core. Is it being run by as many websites as are running Drupal core? If not, the code is getting a lot less exercise.
There is no pride in writing an application that has no officially-reported security holes. That’s the default state of an application. Any of us can write one whenever we like. And the lack of public security alerts covering the code I wrote yesterday implies almost nothing about its security.
[Disclaimer: I'm not a member of the Drupal security team, but I work with people who are.]
Sorry to hear the spam system is swallowing some comments. Took a close look and can’t figure out what’s doing that – everything looks tight. I’ve just pushed some comments through manually.
No, I don’t imply anything of the sort. The track record is the track record and numbers are numbers.
Exactly. You’re re-stating the point I made in the article.
What in the world is the problem with comparing apples and oranges? They’re both fruits. All sorts of meaningful comparisons between them are valid. When you go searching for a flat-screen TV you get to choose between LCD and Plasma. Engineers who work on those TVs see them as so different that they can’t be compared. To everyone else, the comparison is completely meaningful and useful. Django and Drupal are platforms for building web sites. Comparison is valid and useful.
I’ve been doing Django dev for a while now and Drupal as well. In fact, at my workplace (60-person web design/ development shop) I’m leading a similar charge to move us away from Drupal development towards Django.
I took a look at your post and thought I’d add a few things:
1. It’s not exactly correct to say Drupal isn’t Object Oriented. Like Django, some of Drupal is written in a typical procedural style, some OOP. It’s more accurate to say Drupal is less Object Oriented. More here: http://drupal.org/node/547518 In any case I’m not sure it’s a huge selling point.
2. Same for MVC: Drupal does it…kinda. More here. I’d say Django maintains a separation of concerns much better, though, and I’d say this is a big selling point, unlike OOP
3. +10 on templates: Drupal templates are very frustrating. A single page is usually generated by an elaborate nesting of templates. Let’s say you have a page that lists a bunch of nodes. You have a template for the page, for the list, for node itself and maybe (with CCK) individual node fields. This is a lot to keep track of and why there are whole books written about Drupal templating. What’s more, you don’t have enough control over markup. A lot of devs where I work feel very frustrated when the lean, clean, semantic html mockups they produce get completely torn up by the way Drupal works. Django almost never forces any markup constraints on you. This allows front end dev to proceed more or less parallel with back-end dev in Django, which buys you a lot of time if you have teams that work that way. In Drupal, the templating phase is intimately tied into the back end development phase, partly because of the less-than-stellar separation of concerns mentioned in #2 above. That’s a slower way to work.
4. Drupal doesn’t have an ORM, really. With you can get a mapping of DB fields to a php object, so that say, the “title” DB column maps to an object : $node->title, but that’s not really an ORM in any sense that I think of it.
5. Security. Django makes a lot of design decisions that make it hard to write insecure code. Not impossible, but hard. Some attack vectors, like SQL injection (and other input sanitization exploits) are pretty much eliminated by Python’s DB API and Django’s ORM and Form validation tools. This is not to say you couldn’t create an exploit in a Django app, but that you’d have to be trying to on purpose. They also give you tools to prevent CSRF which were optional, but in newer releases are being promoted to “required” in contrib.admin at least (http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ ) One of PHPs biggest failings re: security , IMHO, is they made it too easy to do the wrong thing for far too long. This is improving, but I think you still see this lax approach reflected in the large number of Drupal exploits that have appeared and in the way many people don’t seem to take security as seriously in the PHP universe.
6. Deployment. I tend to think of Deployment as more than just installing an app and for that reason, I think Drupal’s deployment is far inferior to Django’s. It’s relatively easy to set up a Lamp stack and install Drupal on it. Django requires you to install Python, Apache, your RDBMs, python drivers to connect to it, PIL (probably) and mod_wsgi (Hopefully that’s what you’re using). These things represent the baseline for installing an app, IMHO, and for people without a *nix background, setting them up is harder than in Drupal (although with debian and dpgk, it’s not that bad). But to me, deployment means more than installing a LAMP stack. Deployment means packaging. PHP doesn’t really have good package management tools. Python does. Deployment means being able to run a test suite on your install and know immediately if anything has broken: Django let’s you write tests for your app, Drupal does not. Deployment means being able to maintain dev, staging and production environments in sync. In Drupal this is very hard: one of my biggest complaints is that Drupal is that it mixes application configuration and data in the DB so that they are completely inextricable. This is a huge problem if, for example, you want to migrate some new views from your staging environment to your production environment. Deployment also means upgrading: In Drupal you’ve got the upgrade treadmill and it sucks. The more modules you have the more it sucks. Upgrades not infrequently break things, and since you have no unit tests or functional tests, there’s no way to know if something broke without clicking around and hoping you catch the problem. Django + Python give you:
+ package management (distutils, virtual_env, zc.buildout)
+ unit and functional tests
+ fabric to help deploy in multiple environments across the cluster
+ south to help you migrate schemas + a complete separation of data from everything else
My argument against Drupal boils down to 2 things: 1. It’s doesn’t know if it want to be a CMS or a framework, and the confusion shows. It’s an OK CMS if your problem set matches it’s capabilities. It’s not a good framework for the reasons mentioned above and more which many commenters here have caught. 2. Drupal makes deployment of a real, professional site (where less than 99.99% uptime is not an option) very difficult and there doesn’t seem to be anyone doing much about it. This is a start http://groups.drupal.org/aegir-hosting-system …but it’s not enough.
Anyway, from someone who has been there, I feel your pain. We’ve done a few parallel development projects @ my workplace to show Drupal vs. Django and the results have been encouraging. For the kind of site we often do, an average Drupal build means moderate to heavy template customization, CCK and custom content types, 20 or so 3rd party modules modules and 1 or 2 custom modules we write. If this is the kind of site you’re doing, Django is very likely a better fit.
While this is a well elaborated comparison of the two, I need to ask one question.
Why would non-technical management need to have a say in this matter? If you can have management that is “non-technical”, then it’s very likely you have a bunch of technical people. You should take the brightest guys from the technical bunch, decide on some meetings and discuss your requirements. This way you actually let the people who actually should understand the issues better use their skills, and you’d quite likely reach a better solution.
I’m a full-time Drupal developer with zero Django experience (though I’ve been meaning to rebuild my blog using Django soon to learn more about it).
A couple of comments:
1. Drupal’s security team reviews both Drupal and contributed modules hosted on drupal.org. This results in quite a few discovered security issues per year. I don’t see how this is a Bad Thing. As someone else pointed out Django does a lot less out of the box, so it’s bound to have fewer security flaws.
2. A typical Drupal project (company site, newspaper, small community) involves very little coding, mostly some overrides to get things looking the way they’re supposed to. This means 99% of the code is maintained by someone else and has been tested on dozens, hundreds or thousands of other sites. It also means these modules are audited by the security team.
3. Drupal makes more assumptions about your site than a regular lower-level framework like Rails or Django, but less so than Wordpress. This means you will be less flexible. If you need to build something very custom and unique, you should probably use a lower-level framework. If, however, you’re not, chances are that you will be
a) wasting time re-inventing the wheel,
b) maintaing a lot of custom code (how easy is it for someone else to step in and take over?)
c) shipping a buggier product
d) introducing security flaws
It’s an interesting overview, but it would have benefited from being clearer about what use-cases we’re talking about.
I’m currently using Drupal for a low-budget project at a college department because all the available modules can give them 90% of what they want in no time. E.g. the Bibliography module would take weeks to develop from scratch in Django, but only takes half an hour to download and configure in Drupal. I’ve deployed multiple Wordpress installations in situations where people need something cheap, simple and CMS-like, and still love how user-friendly it is. But for any project that needs to be flexible and where you need full control over how everything works and looks, Django wins hands down.
The same goes for deployment. For a single developer, Drupal is easier to deploy, but when you’re working in a team with version control and want test/staging/live servers, Drupal is frustrating as hell, as James Stevenson mentions. (Although, with the Features and Context modules from DevelopmentSeed, things are starting to get on track.)
You’re too friendly for Django when it comes to reusable apps, though. Django has some great ones spread across the web, but even Pinax really can’t compare to all the contributed modules for Drupal. But, again, this isn’t necessarily a problem as one of the reasons you’d pick Django over Drupal is to be in control of your code.
And you’re too harsh on Django when it comes to the learning curve.
I led a team doing a Drupal-powered site a while ago, and we switched to Django halfway through the project. The team members were unfamiliar with both. Getting the project members familiar with Drupal amounted to me being some sort of a living version of http://api.drupal.org/, being asked every five minutes “hey, what hook do I need to change this and do that?” or “which of these ten contributed modules is the standard solution for this kind of problem?” When we switched to Django, reading the four-page getting-started tutorial was enough to get people hacking away.
In Django you build things, which is easy. In Drupal you modify how the existing code works, so you need a good working knowledge of what can be modified how (hooks, theme layer overrides, existing modules that do the work for you, …) and that requires a lot of experience.
The learning curve follows from the basic architecture of these systems, so I guess you can’t blame Drupal for being the loser on this front. But the sub-par documentation sure doesn’t help.
Another point that I think is worth mentioning is that Django can feel empowering after working with Drupal. Yes, you have to code more yourself, but at least it doesn’t feel like fighting the system. And you’re actually coding most of the time, instead of going through the drudgery of configuring a boatload of modules. And a happy coder is a more productive coder, a lesson the Ruby on Rails community has taught us.
Also in the realm of subjective experience, Django really pushes you to think about the structure of your data and how everything relates to everything else, whereas with CCK in Drupal there’s a temptation to be more cavalier about your data models. I guess this is because CCK defines both your data structure and how your input/edit forms will look. If you’re not careful you start thinking in terms of how you want your input forms to look, rather than about how your data should be structured, which can cause problems in the long term.
Anyhow, I may not entirely agree with your assessment of Drupal and Django, but I think your basic conclusion is sound: if you can get away with it, use WordPress and if you need something special, use Django.
where i work, we basically took the same decision as you did: don’t go with a full-fledged cms, but with the wordpress (WPMU in our case) + web framework combo. and so far, i’m really happy with this decision: it helps keeping simple websites in a simple environment, and once they outgrow this, you switch to the framework (turbogears in our case), with a pretty clear picture of what functionality you need to build.
while in theory a cms would give you a continuum for gradual enhancements of a site, i really came to like our two-basic-options approach, in particular because with wordpress it is so much easier to get more people involved into the site management, freeing time of the programmers up for working on the complex sites.
I heard about Python being faster than PHP. But I currently use Drupal for “middle-class” websites. Reading this article, I can imagine a solid framework offers greater flexibility for corporate solutions. But you need highly skilled and spexialized programmers. With Drupal, the bar comes down. Average devs can easily pick up Drupal skills and build corporate websites.
It is indeed an important decision point: cms or framework? Answer -as always- depends on desired results. Choose Drupal for tons of community extensions and 3rd party integrations, but accept some compromise in flexibility or power. Choose a framework for the perfect corporate app without any compromise, but pay for highly skilled devs.
Henrik -
It’s not a bad thing! I didn’t imply that it was.
That’s exactly the point I made in the original article, above.
Lawrence said:
Once upon a time ubiquity was a powerful argument for PHP five, ten years ago, but today is less of an advantage because there are ample economical options for hosting a Ruby or Python (or …) powered site, and the community around these other languages continues to grow, in part made possible by the new hosting opportunities that exist today but didn’t five or ten years ago. Thus it makes sense to look past the defacto PHP deployment model and consider other options.
For that reason it makes sense, for a project which is starting from scratch having no particular other legacy bindings to be concerned about, to take a hard look at the available technologies which make web development fun, fast and safe(r).
Note that when I talk about deployment I’m only referring to the defacto default mod_php on Apache — there are obviously a great many other considerations which make development and deployment easier or hardware – James above gives a great overview of these.
Disclaimer: I am a Drupal developer, much more familiar with Drupal than Django, but I have a lot of respect to Django. Actually Django is my most favorite Web development framework (with the caveat that I don’t consider Drupal a framework).
The article is well-written and you can definitely see that the author is trying to be fair, but it’s very obvious that it’s written by a hard-core Django developer who has only passing understanding of Drupal and quotes other developers who also seem to be experienced Django developers and only happened to have taken a look at Drupal, in passing, to re-assure themselves how much they truly like Django :)
The problem in all these is that when given relatively equal two technologies as tools, you will always like the one you are familiar with. Simply because you are much more comfortable with what you already know and hence much more productive, too.
I am not going to get involved into Drupal vs Django discussion, since much like I don’t think some of the Django developers are qualified to discuss Drupal, I am sure I am not qualified to talk about Django. However, I would like to point out that it’s not right to declare that “Drupal is not object-oriented” or just because some other framework follows “pure MVC” pattern, Drupal is somehow inferior.
Drupal (especially starting from version 7), while technically still not “purely” object-oriented, has embraced many very important principles of object-oriented design at much higher and important levels than some other frameworks that pride themselevs as “purely” object-oriented. Object-orientation is not a religion, it’s a design pattern and you can use it in more than just one way.
Similarly, for the separation of UI from backend, Drupal has very advanced theming engine that allows some truly amazing implementations that supposedly, “purely” MVC-oriented frameworks like, say, Struts can’t even dream of. So, again – gray area.
Design patterns do not translate exactly the same way across completely different languages. So “translating” Struts into PHP world would be plain wrong. It is to Drupal’s benefit that Drupal does not try any such thing.
Thank you
We have live Drupal-based site that required a lot of custom module development and various tweaks and tricks to AJAXify it. It was a bad decision to use Drupal, framework would be much better. Drupal constantly prevents us from doing things the right (and easy way). It was relatively easy to get it up and running initially though.
I rewrote almost the whole thing in Django in about 3 weeks total, learning Django in the process. It was a joy to program in Django. I had some Python background from about 5 years ago. And, of course, I already knew the whole business domain part. But… in that timeframe I managed to try different approaches, wrote a couple of Django apps that can be used separately, and came up with interesting ideas on JavaScript usage on site (90% of JS was a rewrite, by the way).
There are several things in Drupal that make unacceptable for use in a framework role:
- You cannot alter core tables and hope that you will be able to keep updating Drupal seamlessly closing security holes
- Keeping track of all hooks you have to implement and knowing what hooks are invoked is a nightmare
- Quite often you have to do something and then immediately undo some of what core Drupal did as a result
- Templating system is convoluted – there are too many places you can plug in a template because of “by convention” template naming scheme. It is flexible, yes. But very hard to debug and keep in order. And don’t ask me to create a new theme…
On the positive side, if you need some general functionality, Drupal has it. But so does Django.
The only issue I currently have with Django is that it’s not easy to deploy (initially) on a shared host.
[...] Drupal or Django? A Guide for Decision Makers — scot hacker’s foobar blog (tags: tools wordpress drupal django python framework journalism web) [...]
I have been running two Python based Zope websites and for a couple of years have been considering what to do with them as I am forced to move on with the one that isn’t working as well as http://www.fbyc.net. I am the Manager that Scott Hacker refers to, as I don’t plan to learn how to program. I did my research on Drupal and Django – each were recommended by one person or another over the past two years.
I decided to go Django, found a programmer who could help me, we did a test of the functionality which worked out fine, and now we are almost finished with the site. About 150 hours of his time, but Django has done everything I wanted it to do, and once the data models were set up, changing it around seems pretty easy. And if we change a few things in the data models, the effect flows right through the website.
I couldn’t be more pleased.
I do think that if we have tried to implement the features I was looking for in Drupal, it would have been a lot more painful and time consuming. But as I said, I am only the manager.
Thanks – and I enjoyed reading your comparison.
Nice read. I was surprised that you didn’t mention auto-escaping in the security section.
[...] Drupal or Django? A Guide for Decision Makers [...]
[...] has written a comparison of Drupal and Django as a guide for decision [...]
Sorry, this article is disappointing. The title is not justified. This can’t be a guide for decision makers, you are defending why you are using Django. This is not an evenhanded comparison.
I am saying this as a Drupal developer, and I am saying this as somebody who is longing for a more informed juxtaposition of Django’s advantages/disadvantages vs. Drupal’s. Don’t get me wrong, I don’t want to see Drupal appear as the winner of the contest, I’d like to get some insightful guidance that is true to what your title promises.
Finally, let me point out that referring to security announcements as the sign of Drupal being insecure is completely getting it wrong. An active and committed security team producing a regular stream of patches to a plethora of contributed modules is the main reason for the volume of these lists, I regard their work as a clear asset for Drupal.
To compare security reasonably, you _have_ to use a different indicator.
About your ‘Rapid Development’ section, we’ve done lots of Drupal training for our clients for years, and often they can build the site they’re after in a one or two day training session, or at the very least build a technical demo of all the pieces. Quite often we won’t have to touch any code, Drupal has a much lower technical barrier to entry.
If a Drupal site took us weeks to build we’d be out of business very quickly.
@alex_b: First, I was up-front about my bias toward Django, but I was also very sincere in my attempt to evaluate all of these issues fairly. You’ll need to be more specific about the ways in which you feel the assessment fails. Insightful guidance is exactly what I want to provide. Are my facts wrong? What important points have I left out? I’m more than happy to make updates and corrections.
As for security, there is really one measure: The number of security issues that have occurred with both platforms. I wouldn’t know what other measure could possibly matter. Kudos to Drupal’s security team. They’re awesome and I have often encouraged the WordPress development team to work more like Drupal’s. I am not knocking their own work in any way. But to suggest that Drupal is as secure as Django is ridiculous on its surface. Just count the incidents.
@Steven Jones: Without talking about what kind of site you’re having your students build, I don’t know what you’re measuring. You’re right that Drupal has a lower technical barrier to entry for simple sites or sites that don’t require writing of any code. Most CMSs and frameworks can offer a simple tutorial for a simple site that gives new users an early sense of satisfaction. But where the rubber meets the road is what happens after the tutorial is done and real work needs doing. I’m much more interested in what happens when the developer is faced with a complex site.
Steven, so long as you or your clients are using Drupal as kind of LEGO, the barrier to entry is low indeed. But that is using Drupal as a CMS. When the number of modules you (or you client) creates in a project is close to the number of core modules used in that project, you are using Drupal as a framework. And that’s a different beast. You probably end up using 10 or so core modules anyway. With Django you end up using several 3rd-party or contrib apps in a similar way. And then the difference is how quickly can you code modules for Drupal or write apps for Django.
@shacker: I can go into details if you want. Se my reply to Steven just above on general approach.
I’d start with user profile. Drupal Profile module is universal in that you can add profile fields without coding anything but… No way to constraint values to anything. No way to retrieve a list of users with profile fields efficiently – each profile field value is a separate record and you have to join with profile_field table too for field names. Django, it easy as declaring an entity, adding a setting in settings, and declaring property on user. Done. Then let’s talk about file uploads where you have multiple attachment types that should go into different subfolders on server. In Drupal it all goes into a single folder, and as temporary content at that. You have to write code to copy file to a proper location and making it permanent after upload. A lot of unnecessary work. And good luck creating your own content module (one that is a “node”) – you want that for 3rd-party and core modules like voting, comments, RSS publishing, etc. working with it seamlessly. There are so many little things you absolutely must do and that are not clearly documented… Sigh… Making comments app working with your own “content”? Easy. Your content is defined by entity/table name and object id. Intuitive too. That’s content management in Django. It gives more CMS freedom than Drupal. Going back to user profile. In Django I can add my app specific profile and still have forums specific profile and then profile for some other app, all of them working together.
These are technical details but should be clear enough for decision maker to understand the difference in flexibility of two systems.
Alexei – I’m a bit confused. I thought you were saying that I wasn’t fair to Drupal, but your response lists a bunch of Django advantages. All of them are good points, but don’t do much to improve Drupal’s case!
Although I am a “Drupal expert” after 3+ years of Drupal and work for Acquia, I agree with many / most of your points. My true love is Python, and I have the same complaints about Drupal. HOWEVER, this is a pathetic excuse for a “guide” it is simply propaganda for one system. You make a disclaimer of bias, heh. Should be a disclaimer that at times you might be fair or reasoned! The entire article is bias. Please simple change the title to:
Hey CIO: Choose Django – it is better than Drupal. Here is why.
That would be responsible journalism.
Drupal is not a product, a framework nor a development environment. It is a community. And a big one. The reason I work with Drupal instead of what I consider a better system (like Django), is that Drupal has a huge community, momentum and a ton of code which is written and out there. I agree, if you’re not building a CMS, PLEASE don’t use Drupal. But if you are, you can build something faster, find more developers and deploy it easier than anything else out there to my knowledge.
Jacob – Those are some really strong claims you’re making. Like I said to another poster above: 1) I gave props to Drupal wherever due. 2) I was up front about my bias. 3) If there are specific points about Drupal that you feel like I missed or got wrong, please point them out.
On the power of the huge Drupal community, I totally agree. And my piece was careful to spell that out and give points to Drupal on that one. So… it’s really not clear to me where your vitriol is coming from.
Shacker: His claims are warranted, the title of your post is misleading. This is not in any way an even handed or comparison. It’s a long list of your own subjective opinions based on superficial knowledge of Drupal and a more in-depth understanding of Django (which admittedly pays your bills).
The choice of languages, frameworks, etc. will always be a never ending subjective argument amongst developers. Everyone will have their argument for what makes them a better and more productive engineer. For decision-makers however (professionals putting money behind technologies) more rigor is required beyond individual developers personal preference.
Here are a few reasons why it makes more sense for a decision maker to invest in Drupal rather than Django:
1) Drupal by all measures of an open-source project is a magnitude larger than Django. Core contributors, community members, deployed sites, any way you want to compare numbers Drupal is a much more established project.
2) Drupal is more proven in the market place. It runs magnitudes more websites (500,000+), and many of note. Whitehouse.gov yes, but Viacom, Warner Brothers, Yahoo, Wikipedia and others all run highly trafficked Drupal sites and have made strategic business decisions to invest in the platform.
3) Drupal has far better commercial support in the marketplace than Django. There are many more (and more qualified) Drupal development shops and specialized service providers in the marketplace.
Note: My bills are being payed by Drupal.
Disclaimer, I’m a (not very active) member of the Drupal security team, and a very active Drupal core developer.
“As for security, there is really one measure: The number of security issues that have occurred with both platforms. I wouldn’t know what other measure could possibly matter.”
Well not really. The Drupal security team regularly releases SAs for security issues which in some cases are theoretical, in many cases have never been exploited (simply reported after code review), and very often require either authenticated or some level of administrative access to a site. Additionally, the 3-4,000 contributed modules are hosted centrally on Drupal.org, not distributed around the web, and have the same rules for security announcements as Drupal core, handled by the same process. The number of security announcements for Drupal core itself is relatively low given code base and deployments, although could always stand to be better, the same can be said for high usage modules like CCK and Views – and these are reviewed by many, many thousands of developers over time.
To make the comparison meaningful, you’d need to additionally compare the process for releasing SAs, what is considered a threat worthy of SA, to what extent third party modules and themes are supported etc. etc. – there’s no discussion of this in your article or responses.
For example the only information I can find about Django’s security policy from a quick google search is http://docs.djangoproject.com/en/dev/internals/contributing/#id2 – this doesn’t mention DjangoCMS, in fact it appears to exclude both that and third party modules too. And a search on http://www.django-cms.org/en/search/ for ’security’ returns zero results.
This is before you even get to the point of comparing Apples to Oranges – first you need to make sure you’re not comparing one apple to a whole orange grove – and an orange grove where pretty much anyone can check a rotten orange over the fence (i.e. release a module on Drupal.org ;)).
On the overall article, I agree this could have done with more insight from the Drupal side, since there are inaccuracies there, and an obvious lack of detail.
For example Drupal 7’s field and entity APIs are a step towards an ORM, our database layer and many other subsystems including contributed modules like Views are object oriented (to various extents) etc. – this information is absent from the article and belies the experience of someone who’s only dabbled with Drupal 5 or 6 – while Drupal 6’s API was officially frozen 2.5 years ago and Drupal 7 has been in rapid development for more than 18 months, with probably 1-3,000 patches commited by this point. I also agree with Alex B that the balanced and informed analysis I’d hoped to read here can’t be found in many other places either in regards to Drupal and Django, so perhaps a second round is in order – although I personally don’t know any Drupal developers familiar with Django but I’m sure they’re around if you ask.
Thanks so much for the feedback Zack Rosen and catch. I’ve added a whole new section on “Popularity/Installed Base” based on Zack’s comments and have interleaved several of catch’s points into the article. Much appreciated.
Zack Rosen said, among other things:
I suspect you are underestimating the size and velocity of the Django community, a community which certainly benefits from the size and velocity of the greater Python community. In the web space Python has long been used to create complex web applications. There is a sizeable community of CMS experts in the Python family, and a certain amount of cross-pollination between the various Python clans (Django, Zope/Plone, Turbogears and others) occurs as routine.
Google takes us to the following pages for Drupal and Django service providers, both look “similar” in size.
drupal.org/drupal-services
code.djangoproject.com/wiki/DevelopersForHire
Perhaps of more significance than listings of companies for hire, are listings of companies seeking employees to hire.
Drupal wins in the “available jobs” category, but what a Drupal “job” is varies greatly. Very frequently they are requests for 200$ worth of theming work here, a $25 button job there. 177 jobs of this variety are listed at oDesk.com. There are some 700 plus jobs available (since July 2009) as noted on http://groups.drupal.org/jobs. However there too the nature of the jobs ranges from “themer” to hourly-paid subcontractor for minor alterations to Drupal related work (project management) that isn’t strictly a Drupal job. Some “jobs” are requests for partnership, or system admins, designers and such, so it is difficult to gage what the demand for skilled programmers familiar with Drupal is, other than it is likely to be a vibrant marketplace. If we filter the Drupal jobs search result to only “full time employment” the available jobs number (since July) is closer to 300.
The Python story here isn’t terribly clear either, but for different reasons, as Python is a general purpose language, not a CMS, so there are quite a few distinct communities each with their own employment circles and of course there are some areas of overlap. It would appear that Django, and perhaps Python itself, could benefit from a more wide open job posting system in a central location. On the other hand, the jobs that typically land on the Python.org site tend towards the higher end and it may be that recruiters and prospects alike favour the higher signal to noise ratio found there.
Higher end development jobs tend to show up on the Python.org site itself (www.python.org/community/jobs/), so lets see what the ratio of Django jobs to all others is:
>>> from lxml import html>>> url = 'http://www.python.org/community/jobs/'
>>> doc = html.parse('http://www.python.org/community/jobs/')
>>> len(doc.xpath('.//div[@class="section"]'))
131
>>> len([job for job in doc.xpath('.//div[@class="section"]') if 'Django' in job.text_content()])
51
>>> 'Django mentioned in %.1f%% of Python job board requests posted since July' % (51/131*100)
'Django mentioned in 38.9% of Python job board requests posted since July'
In addition you’ll find Django positions noted at:
code.djangoproject.com/wiki/DjangoJobs
djangogigs.com/
http://www.djangozen.com/
Another 80 or so jobs are listed on the Django Jobs wiki page; another 11 on Django Zen; another 20 at Django Gigs. oDesk.com lists 14.
Maybe Monster.com can be used effectively here to compare, as that site typically won’t be used to list a 200$ “job”. Monster.com lists 69 jobs (U.S. only) that show up with “drupal” as the only search term, and 43 jobs (U.S. only) for a Django search.
This article is a little confused, as Drupal and Django cannot be compared.
Drupal is a CMS, like Wordpress or Joomla
Django is a framework like Rails or Symfony
Hope this helps,
Dave
@Dave, that is not quite accurate. Drupal is not like Joomla or Wordpress. It has much more framework-y architecture. And there’s very strong movement to emphasize/engance that in Drupal. Even now, there’re a bunch of “distributions” built on top of Drupal that don’t look/feel like the base distribution.
Similarly Django has some things (admin UI, for example) that you would not find in a typical barebones framework.
So, yes, Drupal has more from CMS and Django is still more a framework, but the line is not totally black and white i.e. that is not the biggest issue while comparing the two. For what I think is the biggest issue – you can see my comment several posts earlier, if you are interested.
Another thing to clear up:
“Django uses the model-view-controller methodology (going by the name MTV in Django-land). This means that in Django, developers have almost complete separation of logic (programming), data structure, and display logic. Contrast this to WordPress theme development, where developers have to copy chunks of logic over to the new theme manually if they ever decide to change themes.”
Wordpress?
Drupal’s PHPTemplate theme layer gives you a lot of freedom to do processing in themes, which can be good or bad depending on situation/skillset etc. I much prefer phptemplate to smarty or what I’ve seen of wordpress theming (which is literally copy and pasting business logic around).
However, even if you do have code which you need to share between themes: since at least Drupal 5, we’ve had theme inheritance (sub themes) which means if you have some central logic which would need to be re-used between multiple themes – whether that’s templates, CSS files, preprocessing etc. (either on the same site or completely different sites) then there’s zero need to copy this between them – you just have your base theme with that stuff in, then build a subtheme on top of it, subthemes can be as light as a single css file. Once again wrong information which could have been cleared up by a couple of quick questions in the #drupal irc channel, although I appreciate you trying to incorporate some of this discussion into the blog post retrospectively to some extent.
Also on MVC in general, Larry Garfield wrote an excellent post on this common criticism of Drupal here: http://www.garfieldtech.com/blog/mvc-vs-pac – just saying “Drupal isn’t MVC” is on the same level as saying “Drupal isn’t OOP” – there’s no actual argument being made there.
@shacker: Sorry, I thought your response was to me (it was to @alex_b, see the similarity?).
In defense of Drupal, it is good as CMS and has practically anything you would ever want from a CMS. If you want to use it as a framework you need to avoid using 3rd-party modules and many built-in modules from the start and plan to write a lot of your own modules. A deep knowledge of Drupal workings is also required. Then you are golden. Why avoid 3rd-party modules? They are (typically) built with a lot of configurable parameters and complex pages for configuration. It’s a good thing for CMS but may be a huge overload for your custom site. And then you are stuck with wherever that module author(s)’ fantasy would lead him/her/them in the future. They are not part of the core and hence are not that conservative.
What would make Drupal more usable as a framework is a nice ORM and better routing system (existing one is close but paths are spread over modules and are prone to collisions).
This is a terrible article. I am interested in a legitimate comparison, not a thinly veiled promotional piece for Django. Who do you think you are fooling? If you want to say how Django is so much better than Drupal, just say it, don’t pretend that you are doing a guide.
Excellent article. I often find myself going with Django simply because I want it’s flexibility and with open source Django apps that you can use like basic-apps and Django CMS, it’s fairly easy to get a lot of the functionality of a CMS like Drupal.
[...] the original: Drupal or Django? A Guide for Decision Makers — scot hacker’s foobar blog Comments0 Leave a Reply Click here to cancel [...]
The author just fever by Django, nothing wrong here, but then this guide for Decision Makers who want to hire(or already have) Python/Django powered team, nothing more :)
i.e.
With a little effort you can re-post with new subject “Why I like Django?”.
On other hand I am really glad that Drupal being compared to frameworks, even such great as Django. And any experienced decision maker should pay attention to this ;)
[...] been meaning to link to this for a while. Scot Hacker looks at Drupal vs. Django and why he prefers Django to Drupal. (With a [...]
@catch – Thanks again for your useful contributions. I’ve updated the Templating section with your notes on Drupal’s sub-theming system, along with new notes on Django templating from myself.
ryan and others – The piece is called “A guide for decision makers” because that’s what it is. Such a guide should be as even-handed as possible. I’m working hard to make it as fair and as objective as I can. Like I’ve said a bunch of times: If you feel like I missed something or got something wrong, be specific in your comments and I’ll amend the article. Don’t just complain because the comparison doesn’t make Drupal look as good as you want it to. Open yourself to the possibility that, gee, maybe there are tools out there that do things better. This isn’t religion, this is software. Be open, be objective, and let’s have a meaningful discussion.
I think it’s inaccurate comment to be placed into guide for decision makers.
I also can confirm that I never had any problems with Django at all!
p.s.
I never used Django :)
Great conclusion, but breaks whole subject, how could I made decision after reading this? :)
And as a decision maker, I should pay attention to more general things, like:
* experience of your team players
* customer requirements
* licensing
* other conditions
Isn’t it?
I might be wrong, let me know :)
Thanks.
* experience of your team players
Absolutely. Or willingness to go out and find the right team players for the project.
* customer requirements
Only barely related to this discussion.
* licensing
Both systems are GPL.
@shacker,
you seems wrong about licensing
Drupal – GPL
Django – BSD
I think decision maker should take this into a count among with customer requirements.
Drupal is a CMS and a framework. It has a robust API and an advanced system of hooks. The fact that you can make Drupal do just about anything is proof of that.
You would have been better off, since you’re really talking about frameworks, comparing Django to CakePHP, Symfony, and Zend Framework.
(Disclaimer: I’m a Drupal developer with much respect for Django, though I’ve never used it.)
What I consider Drupal’s real strengths are the modules you use for building sites. In Django you’ll code sites from the ground up (which Django does better than any other system!). In Drupal you can rapidly build sites using modules (tools, rather) such as CCK, Views and Rules, with very little time spent on reinventing the wheel.
With the 3 mentioned modules in particular, I’m able to build very diverse and often complicated sites with very little custom code, in a short period of time. That is a fundamental difference between Django and Drupal.
As always, you need to do things right, or you’ll end up with a lot of custom code and a mediocre result. It’s all about doing it The Drupal Way™.
Another obvious point; you need to pick the right tool for the job. Drupal and Django are both great systems, and you need a good understanding of both in order to make an intelligent decision.
@Erich – First, the piece explains very careful why comparing Django and Drupal is legitimate – re-read the first few paragraphs. Second, you’re contradicting yourself. You say Drupal is a framework, then you turn around and say I should have compared Django to a different framework.
@Ximo – The functionality of CCK, Views and Rules are already inherent in Django, so I’m not clear what you mean by That is a fundamental difference between Django and Drupal..
@schacker – What I meant was that with Drupal’s modules you can achieve advanced functionality without any code at all. You will need to code to achieve what you want, but a lot can be done through configuration only. This is what I find unique about Drupal and makes for very rapid development.
This is great in a lot of cases, but there are just as many cases where it’s not the best way forward, where Django would be more suitable.
Other Django / Python pros:
WSGI: This is not merely a method for hooking up your application to a web server (aka mod_wsgi) but is an interoperability shim that allows for “middleware” to be wrapped into your application. Even a relatively passive WSGI consumer application (which some might argue Django is) can still take advantage of this flexibility.
For example with just a handful of lines of code I can wrap most any sensible Python web app/framework with an interactive debugger that allows me to explore exceptions and variable states at the time of exception – even see code snippets from each layer of the traceback. I don’t have to write this, or **modify a single line of my application code** — another toolkit, Paste, (or a prettier example from Pylons) gives me all that capability for free.
Personally I prefer slightly less opinionated frameworks than Django; If I were looking for a Django-like experience, Pylons or Turbogears would likely be where I would cast my eye simply because they were designed from the start to enable the wholesale swapping out of major components (like an ORM or templating system) while Django prefers to be something of a closed single source ecosystem albeit a highly productive ecosystem.
One nice thing about WSGI is that it allows for a certain amount of bridging the two solitudes, and as I pointed out in the debugger example, often this can be done with quite literally four or five lines of integration code.
Interactive console: Django / Python offer a fully interactive command prompt where you can directly manipulate your data objects; it’s an incredibly powerful tool not only for working with the application data but also for quickly proving out snippets of code. Out of the box, if your OS supports readline you can have tab expansion/code completion, and with some minor tweaks you can even have syntax highlighting if you want. PHP has nothing comparable.
Indeed virtually any common Python web app framework exposes this type of capability because Python itself makes it almost trivial to do so.
Python as a “feature” of Django while touched upon in the article and comments is a key differentiator that is probably not stressed enough. I’ve mentioned the interactive prompt as but one feature; Unicode handling is another; it is sane and has existed in Python for many years; with Python 3 I would argue Unicode handling moves beyond sane and approaches “easy”. Consistency is a “feature”; you won’t find dozens of compiled in functions that purport to do what others do. You won’t have to recompile your Python just to get X or Y feature enabled, just “import something”.
Want a standalone test environment on the same box as your server? No problem, there is “virtualenv”, a stunningly simple method of creating little mini standalone Python environments to avoid polluting your system Python or your production environment.
Packaging works well, and is being continually improved (distutils / setuptools/ distribute / pip et al). You can write an application that has a swack of dependencies and deploy a simple setup.py script which checks for and installs the right dependencies. PyPI – the Python Package Index, hosted on Python.org itself, is another key “feature” that not only enables browsing and searching for available third party packages but also forms the basis for automated installation of same.
These are but a few features and capabilities which one gets when they adopt any Python framework.
I enjoy reading the article, and I understand also the article itself, but also the comments made by django and drupal developers.
For example I like PHP, so it’s easier for me to understand Drupal, than Django. Also I like to made beautiful websites, because I like web design. I think problem of developers it’s that they don’t understand web designers also, who want more cretive and beautiful websites, than to think at coding. That’s why I start to tend to be more developer, than designer. I start with Joomla, for example, which is a pleasure for designers (and out there are a lot of very beautiful websites made in Joomla, than made in Drupal or else), but because of security problems and because I wanted more control over my work, I started to tend more to Drupal.
But to make my point, it was same discussion on a training in Drupal in Amman, between Jacob Redding and a developer, employee of a firm that started training, who love django, because of simplicity to code, than Drupal, which seems to him that must to learn too much the settings for modules and themes.
So end of the story is that Drupal is a beauty of coding, if you look closely, and at first they started developing for enterprise companies, and now, with Drupal 7, tend to gain also the users, because everybody see now that wordpress become so popular these days because of that. After all, users decide the popularity and strength of a CMS.
Thank you for pointing my attention to me with this article to Django
Hmmm.
I appreciate the article, and I would like to try out Django sometime. But when every problem with Django is described as a minor problem that will go away or can be ignored, but every problem with Drupal is described as a hideous show-stopper, it really does show a bias in big glowing lights, to me.
That said, I make a very good living writing Drupal code.
John
John – Do you think this article does that? (trivializes Django problems and magnifies Drupal problems?) Or is this comment based on something you read elsewhere?
@shaker,
Thanks for the great write-up. I first stumbled upon the article while it was still in draft and have been checking back since. The comparison of Drupal and Django has been on my plate recently and the article along with the comments has provided confidence in making my mind up.
I have little experience with either of these, much less with Django. Given this, I unfortunately don’t have much to add to the discussion (yet) when it comes to comparing the fruit in the bowl. However, what a lot of commenters seem not to understand is that this is a business comparison. If you build a house, will the factory built modules (they do those in Scandinavia at least) give you the desired outcome, or do you want to have it custom built from the ground up to suit your preferences?
It is also mentioned, that the two options being weighed already have a foothold in the current organisation. Shoving either of these at an organisation with, lets say a heavy .NET/Windows base would not necessarily be a good thing for anyone, depending on what you would intend to do with Drupal/Django. It all depends on a number of moving parts in the business and the resources at hand. So, in this respect comparing the two still holds a valid business argument in your case. Choosing between the two is then down to checking them against the business requirements.
If you are in the happy scenario, where Drupal/Django are a viable option, then to me it’s all about choosing the right tool for the job. Personally, I like to work with only the essentials, work from a clean slate up and keep my code super tidy and front end code totally under control. If the business requirements cut it, my choice would be obvious: Django.
What about .net based solution like Kentico CMS?
John – I’ve heard good things about some of the .net based systems. But there are more than 600 systems listed at cmsmatrix.org. I chose to compare just these two simply because they’re on our personal radar. So … that would have to be a subject for someone else’s article.
Why would non-technical people make decisions on whether to use Drupal or Django? Because they are the decision-makers in most organizations. They write the checks, sign the contracts and have to work with leadership (and sometimes, the board or a sponsor government agency) to get approval for any project. If you don’t get non-technical people on board for a project, it doesn’t happen. The Webmaster, though the most-technically savvy person in an organization, is often more likely to be an adviser than to be the decision-maker. Given that the CMS will be used for several non-technical purposes, those needs will prevail over the non-technical aspects.
Also, if you are running a nonprofit or a small Web operation, there will be several people involved in managing the CMS. A Webmaster will not be able to handle all the technical issues alone; the director of new media at an organization, for example, will also play a hands-on role as will the marketing director. Those folks, although not the technical masterminds of the organization, will be the ones making the key decisions when it comes to CMS selection and implementation. And they will have several other issues (including customer relationship management, cause marketing and even community-building) to weigh alongside the technical issues.
I’m someone who was a program person at a non-profit and, over a two-year period, evolved into becoming a Drupal developer. I was originally one of those non-techy managers who needed to make a platform decision. In early 2006 I researched Joomla, Drupal, and Plone and decided on Drupal for the non-profit I used to work for.
The world is changing so fast. @shacker wrote:
For small and medium sized businesses and non-profits, non-enterprise solutions, it’s often a mistake to tightly build a solution around a “glove” because the glove is going to be changing soon. Many argue that an org should fully develop a spec independent of the platform. Initially that certainly couldn’t hurt. But in many instances it’s not healthy for an org to take it’s “requirements” too seriously because often they are brand new or part of a legacy work-flow that was never that good. It’s no sin to play to the strengths of a platform, when appropriate.
In many cases it can be incredibly efficient for the spec to bend to the CMS rather than the other way around. Developers sometimes take a spec too seriously. Sometimes that is because they are trying to listen hard to the client while not knowing much about what they do. And it may be partly because of increased fees that might accrue from custom coding to a specialized work-flow.
For an enterprise ap where the requirements are set, it makes no sense to use Drupal. It’s in a quickly changing world where every business and org are trying to communicate with constituents in new ways in which Drupal will lead and thrive.
Actually, WordPress does have it’s own equivalent to Drupal’s ’sub-themes’ referred to as ‘child themes’. Anyway, interesting article.
Hi.
Just asking about bundle of applications of Django.
…and what database it supports?
Thanks…
drupal programmers
drupal vendors
Well, what do you want to know about them?
Right now it supports sqlite, PostgreSQL, MySQL, and Oracle. There is also discussion about adding support for non-relational databases here.
I think Decision Makers(especially startups) would be interested in more case studies from both workshops, for example:
Upcoming Webinar: Integrating Drupal with Enterprise Back-Office Systems to Deliver a Best of Breed e-Commerce Site http://is.gd/5SUBI
And later it will be available at
http://acquia.com/community/resources/recorded_webinars/
[...] Lire Drupal or Django? A Guide for Decision Makers. [...]