Drupal or Django? A Guide for Decision Makers

125 Replies to “Drupal or Django? A Guide for Decision Makers”

1. 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.

2. Maybe check out django-cms.org. With this you get a CMS on top of a framework.

3. 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.

4. 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.

5. @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.

6. Pingback: Drupal’s prominence is hurting the PHP frameworks, such as Symfony

7. 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

8. 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.

9. Pingback: Drupal, [WordPress] or Django? A Guide for Decision Makers

10. 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.

11. 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.

    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.

12. 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.

13. 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.

14. Pingback: Drupal or Django? A Guide for Decision Makers — scot hacker's … Hello CMS - the best cms website

15. 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.

16. 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.

17. 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?

18. 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.]

19. 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.

    Michael: 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?

    No, I don’t imply anything of the sort. The track record is the track record and numbers are numbers.

    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.

    Exactly. You’re re-stating the point I made in the article.

    Stop comparing apples to oranges.

    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.

20. 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.

21. 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.

22. 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

23. 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.

24. 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.

25. 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.

26. Henrik –

    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.

    It’s not a bad thing! I didn’t imply that it was.

    As someone else pointed out Django does a lot less out of the box, so it’s bound to have fewer security flaws.

    That’s exactly the point I made in the original article, above.

27. Lawrence said:

    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?

    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.

28. 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

29. 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.

30. Pingback: links for 2009-11-16 | Aram on Mason

31. 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.

32. Nice read. I was surprised that you didn’t mention auto-escaping in the security section.

33. Pingback: Max Design - standards based web design, development and training » Some links for light reading (17/11/09)
34. Pingback: blog:2009-11:17_drupal_or_django [ConsEbt]

35. 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.

36. 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.

37. @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.

38. 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.

39. @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.

40. 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!

41. 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.

42. 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.

43. 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.

44. 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.

45. 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.

46. Zack Rosen said, among other things:

    There are many more (and more qualified) Drupal development shops and specialized service providers in the marketplace.

    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.

47. 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

48. @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.

49. 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.

50. @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).

51. 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.

52. 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.

53. Pingback: Drupal or Django? A Guide for Decision Makers — scot hacker’s foobar blog

54. 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.

    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.

    If you want to hire me, choose Django!

    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 ;)

55. Pingback: Drupal or Django (and WordPress)? » Dissociated Press

56. @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.

57. 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.

    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 :)

58. 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.

    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.

59. * 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.

60. @shacker,

    you seems wrong about licensing
    Drupal – GPL
    Django – BSD

    I think decision maker should take this into a count among with customer requirements.

61. 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.

62. (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.

63. @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..

64. @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.

65. 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.

66. 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

67. 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

68. 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?

69. @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.

70. What about .net based solution like Kentico CMS?

71. 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.

72. Jani Hartikainen says:
    November 16, 2009 at 1:50 am

    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.”

    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.

73. 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:

    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…

    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.

74. Contrast all of this to WordPress theme development …

    Actually, WordPress does have it’s own equivalent to Drupal’s ‘sub-themes’ referred to as ‘child themes’. Anyway, interesting article.

75. Hi.
    Just asking about bundle of applications of Django.
    …and what database it supports?
    Thanks…

    drupal programmers
    drupal vendors

76. Just asking about bundle of applications of Django.

    Well, what do you want to know about them?

    …and what database it supports?

    Right now it supports sqlite, PostgreSQL, MySQL, and Oracle. There is also discussion about adding support for non-relational databases here.

77. 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/

78. Pingback: Comparer et choisir son CMS : Drupal et Django par Scot Hacker | bertrandkeller

79. I found this as interesting a guide for developers interested in getting into Drupal or Django as it was intended for project managers or decision makers. My own evolution and experience in database driven sites is from working with Symfony many years ago, to custom intermediate level PHP/MySQL sites, to learning WordPress and Joomla, with significant investment in learning the Joomla framework. Somewhere along the line I checked out both Drupal and Django, but had settled in the Joomla camp for awhile. A recent project forced me into Drupal, and I’ve been working with it for going on six months. I inherited the site rather than creating it from scratch.

    As reported here, Drupal can be really slow in the admin, which can make even doing the simplest changes a tedious nightmare of watching the little blue Drupal clock spin for fifteen seconds every time you save. I’ve just come from a week of working with Views, and while it greatly extends the capabilities of Drupal, the admin form does not allow you to make multiple configuration choices at once, but one at a time, and each time can be a tiny eternity if you stop and think about how long you are waiting. I don’t want to think about how much I actually got done the past few days.

    The performance issues ARE a concern, and already even a relatively small site, with a base of about 2000 nodes, is creeping more slowly than it should whether in the front-end or in admin, which always runs much more slowly.

    The comments about having to undo or take away things is right on track, only it doesn’t allow you to take things away very easily sometimes. I have had to find code hacks for simple things like removing the default title and getting it to convert dates from a Unix timestamp into human. Having worked with Joomla, I am used to such things being considered a given.

    There may be a large community, but utilizing it can be as cumbersome as the software. The Drupal site is unwieldy, sprawling, and strangely organized, obviously built around the same presumptions as to how information is created and organized as the Drupal software. It’s also just not good-looking or easy to read, with few visual cues as to where you are. This was my first turn-off to it a couple of years ago. After months of working with it am I only beginning to understand the logic behind the site, as I am beginning understand the logic behind the software. It did not take me this long with Joomla and I know less then than I do now. It just seems to me that everything related to Drupal has this steep learning curve, this built-in opacity and density to it that seems embedded in the very culture surrounding it.

    For example, I have read few module descriptions and understood from them clearly and immediately what the module does. If you don’t know Drupal-speak, it’s not going to help speed things up for you because there are 3000 modules when you aren’t going to have any idea why you need even the most basic recommended modules like Views until you’ve worked with the system for awhile. For some reason, few of the developers like to speak plain English as if their audience was the GP or new developers chekckng out the system, but instead like to all speak to each other in Drupal-speak. It seems like once you’ve gone through the trial by fire, you’re in the club, and now you’re not going to make this easy for anyone else, either.

    This blog post has been formative in my trying to determine which way to go in my development path, especially concerning Drupal. Should I continue down this tortuous path— and is is really tortuous, or is it just me? Reading about why others with far more experience have left the fold validates the concerns and criticisms I’ve had.

    There really is this clubby, insular, even protective atmosphere to the Drupal world, and quite a bit of snobbery, though you find that to some degree in any of these communities. But I am not sure why Drupalites are so proud of their arcane Drupal knowledge when so much of it, while not proprietary in the legal sense, is nonetheless not really applicable anywhere else. The future is really in MVC architecture and OO programming, which are becoming a universal languages of sorts. Knowing something about them enables me to read the intro pages to Django and understand what is going on much more quickly and clearly than I have with any page on Drupal, even though it uses Python, which I have not really used. It seems to me that frameworks like Django and Symfony are the way to move into the future(and even Joomla is developing a pretty strong MVC framework too, beyond just being a CMS), and as soon as I can I’m going to revisit those options. It seem to me
    Drupal is still working in some very old-school paradigms, and insists on continuing to do so in the face of what appear to be superior developments.

    “Agile” development is a much bandied about term term these days. It seems to me that to be a successful developer you must be personally agile in your skills and able to handle any number of different frameworks, CMS’s, languages, databases, etc. This is why I took on the Drupal challenge. But how much can I take from the Drupal world and apply to anything else, how does it help me be personally agile in the Web dev world, or be agile with it itself? Instead, it seems almost purposefully obtuse at every turn, like a cult that inverts your usual thought processes — therefore requiring absolute devotion in order to believe it and master the intricacies of its theology. I don’t want to join a cult and be one of the select few of an elect priesthood. I just want to make Web sites.

    What is interesting to me is how Drupal is gaining this foothold, and you’ve got it being used by major corporations and even IBM development teams. Am I still missing something?

80. Pingback: We’re in the information business

81. To me, starting the with the data model and being able to define it yourself makes a ton of sense, though it might not apply to all cases. But with the kind of customized Web sites you mention, it seems the best way to go. Historically this is the opposite process upon which Web sites have generally been built, which was an outside -in approach as opposed to an inside – out approach, which meant you’d start with what we would now call the “view” and make a visual mock up of the site (which of course had to be based on some foresight of what data is to be presented), then work your way back to creating the data structures and programming the would fill out that vision.

    Of course, you could never get that visual 100% right from the outset, because as you dig deeper into the data and the programming, you always realize you missed something or made improper assumptions about function in favor of looks, and you have to make adjustments. This makes for a development process with lots of re-iterations based on feedback coming from the data modeling and programming development, and on what you find you can actually do versus what you thought you could or wanted to do. This feedback loop will and probably should always be part of the process, but if you stop and think about your data model first, you’ll have a much clearer vision of what the site is all about from the outset. It seems to me this can positively affect everything else as it percolates back up into the real world, including your usability, your graphic design, your marketing, etc..

82. As Ximo points out, one of Drupal’s main strengths is the malleability it offers non-developers. Sites can be built from ground-up with no programming at all. Further, new features can be rolled out without the involvement of developers. Modules like Panels, Views, CCK and Rules allows you to build workflows, views of data, data models and business logic within the user interface of Drupal! Doing that same with Django would require writing code which is a burden to carry.

    Configuration, unlike code, is safe in the world of Drupal meaning that when a new version of Drupal is released there’s a guaranteed upgrade path for your configuration, but you have to manually update your code for the API changes.

    ORM offers beatiful abstraction, and is naturally suitable for an organization with specific needs, but Drupal’s fields and content types gets you almost the same flexibility without having to pay a developer to write code! This doesn’t just save development time, it also means less cost over time and there’s less custom code to maintain and update as you upgrade your site when new versions of Drupal are released.

    If your needs are very specific and you are prepared for the cost of doing a lot of the development work yourself and want to bring it in-house, then Django may be the right choice. There are cases where choosing Django over Drupal is cost-effective but those cases require you to have Python skilled developers in your own organization.

83. ORM offers beatiful abstraction, and is naturally suitable for an organization with specific needs, but Drupal’s fields and content types gets you almost the same flexibility without having to pay a developer to write code!

    Jakob – To be clear, the ORM isn’t what provides content types or fields – it replaces the need to write SQL to get at the data store. Rather than SQL, the ORM syntax is very user-friendly, far easier to comprehend than writing SQL.

    This doesn’t just save development time, it also means less cost over time and there’s less custom code to maintain and update as you upgrade your site when new versions of Drupal are released.

    In my experience, Drupal sites are pretty prone to breakage with major updates. In contrast, there are very few situations (with the exception of the pre-1.0 newforms changes) where Django upgrades required code updates. And when they have, they’ve been pretty much trivial. I think the comparative ease of upgrades with Django is one of its strengths. Or maybe it’s a strength of frameworks over CMSs in general.

    If your needs are very specific and you are prepared for the cost of doing a lot of the development work yourself and want to bring it in-house, then Django may be the right choice.

    It’s certainly true that Django is all about writing code. I’d argue that any site complex enough to go beyond what WordPress can deliver is worthy of having a good developer on staff.

84. Jakob – To be clear, the ORM isn’t what provides content types or fields – it replaces the need to write SQL to get at the data store. Rather than SQL, the ORM syntax is very user-friendly, far easier to comprehend than writing SQL.

    I am aware of that but Drupal also abstracts queries through CCK and its integration with Views, why I mentioned CCK.

    In my experience, Drupal sites are pretty prone to breakage with major updates. In contrast, there are very few situations (with the exception of the pre-1.0 newforms changes) where Django upgrades required code updates. And when they have, they’ve been pretty much trivial. I think the comparative ease of upgrades with Django is one of its strengths. Or maybe it’s a strength of frameworks over CMSs in general.

    I find that hard to believe, the API will have to change as your framework develops rendering code obsolete. You cannot avoid maintaining code. Drupal helps you avoid it by allowing you to do a lot without writing any code at all. Further, updates do work, almost every module provides an upgrade path from major versions.

    It’s certainly true that Django is all about writing code. I’d argue that any site complex enough to go beyond what WordPress can deliver is worthy of having a good developer on staff.

    As a developer you think so, yes. However most clients think differently. First of all they’d rather rely on a consultant for support, technical advice and initial development. They are also attracted by Drupal’s ability to empower non-developers to take on tasks usually reserved for programmers. With Drupal you don’t need to pay a full-time developer, in fact your other staff can extend, adapt and improve your site without having to involve the IT department (or need it at all). That means shorter release cycles and time to market. That is a very compelling reason to use Drupal, one which Django cannot match.

85. I agree with Jakob but want to add a couple points for emphasis.

    It’s certainly true that Django is all about writing code. I’d argue that any site complex enough to go beyond what WordPress can deliver is worthy of having a good developer on staff.

    I was struck by the word “developer” in the singular. What happens when that developer moves on to another job? Do you have another developer on staff supervising that person to make sure he/she is commenting the code well so someone else can take over? Who is reviewing the code?

    In addition to Jakob’s point about clients not wanting to have a developer on staff, add to that the fact that companies often feel like they are being held captive by developers, or even whole software companies, because the developers/shop are the only ones who understand what’s going on under the hood of the web ap that client paid for.

    With Drupal core and popular modules you’ve got thousands of sites running the same which is an amazing advantage. And yet, customization keeps getting easier to you aren’t locked to a Drupal site that looks or behaves like every other Drupal site.

    And sure, Drupal’s approach bakes in the fact that they were always be some code baked in to any implementation which is extraneous to the web application being delivered. Mitigating that problem, though, is a whole ecosystem within the Drupal community which focuses on scalability and performance. We can now consider the Obama administration part of that community as they have just contributed three modules to the Drupal community which deal with scalability.

    Certainly, if you have a very clear set of requirements that aren’t going to change much during development or over time… then Django is likely to be a better choice.

86. Pingback: IA for news websites: a link dump

87. Update: Drupal developer Nick Sergeant has posted a similar piece: Drupal v. Django

88. Drupal can scale really well. Check this presentation on 2.8 million page views a day, 70 million page views a month, on a single server for how it was done. Very little customization.

89. Pingback: Lesetipps für den 22. Juni | Netzpiloten.de - das Beste aus Blogs, Videos, Musik und Web 2.0
90. Pingback: Sourcefabric's Dev Blog › Django Software Stack

91. My site is on Drupal and has been working flawlessly since installation. However, when it comes to customized web apps I guess I literally had to give up Drupal on this n I have started using Django, though I love Drupal n its community.
    I can term Drupal as a safe for building a Community websites n portal coz its quite stable. On the other hand Django object oriented n framework approach is more superior for app development. To support my answer, check out DISQUS the comment plugin it is powered by Django.
    So in short Drupal rocks for newbies n Django rocks for skilled developer!

92. We looked at drupal for Resume Companion resume builder application but ultimately decide to go with a simple file upload CMS for RoR.

93. @Aamiraafi wrote

    So in short Drupal rocks for newbies; Django rocks for skilled developer!

    That point of view is true if developers are the center of the world around which everybody turns. It takes into a account the interests of developers, ignoring interests of clients.

    If you know exactly what you want, it won’t change much over time (or you have the funds to keep paying developers a lot of money), and you won’t need to respond to current trends, … then obviously Django is a better choice. Of couse you would want to build something from the ground up and never include what you don’t need.

    But many clients don’t know exactly what they want right now, let alone how it will evolve in the future.

    With Drupal, it is so much easier to change course and respond to changing needs without a huge expense for the client.

    In other “words”:

    if (customer($knows_what_she_wants==’TRUE’)) {
    Django;
    else {
    Drupal;
    }
    }

94. With Drupal, it is so much easier to change course and respond to changing needs without a huge expense for the client.

    Hmm, that’s kind of the opposite from what I hear from clients over and over again, which is more along the lines of “Drupal sounded like a good idea at the start, and the launch went really well, until we decided to try and change things – that’s when everything went to hell in a handbasket.” Can’t tell you how many journalistic organizations have reported stories to me like this.

    With Django, it’s the opposite story – because you’re always in control and never working around the system’s assumptions, changes tend to go much more smoothly and don’t upset the apple cart as much. I’d argue that Django is more future-proof than Drupal. But that’s an unscientific claim, which I’m basing only on reported experiences of others.

95. Scott and all,

    Something that I think coders don’t get is just how much of a benefit it is to clients when you can implement something without custom code. (I don’t mean a whole project without custom code, but working on the assumption that we DESIRE to write as little code as possible). Custom code requires maintenance… all the more-so when making changes or upgrades.

    When you consider Drupal core combined with the Views, Views Bulk Operations, Rules, CCK, Pathauto, Token, and Webform modules, just to name 6 off the top modules I use on most sites, there is an incredible amount of power and customization that you can deliver to a client without writing one line of code. All those modules are well maintained and upgraded regularly.

    If I get a critical mass of people together petitioning a module maintainer, or better yet, get the client to pay for a bounty on some new functionality, I can get improvements going into a module itself instead of into a custom module that I might build to do the same thing. But if it is in a contributed module, then there is a community to maintain it, not me billing the client.

    So a Drupal site-builder (who may or may not be a coder), ends up spending time finding out what existing modules there are and how reliable they are and communicating with module maintainers etc, doing some community organizing… which is not the typical m.o. of a “coder.”

    What you get for the client is far more stable because so many other people are using the exact same code. It is so much easier to get help when you aren’t using your own custom code.

    And the customizations you do, within a custom module or at the theming layer are segregated so well that you can still get all the help you need based on the shared code base that everyone else is using.

    Those experiences you quoted sound like from the Drupal 5 or 4 days.

96. Fair enough – I should take a look at Drupal 7 when it’s released. For me to consider it seriously, it would have a templating system as smooth and smart as Django, would have to have an excellent ORM, and would have to have become object-oriented from top to bottom. But yes, I do recognize the importance for some organizations of being able to do certain kinds of things without programming.

97. Drupal 7 was released yesterday. It looks really cool, and is an even greater improvement over D6 than D6 was over D5 and D4.7.

    Drupal is available in several distributions or profiles, each including modules that have been tested to work well together for specific purposes. These include Acquia Drupal, which is still (as I write this) based on Drupal 6, and includes all of the modules that Shai Gluskin said that he bases most sites on (except for Views Bulk Operations and Rules, which are easily installable) and then some, all in an easy-to-install (a single SVN command at a shell prompt will download it, using your server’s fat pipes! After that, just make sure that you have a MySQL or PostgreSQL DB available with database owner privileges, then navigate to the site’s main URL with your browser and run the simple browser-based install!) and easy-to-maintain (a simple “svn up” will update your install whenever Acquia releases an update, and you can update contributed modules at any time). Acquia Drupal makes a great starting point.

    There’s also Acquia’s Drupal Commons, which includes many more modules (including some unique to Drupal Commons) designed to work together to make a powerful social networking site.

    Other profiles out there include Drupal for Churches, etc. etc. etc.

98. I’ve enjoyed reading the article and the comments. Thanks for creating it and enabling the discussion.

    We recently gave our main website a “face lift”, with a professional redesign, and built on top of Drupal 6 (on the Pressflow.org derivative, actually). The design team consisted of a website design and graphics expert, and an expert PHP and website developer. I enjoyed learning from seeing how these Drupal experts customized and modified the Pressflow/Drupal core and add-on modules.

    They built their prototype in two weeks using a MAMP on the developer’s laptop. That was nice. We used SVN repositories to share and sync their changes with our development server. Their working directory was the the development site, and our working directory was our synchronized development site. Our production site gets synchronized with other tools, but only manually, after QA testing on the dev system.

    I was also surprised to see how something as simple as turning off a sidebar for a single page, required bypassing the extensive Drupal admin pages, to go to the file system, to copy an existing generic template PHP file, modify it (), and then rename it according to the target page’s path. So, I guess the rule is: use the Drupal admin pages for everything — except turning off a navbar?

    Over the last ten years, our website went from a Dreamweaver-based design to a MovableType design to a RapidWeaver design, to finally the Pressflow/Drupal-based design.

    One of the principal reasons for going to Drupal, besides the evangelization by the webdesigner team, was the relative easy by which our management and marketing teams — non-technical — can make content changes.

    Although our Drupal-site is relatively modest, it is also intricate and complex because of several back-end integrations. So, it is ironic that the management and marketing team feel comfortable only making text changes. Anything more complex than that, like creating a new page, with a new URL, or a menubar change, or a new image for the carousel, and they “assign” the work to our IT team. Even though all the above kinds of content changes are “easily” accomplished through the Drupal admin interface, the primary users still choose to not do it.

    I believe the biggest problem with Drupal is the lack of packaging and staging. We have created our own protocol: for small, mostly textual changes, we clone the pages needing changes, and then prototyping our changes on the new-and-as-yet-orphaned pages. Once these orphaned, testing pages are confirmed, then we copy or rename them as the primary page.

    But this doesn’t work for larger change sets, and since Drupal does not have a good way to manage sets of co-dependent changes, we have setup another Drupal dev site, connected to a dev-db instance. But this leads to the 2nd lack: without a proper packaging, export, and then import of all or specific changes, this doesn’t really help us update the live site with lots of confidence.

    I have built a simple, sample app with django, and — as a developer — prefer django for website and app building over using MT or Drupal.

    I have also built a Rails models for our custom “legacy” database, and built a lot of ruby tools on top of that model to use and manage our DB content. I really enjoyed the ruby dev work a lot — more so than the python work. In general, I prefer programming in ruby over doing so in python. The richness of ruby’s intrinsic classes and methods makes me more productive.

    #1 python complaint: why isn’t assignment an expression? There have been so many times I wanted to write: if result = some_function(some_args) then: or while line = input("next"):

    I don’t think I would want to build an entire CMS site using django or Rails, but neither would I want to build a complex website-as-an-application using Drupal. The time-to-market is faster when you build to modest requirements with a framework like django or Rails, and then iterate and grow as needed. This is the lean, agile way. But, getting up a blog site “with benefits”, using a CMS like Drupal is certainly much easier than building it from the ground up with django. This is the fast, easy way.

    I agree with you (shacker) about the validity of comparing frameworks with CMSes (“apples to oranges”), but I don’t think your comparison was as clear as it might have been. Another way to put the comparison might be with what I call a “delta analysis”. What are the differences between apps built with either tool?

    Let’s take the requirements of building a newspaper website: rapidly changing content; optional user registrations; scalable sourcing and programmable placement of multiple RSS feed content; subscription services; frequent advertising updates and rotation; easy to occasionally re-theme (i.e., seasonal colors, etc.). These are common requirements for most “newsy” kind of websites.

    If I were to build this in Drupal, I would only need to do a modest amount of work, pulling in this module or that plugin, to meet most if not all of the requirements. On the other hand, if I were to build this in django, I’d have to do a lot of module searching, forum trolling, probably a bunch of custom integration work, and then possibly my own development to meet even half of the requirements. It’s not that django cannot manage the requirements — its that the path towards addressing all of the requirements is not well documented and certainly unclear.

    As a developer, I would find it easier to incrementally add things to a django site, or to alter its current appearance, or function. Whereas in Drupal, modifying core behavior, or extending it is considerably more challenging even for expert PHP developers. As you (shacker) wrote earlier, the developer must have considerable contextual knowledge to be able to alter or extend Drupal’s core functions (or any of Drupals plugins, for that matter).

    As a manager of technology in general, and maintenance, specifically, my final opinion is this: although Drupal is faster to market with more features with less development work, with all other things being equal, Drupal is a more complex installation and, in my opinion, more fragile than a comparable, django-based website. If you are building for the long-term, then build incrementally with django. If you are in a hurry, and want a lot of plugin-able features now, and no development work, then go with Drupal.

    But, the consequence of the Drupal/django choice is this: the cost of maintenance on a Drupal site will, in general, exceed that of a django-based site, because the skill set of Drupal site maintenance is more specialized than the skill set of knowing django, python, and relatively simple python programming and html template development.

99. Alan, thanks for the thoughts. Can’t respond to everything, but two points:

    See the official Python docs, which explicitly address why you can’t use assignment as an expression – it’s intentional and prevents mistakes.

    As for:

    Let’s take the requirements of building a newspaper website: rapidly changing content; optional user registrations; scalable sourcing and programmable placement of multiple RSS feed content; subscription services; frequent advertising updates and rotation; easy to occasionally re-theme (i.e., seasonal colors, etc.). These are common requirements for most “newsy” kind of websites.

    Remember that Django was built originally and primarily for newspaper sites – it evolved out of the newspaper industry. So newsy needs are its speciality. Almost everything on your list there is built into Django core (it’s trivial to add RSS feeds for any type of content). Django’s fantastic templating system makes things like “seasonal colors or design changes” completely trivial. Advertising should always be handled by a dedicated (and external) system – it’s never a good idea to build ad serving directly into a CMS. Dealing with rapidly changing content is one of the things Django is all about – a common scenario is 1) Journalist has an idea for a special feature that requires new data structures; 2) The journalist or the web dev defines the data model (which is easy and quick); 3) The Django admin now automatically reflects the new data model and provides an elegant CRUD interface for entering data; 4) The developer works on the display side for that data while the journalist continues with data entry and story writing. These are the kinds of reasons why Django is so popular in the journalism world. So I’m really not sure what you’re trying to say here!

100. Thanks for the feedback. I will spend some more time with django to better learn more of its features.

     I will add this observation about Drupal: Drupal hides lots of its interdependencies while it seems that django makes them more obvious. This means that when the sysadmin or web developer want to make non-trivial changes, the consequences are often more clear with a django-based site than with a Drupal-based one.

     From a management point of view, being able to predict the costs of a proposed, non-trivial change appears to be easier with django than with Drupal precisely because Drupal hides much of its interdependencies.

     Some web developers get around this problem by deploying a “clone” Drupal site for the sub-site, using a completely separate database for content and user accounts. While this makes sub-website deployment more predictable, easier to estimate for time and effort, easier to deploy with little or no risk to the existing Drupal site, the downstream consequence is that it increases the cost of management for the system managers by having to manage multiple databases, and, even worse, multiple sets of user accounts. For small websites, this cloning does not have much real cost in extra time and work, but for larger sites, with many distinct sub-sites, the aggregate cost can be significant.

     Unfortunately, like the plumbing in your home, system administration costs are often overlooked until they are overloaded at which point it becomes a crisis.

     Thanks again for the interesting article and comments.

101. I was going to refrain from saying too much in regard to your response about expressive assignments, because this thread is mostly about Drupal vs. Django, but underneath that comparison is an implicit comparison of PHP and Python, being the languages by which these website “construction kits” are extended by the developer. (Drupal is PHP-based, and Django is python-based)

     See the official Python docs, which explicitly address why you can’t use assignment as an expression – it’s intentional and prevents mistakes.

     Of course, I am aware of this argument, and find it specious.

     For those of you who are not familiar with the argument and too busy to follow shacker’s link from his previous comment, the basic idea is that you should not make assignments (‘=’) on an if or while statement because someone might have mistakenly meant to write ‘==’. It has other consequences, too.

     Depriving good programmers of a more expressive language in order to prevent bad programmers from hurting themselves is silly, and limits productivity for everyone. It forces all programmers (good and bad) to develop and use colloquialisms to represent the idea that would have been represented by the more expressive language. Suggesting that iterators be used in place of these colloquialisms or more obvious expressive assignments is proof that protecting us from bad programmers costs us all more work.

     It just occurred to me: doesn’t this sound like socialism? Making everyone pay for the mistakes of the few?

102. I don’t want to wade into specifics on this, but will just say that all languages have quirks and annoyances. In the big picture though, Python is just about the most compact/efficient language you’ll find – in most cases you can do more with fewer lines of code, despite exceptions like this one. And due to required indentation, the guarantee of always having code well formatted means it’s generally easier for developers to understand each other’s work. Language choice is a religious thing, but for the most part, once people get into Python they don’t want to go back (I for one feel real pain every time I have to go back to working on a PHP app).

103. Scott, we are in agreement about Python being compact and efficient. Where we disagree is with its ordering: for me, it’s #2.

     I’ll report back after I have built a non-trivial website with django. I like the idea of giving others in the position of having to make an informed decision the benefit of experience.

     Thanks again.

104. To contribute more interestingly on the issue of language choice, here is a classic article by Paul Graham on “Succinctness Is Power”

105. Great article. I’ve been working primarily with WordPress for a while now, but am about to start building a site that I don’t think really fits the WordPress model very well, and was toying around with the idea of using Django or Drupal. One of my biggest concerns is that most web developers know PHP, so when I’m gone, if someone needs to maintain the site, they will be more likely to be able to learn just a CMS/Framework than having to learn a CMS/Framework + a new programming language and hosting stack.

106. Really great article, thanks a lot for the author! But reading your “Community Resources” part, one question rise in my head. Why does Django doesn’t have any marketplace for selling/distribution templates and additional modules?? I mean web-portal like http://www.snowcovered.com for DNN-world or something like that. I would like to buy some modules to install to my web-site, but I can’t find any. Why??

107. Pavel – You can’t download templates/themes/skins for Django because it’s a framework, not a CMS. No collection of HTML+CSS could possibly know anything about the object or variable names that are sent to it. You can use any HTML+CSS you like – there are thousands of open source designs out there ripe for the taking, or feel free to design your own. It’s not that hard to convert WordPress or Drupal designs to Django – the world is your oyster.

     As for “modules,” the closest equivalent in Django are re-usable apps, and there are hundreds if not thousands of them out there free, ready to integrate into your site.

108. Actually sorry for probably stupid questions, but as I’m not confident with Django technology… How easy can those mentioned above re-usable apps be integrated with my site? I mean can I do it just myself without knowing any special programmer’s tricks after I download app? And as it is open-source, does those apps really well designed and work proper way? I ask because, returning back to DNN world(I have some experience with it) if I bought any app it is well supported and without bugs. Just because it is commercial. And as I know, there is no commercial apps out there for Django platform (probably I’m wrong with this, but I really do not understand why it is so). I’m hesitating because I try to choose right platform for my site now and I want it to be somehow scalable and flexible in future if I want to add some extra-features to it.

     Thanks again. Very appreciate your answer!

109. Pavel – First, you need to be clear that Django is a platform for programmers. Unlike Drupal or WordPress, where you can realistically deploy sites with little or no programming, this is not true of Django. It’s a development platform for developers who are sick of badly designed platforms that get in their way. So the development process is way more pleasant than it with Drupal, but you’re going to need to roll up your sleeves to integrate re-usable apps.

     As for their quality… they vary of course – each developer is different. In my experience, the most frustrating aspect of them is that documentation for re-usable apps is often written for hardcore programmers, not part-time developers without a computer science background. That said, it’s usually possible to get them up and running by reading the docs as best you can, looking for bundled example apps, and searching the net.

     As for why no commercial apps? There are a few available, but for the most part, this is a community of open-source-minded developers. We all benefit from one another’s contributions, and we try to give back however we can.

110. Thanks a lot for your wide answer Scott! Now it is everything clear for me about the platform.

     BR, Pavel

111. I’ve seen several Drupal developers claim that a strong point for Drupal is that you can develop a complex site without having to write much/any code, or that non-technical users can maintain the site by themselves after it’s been developers (who don’t exist of course, since you don’t need them with Drupal …). Oh, really? I’d love to see a single quality site built on Drupal where no custom code was written. Just one single example will do …

     …That’s right, you couldn’t find one, because it’s bullshit. Of course you have to write code to do anything serious with Drupal, just like you do with Django. That’s why people have to hire Drupal coders to make their websites instead of just installing it themselves. There’s nothing wrong with coding, of course, but what sucks about coding with Drupal is that you have to do it by trying to hack around a poorly designed, bloated CMS/framework hybrid … and then get the pleasure of having it all break when the next incompatible Drupal upgrade comes out.

     Anyhow, rant complete. Overall, I think this article and the discussion to be very informative and engaging. Thanks to everyone that contributed something other than whining and angry rhetoric!

112. Thanks so much for publishing this article, cultivating a meaningful dialogue in the comments, and periodically updating the main content based on valuable reader feedback.

     This post has evolved in quite a useful resource for the semi-technical manager finding themselves in a position needing to compare apples to oranges and feeling comfortable knowing it’s all fruit.

     Drupal seems like a valid path for cookie-cutter websites and/or for rapidly prototyping community features without a heavy programming investment to prove the market/user acceptance.

     Django seems like a valid path for advanced web applications and/or iterative development of community features where you have long-term commitment to a flexible roadmap.

113. I was trying to get a general idea of Django and read your article as well as some comments above. I have a strong OOP and MVC background, also have written a CMS in Java before. I don’t know Django much, so I won’t comment on that part, but I know Drupal well, and my experience is: First of all, learning Drupal was easy and quick for me, with my Computer Science background, a lot of things in Drupal just make sense, because most of things are just computer science logic and decision makings. Second, although Drupal is not in written in OOP fashion, Drupal as whole is Object-Oriented; In other words, if you could consider Drupal as a new language, then it’s an Object-Oriented language. Furthermore, I would consider Drupal as a lower level framework, then I can write a new CMS following MVC patterns.

114. For me working with Django was way easier than Drupal. Django is much leaner and flexible. On the contrary I found Drupal to be really slow and bulky. The MVC structure was another gravitating point towards Django.

115. Everyone should relax, I found the solution to all your problems. :-)

     https://github.com/joomla

116. @Gary Brooks, Sorry dude wrong forum. Joomla is in the unserious category.

117. I’ve used Drupal from the 5.x version five years ago. I’m little tired of things like hooks and drupal module weights, but first of all I’m tired of PHP.

     So I try Django for a couple of projects: I’ve only scratched the surface, but I write less code, and I write it better than a custom set of Drupal modules. The Django community is skilful, the documentation is well written and there are some big “libraries” like django-tastypie that are well documented too.

     Well, I start to like Python. I suggest tired Drupal / PHP developers to give a try to Django AND Python. It’s a refreshing experience.

118. I see the author doesn’t know well Drupal. Drupal is:
     Drupal = Django + CMS = Django CMS
     Drupal is not ONLY cms but Drupal is framework also, since the framework name of Drupal is “Drupal” too this make yourself confuse.
     That is why Drupal Framework can be replace by Django if you like, but Drupal 8 choose Symfony, to make it clear:
     Drupal 7 = Drupal Framework + CMS
     Drupal 8 = Symfony Framework + CMS.

     PHP and Phyton is almost same like VB vs Delphi vs C++. Is there anything that Phyton can do but PHP can’t? Nothing, both can achieve same goal!

119. Wendy, all I can say is, last time I did a Django demo for a Drupal developer, she said “Wow – now I get what you mean. This could be a massive time saver. And it’s just so… clean!”

120. What Python/Django needs is a larger userbase. The amount of development for the likes of Drupal and WordPress is so big that it completely removes the need for even learning any language.

     While I favor Python due to its simple style and syntax, I cannot help but notice the simplicity php coupled with WordPress/Drupal has.

     Problems I see are for Django and Python to take over the world are:
     First and foremost because php is embedded into HTML and allows anyone to add code snippets and edit modify on the fly without the need to install dependencies (Django) on the server.

     And secondly because Django is too crude to just jump into. Even after installation working with the framework is the starting point. There is no direct jump into just editing files with Django/Python code.

     Its a different language yes, its also my preferred language, but it kills me that php is so richly used, which shows based on the magnitude of add-ons for the php based CMS portals out there.

121. You said Drupal was an advanced CMS. Incorrect, it too is a framework.

122. Justin, I explored the gray area between frameworks and CMSs pretty carefully in the post.

123. Which is much scale able?

124. Drupal is a framework.

125. If you think Django competes with Drupal you´ve already lost. Write an article comparing .net with Django instead. Thats more valid.