INSIGHTS | February 2, 2019
Drupal Pros and Cons: An In Depth Look
*Check out our recently updated article about the pros and cons of Contentful for similar content.
Here at MCD we have been using Drupal on several projects. As a long time Drupal developer myself, I’ve had the privilege and pain to work on almost every scale of Drupal site. This has allowed MCD some keen insight on when a project is “right” for Drupal and when a more custom solution could be better.
Having said all that, one of the hardest things to deal with when it comes to speaking with clients or bringing on new developers into the Drupal world is their preconceived notions about Drupal. The community at large seems to have some fairly opinionated thoughts on the subject and there are extremes on both ends.
The reason for this polarity is how newcomers perceive the material they read online about Drupal. For instance, most Drupal community members tend to oversell the platform while turning a blind eye to some of its issues. This leads to articles, posts, and Drupal evangelists that champion the software without properly warning the community at large of some of its pitfalls. Obviously this makes sense, as a community wants to put their best foot forward for the public to see. After all, Drupal can only thrive with new developers and organizations that choose to embrace it.
On the flip side, developers or clients that have had a bad experience with Drupal will often talk about how terrible it is and post their horror stories of missed deadlines, spaghetti code, and slow sites on web. Similarly, these cases never tend to talk about the fact that often Drupal wasn’t the best choice for that type of project, or that none of the developers involved we’re aware of some Drupal pitfalls to begin with.
So then what’s the right opinion? Where does Drupal really fall on this spectrum? Hopefully by the end of this article you will be able to formulate your own opinion. In order to do that, lets look at Drupal from all sides.
The Cons of Using Drupal
- Large learning curve
- Major updates can be an effort
- Drupal can consume lot of resources if not tweaked properly (slow)
- For large websites, contributed module compatibility can be an issue
- Doesn’t work well for custom applications
Above is really just a small sample of some of the main criticisms of Drupal, and while more do exist I’ll only speak to these for the sake of time. It’s key to know that a lot of these issues can be overcome, but if ignored you can find yourself in some pretty tight spots.
Drupal’s Large Learning Curve
While learning is fairly subjective, I do believe there is a lot of merit in this complaint. If any of you are familiar with the Drupal world you will undoubtedly have heard of “Drupalisms”. For the uninitiated, “Drupalism” is just a nice way of saying “following Drupal development methods”. Unfortunately just knowing PHP in this case isn’t enough, because a lot of these methods and patterns are buried in pages and pages of API docs. Bringing on a new developer in the Drupal world will almost certainly take time and in some cases money.
Strides have been made in this department with things like The Drupal Core Mentor Program and tons of online workshops and tutorial, but these initiatives can only cut down so much time in the learning process. With the next release of Drupal (drupal 8) there has been a large focus on rebuilding core to bring in more common patterns of PHP like object orientation, leveraging frameworks like Symphony, and up-to-date frontend components to reduce these ”Drupalisms”. The truth is, the time to learn any new technology can mitigated by the effort someone puts into it, and the community that supports it. In Drupals case, the community is one of its strongest assets.
Major Drupal Updates Can Be an Effort
While updating common modules is a snap, many people have knocked Drupal when it comes to updating full versions of the software; for example from Drupal 6 to Drupal 7. A lot of this pain stems from the fact that the Drupal community decided long ago to not support legacy ideologies for the sake of backwards compatibility. The reason for this choice was to insure that every new version of Drupal is able to leverage the latest technologies, which in turn breeds a better overall system.
However for companies looking to stay on the forefront of their respective fields this means added cost when it comes time to update their core to the next version. Similarly on the development side this means contributors must rewrite their modules to ensure compatibility with the next version. Since most modules are written in developer’s free time, this can mean a long wait between releases cycles for lesser known modules.
The criticism is fair, but I would also argue that any open source project is a reflection of the community that works on it. For instance, Drupal aims to be open to as many 3rd party systems as possible and the goal for updating isn’t with just Drupal in mind. That is why considerable time and effort has gone into the Migrate module. This tool allows developers to write their own custom migrations from almost any source into Drupal. While it may take a bit more effort, it means migrating from almost any source into Drupal is a snap; including older version of Drupal.
The bigger question is to decide if Drupal is the right tool for the job and if the project is in a place that it can comfortably rely on open source modules. For instance, if you think you’ll be using a lot of contributed modules then you should prepare for future upgrades in advance. At the least you should familiarize your team with the modules in use to help fix them and contribute back as the project ages. This is the essence of open source!
Drupal Can Consume a Lot of Resources If Not Tweaked Properly
Third on the list deals directly with one of my own personal issues with Drupal. Drupal can be a resource hog, and in most cases you will be spending at least a little time on optimizations, hardware, and caching. The problem is that in order for Drupal to remain so flexible, it has to cover a lot of scenarios. This often means running a lot more code on page load making bloat a common problem.
In practice however, complaints of Drupal’s slow speeds often stem from poorly written contributed third party modules that didn’t put the time into optimizing their own code. I can’t tell you how many times I’ve consulted on a slow Drupal site only to find 1-3 modules causing most of the issues in a site using 40+ contributed plugins.
Having said all that, Drupal does allow for some fairly robust caching methods when combined with tools like Memcache, Redis, and Varnish. While this does mean you will have to spend some time on both your hardware and software configuration, you can still end up with a fairly snappy site. As a rule of thumb I always warn users that are trying to run heavy Drupal sites to shy away from shared hosting. Shared hosts often don’t afford the flexibility needed to run Drupal, nor do they come with a lot of caching built in. There are exceptions to the rule of course, but your mileage may vary.
For Large Websites, Drupal’s Contributed Module Compatibility Can Be an Issue
The last two items on the list are actually related to one another. As a site grows larger in the Drupal space, more often than not the course of action is to pile on more and more contributed modules. All of these modules are hooking into Drupal core and running their own code on top of one another. At some point or another this code may conflict and manifest itself with slow speeds, errors, crashes, or just poor user experience. It’s usually at this point that people start to complain that Drupal can’t be used in large web sites.
Drupal Doesn’t Work Well For Custom Applications
The problem with the previous statement is that complexity doesn’t necessarily mean size. It also doesn’t mean that complex sites can’t use Drupal. The truth is that Drupal scales quite well. It’s also true that fairly complex sites have been built with Drupal. One great example of both is the newly released weather.com. In this site we can see complex functionality, components, widgets, layouts, all within a snappy site that ranks with the most heavily traffics sites on the web.
The real issue at hand here is how the site was built in the first place. If you choose to rely completely on contributed modules with zero refactoring of your own, then over time you going to find yourself in bad place. As much as Drupal attempts to make building a website easy, it still must be tooled to your needs. If you feel like your application is going to be uber specific and laser focused, then I tend to think Drupal isn’t the right choice for you. This is especially true if you find yourself not needing the majority of what Drupal provides in core. At that point you might find yourself better served with a mature framework like Rails, Laravel, or Django.
The Pros of Using Drupal
- Drupal is extensible
- Drupal allows for rapid prototyping
- Drupal security updates are timely and thorough
- Drupal community is huge with support on drupal.org, stackexchange and other websites
- Drupal can scale well
- Drupal can serve as an API of it’s own
While I don’t think its necessary to go over every item on this list, I would like to take the time to highlight some of the important ones.
Drupal is Extensible
To start off, Drupal’s strongest plus is how extensible it is. Out of the box it’s basically a blank slate. From there you define what you want your site to be. Content Types allow relatively novice users to build complex data structures in minutes. This means prototyping an idea in Drupal can result in a huge savings in time. You can have a working prototype within the first few moments and build it all out from there. Whether that means using contributed modules or building out your own, you're free to extend Drupal as you see fit.
Drupal Allows For Rapid Prototyping
This is a fairly important distinction of Drupal and one that needs to be taken into consideration when building your projects. It’s not crazy for some developers to build out a relatively complex site over a short weekend. On several occasions I’ve found myself having an idea on a Thursday, sketching it out on a Friday, and having a working site ready for Monday.
Drupal Security Updates Are Timely and Thorough
All this means nothing if the site isn’t secure. While being open source does lend a project to more attackers, it also means that Drupal security team is working 365 days a year to provide patch and fixes. Turn around for security is fast and if you subscribe to Drupal security email notifications, they can have any large holes patched and deployed the second they are discovered and released.
Drupal Community Is Huge
Perhaps the largest advantage of Durpal is it’s community. As I previously described, Drupal community members are often fanatical about it. The support is extremely strong and each iteration of Drupal brings in even more developers from around the world. On top of this, the enterprise community has seen a huge uptake in Drupal adoption over the last few years. Twitter, Pintrest, Microsoft, Government Agency, etc are all pouring hours and dollars into Drupal. This has gone a long way in securing Drupals future and should be more then enough to show you its worth in the wild.
Drupal Can Scale Well
While we talked about the issues of speed with Drupal, we also know how that can be overcome. As such, Drupal scales very well. I’ve already given examples, but if you’re still searching more examples are out there check out http://www.whitehouse.gov, https://dev.twitter.com/, http://www.economist.com/, http://www.teslamotors.com/, and more.
Drupal Can Serve As an API of It’s Own
My final check box in the pro-Drupal column is actually relates back to how extendable it is. In recent years, the front end world of development has seen a huge surge in tools and tech that have managed to push it to the forefront of modern web development. One of the main proponents of this was the explosion of RestFul web APIs.
Drupal has embraced this idea fully and allows you to extend the software easily to become a full REST API with almost no upfront work. This means your Drupal project can be completely separate from your front-end teams work flow, making Drupals environment 100% portable to almost any other type of platform. If you want to expose your data for an iOS or Android app you can. Moreover with Drupal 8 the Rest server will be built completely into core and available the minute you install.
Wrap it up!
Hopefully this article gives you a bit more insight into Drupal, but also describes how most “cons” are really fixed by research, best practices, and common sense. There is no doubt that improvements can be made in how Drupal is both presented, and performs. However as with many things in development, a lot of these hurdles can be overcome with planning and experience. The biggest takeaway I hope that readers glean from this is how each project needs to exist on its own. Not everything you build should be built in Drupal, but there is more than enough places on the web where it has proven to shine.
Further more, experimenting with many different technologies is what will ultimately make you a better developer, agency, and client. Always make sure you have a deep understanding of the needs of your users first, and then look for the best tool for the job. For feedback, please email me at jalbert@mcdpartners.com