Before joining Viget I built websites on Drupal for Congressmen and Fortune 500 companies. Those websites were good, and they’re visited by millions of people. I’ve been to Drupal Cons, I’ve been to Drupal meet-ups, and I’ve given presentations on Drupal topics. I wouldn’t have a career as a developer without Drupal, but I wouldn’t recommend Drupal.

“So if not Drupal, then what?”

It depends. Anyone who says they know the solution before they know the problem is lying, wrong, or guessing. At Viget, we can figure out what the best solution is to a problem. That solution may be a static website, a solution with Contentful, a Craft site, a custom-built CMS, or something we haven’t thought of yet. It depends on the project.

We’ve written about this before. We have come up with reasons to go off-the-shelf or to go custom-built. We have compared off-the-shelf CMS’s and we wrote The Viget Book of CMS.

After six years of working on Drupal, I decided to look at the alternatives. I haven’t found a reason to use Drupal since.

“We need to talk about Drupal”

Drupal is not bad. You can find plenty of arguments out there about how terrible Drupal is — that’s easy — but it’s not true. Drupal isn’t bad, Drupal is good. It’s good enough to make a site and get your business going. Drupal modules can be easily installed. Drupal hosting companies will make it easy to get set up, and help you run updates.

I don’t want to dismiss Drupal outright. Drupal can be a good tool, but I want better tools. I left Drupal behind to build better sites, using the best tools. I came to Viget because our standards are higher than any place I’ve ever worked. We want to deliver the ideal solution, and we obsess over quality. If Drupal is ever the best solution for your project we will tell you, because we will want to use it.

I believe Drupal sometimes gets picked by default, and I want to change that.

“Come for the software, stay for the community”

Drupal’s unofficial tag line is “Come for the software, stay for the community.” Maybe you’ve heard this at a meet-up, at DrupalCon, or at one of the many Drupal camps, and it’s true. They are a kind, funny, inclusive, and determined bunch. This isn’t exclusive to the Drupal community though, and we should see “the community” for what it is: marketing. A kind, funny, inclusive, and determined community will attract tons of people of all skill levels. There are great developers who contribute to Drupal, but there are many more site builders who do not contribute any code. A large community, even a nice one, doesn’t equate a highly-skilled one.

Like any community, you will find differing opinions on “best practices.” Saying you follow Drupal “best practices” is akin to saying you have the Best Burger in DC (or anywhere for that matter). Knowing Drupal, and knowing how other agencies use Drupal, are two different things.

I’ve taken over Drupal websites built by other agencies before, and I rarely encountered what I considered “best practices.” Sure, it was Drupal, but I couldn’t jump right in. I had to research every module that had been chosen and wonder why it was chosen over what I would have recommended. I had to dig through custom module code. Sometimes it was well written code, and sometimes not. Taking over these sites wasn’t seamless.

Recently I’ve taken over some Craft projects. Even without any prior Craft experience I was able to get up and running far quicker than on Drupal projects. I didn’t need to be part of a Craft community to become productive in a Craft project, I just had to read their documentation, and since the system is more intuitive everything was easier.

“Look at all these modules, so many modules!”

Drupal’s functionality can be extended through modules, simple add-ons that the Drupal community has built for everything from better commenting to integrations with third party tools like Salesforce. It’s worth noting that Drupal didn’t invent modules, nor is it the only platform that has a concept like modules. Every CMS and most programming languages have something similar to modules.

Modules are touted as time saving, and they can be. If you are willing to settle for what the module does and nothing more, then they are time savers. However, the architecture of some modules make them hard to extend or modify. These modifications introduce possible problems to the update flow. The promise of modules is oversold. In practice, every module introduces a point of failure while running updates. This isn’t a Drupal thing, it’s a software thing. Drupal doesn’t solve this problem in any clever way.

Modules and the modular architecture of Drupal are good. They’ve made serious improvements to the way modules get added in Drupal 8. However, Drupal is an open source project with modules being developed by individuals with limited time. This means that sometimes the module you need may not be ready for primetime, may not be well maintained, or may not exist at all.

“Drupal ain’t easy”

Drupal is filled with drupalisms, the quirks of the system that don’t translate to other platforms. Every language or system has its quirks but Drupal is defined by them. The big tent of Drupal developers have internalized these quirks, but the much bigger tent of web developers is usually baffled by them. This means that choosing Drupal ultimately limits the pool of talent you can pick from. Good Drupal developers will be able to pick up any web project that use similar technologies, but the reverse isn’t necessarily true. Drupal is not particularly approachable for developers. That's why every aspiring Drupal developer is shown this: