A key service we provide is helping clients understand – in as much detail as they want – why a particular platform, application, language or other technology is or isn’t the right fit for their needs. In this post we’ll speak to the challenges facing a client asking whether a web-building framework – or an open source CMS – was right for their purposes.
Choosing a platform upon which to build your website is no small task. After all, given that a website is the public ‘face’ of an organization, the platform upon which it is built is of supreme importance. You and your team members will be using that system to produce, create, edit, share, curate, sell, and much, much more.
We have seen platform choices that adversely impacted employee morale (difficult to use) or thwarted production (too disconnected from internal requirements), for example. And we have seen choices that improved an organization’s customer reach, brand visibility, and internal productivity.
The key is to identify a system that is the right fit for an organization’s unique operating requirements, personnel, and resources. But equally important – at least to us at Galaxy Weblinks – is to ensure the client has all of the information it needs to make an informed decision.
We recognize many companies don’t have the time or expertise to master complex technologies – that’s our job. The better able we are to translate that technology into language the customer can understand, the more confident they will be in making a choice or their own, or trusting the one they ask us to make.
Recently we were tasked with helping a client do just this: weigh its options and determine whether further customization and development with its current platform – Django – was the right option, or whether a transition to Drupal made more sense.
Home to one of the largest databases of student enrichment programs on the Web, the client required, among other things:
In this post we’ll look at the analysis we performed for the client – specifically, the differences between the two systems the client asked us to evaluate: Django and Drupal.
For starters it’s important to point out that Drupal is a PHP-powered, out-of-the-box content management system (CMS) similar to other such systems (think WordPress, Joomla, WebGUI, etc.). With Drupal you can set up a website very quickly and relatively easily and without writing a line of code.
Django, on the other hand, is built on a Python-powered framework that offers programmers the raw building blocks with which to build websites.
What this means is that each platforms comes at website development from two fundamentally different approaches: Drupal aims to help users rather quickly and intuitively develop extensible sites that meet just about any mainstream need. Customization is possible so long as you work within its data, template, and URL structures. By contrast, Django lets you build just about anything from scratch – it is the fertile laboratory allowing far more flexible and open-ended development.
It might be easiest to think of Drupal as a CMS application upon which other applications are added. Content types are supported through the use of dynamic modules developed by its large community of supporters (again, comparable to WordPress and similar CMS platforms). This makes it relatively straight-forward to create and augment sites that can be easily managed by its host client.
By contrast, Django is more Wild West, offering a greater degree of flexibility and openness for coders who know what they’re doing and for clients who need more tailored solutions.
In other words, while both platforms are flexible, Drupal’s flexibility is tied to its vast menu of existing possibilities, while Django delivers a powerful framework upon which just about anything can be built.
Like its many PHP-powered counterparts, Drupal offers a theme-based user interface. These theme layers and their authors make Drupal a far more intuitive CMS, particularly for end users who lack much technical sophistication. Drupal also offers native support for responsive frameworks such as Bootstrap. The downside to all of this is that Drupal does not allow for much flexibility with themes – users are more or less confined to these layers or must employ coders with the ability to create custom themes.
Which brings us to Django. As an application framework, Django enables users to create the UI/UX of their dreams, assuming they’ve got the knowhow to make those dreams a reality. There are no restrictions on layout or structure, and the system’s template engine supports the reuse of UI/UX components. Responsiveness can easily be implemented as well.
Until version 7, Drupal was known to have some performance issues, primarily because its architecture requires more processing steps than the more direct approach supported by Django.
So while Drupal makes it relatively easy to extend courtesy its seemingly countless available add-on modules, those same intermediate layers require more processing steps. Django, on the other hand, is far more flexible and allows clients to construct what they want, the way they want. This means database interactions can be executed faster, delivering more flexibile scalability with better performance.
Once we get into search the differences between Drupal and Django really begin to surface. Where Drupal offers a perfectly adequate and stable search function, more advanced options for more complex data structures requires custom development using integration with frameworks like Apache Solr or Elastic Search.
Django comes integrated with Python’s BOTO Cloudsearch, meaning it is extremely fast, scalable, easy to set up, and intuitive. For customers with rich, complex databases like the one in question, Django’s search far outpaced Drupal’s. (It should be noted that Amazon search is in testing for Drupal.)
Here, again, the native architectures of Drupal and Django produce far different outcomes. Drupal employs a more conventional CMS with well-defined themes, modules, and folder structures. Customization is performed at the modular level and through system integration. Entities can be mapped across content types while remaining tied to the same root directory.
The Django framework, by contrast, does not support ad hoc development. Strict design principles are enforced, including:
After delineating between the two systems, we drilled down farther for our client to help them understand the differences in the risks and challenges associated with each system, how best to implement Drupal vs. Django, implementing the two systems, and the time and costs involved.
Thus the client able to see, firsthand, the key differences between these platforms and to understand the rationale used in choosing one platform over the other. Sy Syms, the late clothing retailer, was famed for his expression, “An educated consumer is our best customer.” We could not say it better ourselves.