Drupal 8 and Backdrop CMS – A Brief Comparison
Putting the controversy about Backdrop aside, let’s get straight into a comparison of the features. Keep in mind, however, I’m using the term “features” here a bit loosely. That’s because I also want to talk about how Backdrop is managed as well as other differences between the two projects. This list is not exhaustive. It just has some of the things that seem to me the most significant or interesting.
I know many will squirm uncomfortably when I say this, but the target market for Drupal 8 is large enterprises. By contrast, the target for Backdrop is small to medium size businesses and non-profits – really the original market of the Drupal project. As we go through this list, you’ll see how this targeting plays out in some of the decisions the two projects have made.
This has been widely touted as the killer feature of Drupal 8. If you’ve dreamed of having all the cool configuration management features in D8 available for Drupal 7, then Backdrop may be tempting because that is essentially what it offers. Instead of using YAML files to store configuration data, however, Backdrop uses JSON. Otherwise, it’s pretty much the same.
Another one of the major additions to Drupal 8 is the Twig template engine. This is a big plus for many front-end folks and it’s something that is not available in Backdrop at this time – and I’m not sure I would look for it in thenear future. Backdrop currently uses the Drupal 7 PHPTemplate theme engine.
At this writing, Backdrop doesn’t have a responsive image solution. I asked Nate about this and he’s not a fan of the Picture module approach (he favors using srcset, something that may possibly be added in versions 1.1 or 1.2 of Backdrop), so if that is something you require, it will need to be added as either a custom or contributed module.
Speaking of contrib, most of you reading this will be familiar with Drupal’s massive collection of contributed modules. The contributed modules for Backdrop CMS will be hosted on GitHub and managed similar to how the jQuery project organizes its plugin registry. I don’t think there have been any ports as of yet (all the energy is going to the 1.0.0 release), so this is pending.
Some of you may have heard that Drupal 7 modules will be compatible with Backdrop. This isn’t true, primarily due to modules needing to be rewritten to support configuration management. Porting a Drupal 7 module should be fairly straightforward, however. Instead of storing config in the variables table, it needs to be in JSON files. Here’s a video that will help get you started.
As a quick aside, having Backdrop (and eventually the contrib modules) hosted on GitHub seems like it will be a more familiar and friendly environment for potential project contributors.
The “do-ocracy” that is the Drupal project has been much discussed lately. Nate has organized the Backdrop CMS project along the same lines as the Project Management Committee of the Apache project. That was very wise in my opinion. It bodes well for the project.
Another really nice thing in Drupal 8 is the inclusion of a default WYSIWYG editor. Love them or hate them, virtually every client wants one, so now with D8 you won’t have to add one yourself for every project. As of version 1.0.0, Backdrop doesn’t have this functionality, but look for it in version 1.1 or 1.2.
I remember Nate saying something about it being ironic that Backdrop was launching both without Twig or a WYSIWYG since he and Backdrop co-founder Jen Lampton had been instrumental in bringing those to Drupal 8.
I suppose I should mention that Backdrop minor versions – from 1.0 to 1.1, for example – will occur regularly at an interval of about three or four months. So for the features mentioned that may be in version 1.1 or 1.2, it means they can be expected in either late spring or late summer.
Panels and Views
How about Panels and Views in core? Yeah, I like it! And that’s what you get with Backdrop. Drupal 8 provides Views in core, but not Panels. It may be a while before Panels is ready for D8, but it may also be a while before D8 is ready, so I guess that’s not a problem.
System Requirements and Backwards Compatibility
It may seem odd to group these two, but this is one point where the intended audiences (enterprise vs small organizations) are put into stark contrast. For example, Backdrop is intentionally friendly to inexpensive shared hosting (e.g. GoDaddy). Drupal 8, by contrast, is almost certainly going to use more server resources than Drupal 7, potentially causing issues for those on shared hosting plans.
For large organizations, the cost of hosting is not a big deal, but for some small organizations, it can be. So a solution architected to work well with limited resources may be attractive and also serves to highlight the different approaches between the two projects.
With backwards compatibility, we see the same philosophical divergence. Drupal has never focused much on backwards compatibility, making it a pain in the ass (and often expensive) to upgrade across major versions. The benefit of that approach is that Drupal has been able to innovate without being constrained by past decisions.
Backdrop, however, places a lot of value on carefully managing change so that existing sites can be upgraded affordably. I would recommend looking atBackdrop’s philosophy, because it’s there where you really find the motivations for the project and how it differs (and will differ more in the future) from the Drupal project. From system requirements, to upgrade path, to reaching out to hear voices not found in the issue queue, Backdrop CMS is consistently friendly to the needs of the little guy.
Again, this isn’t a comprehensive list of all the features or differences between the two systems. There is an issue on GitHub that might be of some help in learning more as well as this Drupal 8 feature list.
To me, these two projects don’t compete with one another. Sure, some enterprises may use Backdrop and many small organizations may use Drupal 8. But really, the changes in Drupal 8 are a move toward the enterprise and the talk around Drupal 8 has reinforced that message. Having an alternative for small organizations on a budget and with a need to preserve software investments isn’t a bad thing.