Drupal 8 vs. Backdrop

September 18, 2013 - 7:48am -- John Locke

There's a little controversy in the Drupal world, a fork by Nathan Haug, aka QuickSketch. Last week he tweeted:

#Backdrop needs to exist to preserve the #Drupal community and market. Why it exists and where it’s going at http://backdropcms.org/ — Nathan Haug ( @quicksketch )

I was dragged kicking and screaming into Drupal by my employees -- I thought the architecture sucked, the templating system was stupid compared to Smarty, TemplateToolkit or DTL, it was a bloated memory and performance hog, configuration management was a disaster, simple REST/web services are ridiculously missing, and the lack of any sort of object oriented structure was a real impediment to understanding the code. Yet Drupal got the job done, handled everything we threw at it, quicker than anything else, and I became a convert. Our shop has done all Drupal for the last 5 years.

Drupal 8 pretty much resolves all of these complaints. I'm really excited to see it come about. As long as the community stays behind Drupal 8, I think we'll see a platform poised for even greater success.

As I see it, Backdrop is about preserving the bad parts of Drupal for people who don't want to learn actual programming skills. Users and administrators are never going to notice the difference. Sounds like they're bringing Twig over, so themers won't know the difference either. They're preserving the archaic architecture that makes Drupal so hard to learn for developers, the deployment nightmares for dev-ops, and the resource-intensive loader to keep bogging down performance for everyone. Great plan. Good luck with that!

9/27 Update:

Looks like this post got picked up and discussed with Nate and Jen on the Drupalize.Me Podcast. They had a very diplomatic response (I started with Drupal 5, by the way!), pointed out that I have some of the basic assessments wrong about what's going into Backdrop, that a big focus of their work is on performance where they are already seeing some gains, and that I will probably be happier in Drupal 8, which is fine.

I think Daniel Kudwein (aka Sun) has the best take on this controversy, basically pointing out that it's a communication breakdown.

I also hear lots of people saying "Forks are a good thing", trying to celebrate this and get all kum-bah-yah about the matter, let's all stay friends. Wrong. The ability to fork is a good thing. An actual fork might be a necessary thing, but it's rarely a good thing. Often successful forks make the original project irrelevant, rarely they split off and both versions get established, but pretty much never do forks manage to continue collaborating and helping the other.

Backdrop is not going to be compatible with Drupal 8 -- it's clearly going a different direction. Sooner or later there will be so little in common between the projects there will be nothing to talk about. For us, by far the biggest problem with Drupal is upgrade pain -- the single biggest reason we're losing customers these days is sticker shock at what it takes to upgrade from D5 or D6 to D7. Both D8 and Backdrop are trying to address this problem, in fundamentally different ways. I think D8 is hitching its horse to a platform and architecture that largely solves this problem, while Backdrop is preserving the architecture that promises to lead to more upgrade pain down the road.

But the biggest reason Backdrop sucks is that it means Drupal is losing some very talented developers and long-term contributors.

For more on forks, you can read a post I wrote back in 2006...

Industry: 
Story Type: 

Comments

Submitted by Jakob Perry (not verified) on

Great writeup, it pretty much reflects my views as well. One caveat, I don't believe twig is being ported over, but they're thinking of writing something similar.

Whats worse is that it won't be compatible with Drupal at all, so they're pretty much making a new CMS based on bad industry practices. These were ingenious hacks when PHP 3 was out, but that was over 10 years ago. The idea of turning the clock back is bad.

The FUD that backdrop spreads is toxic to the greater Drupal community and helps re-enforce why external people don't like drupal in the first place. My hope is that instead of people flocking to backdrop, they will learn new programming constructs and become better programmers.

Submitted by Anon (not verified) on

The truth is there have been at least a dozen or more Drupal 'forks' promising all sorts of things but ultimately failing - sans Pressflow, who's performance changes were adopted to a point in Drupal 7.

This is being marketed as a 'new CMS' when it's quite obvious it is Drupal 7 with a different name - in which case, why not just work on D7 core? Otherwise, fragmenting the community and changing the moniker is going to throw confusion into the mix. How can they hope to gain traction with a handful of devs constantly backporting changes for compatibility (from a module standpoint) while improving it to be 'on par with D8' which could never be true at all?

Ultimately, the echoed sentiment is that yes, this is a push-back from a group of people who do not want to use OOP and design patterns to build solutions. Most people who hung with Drupal from 1-6 largely were hobby coder / hackers, and the shift into OOP and structured coding has had somewhat of a Darwin effect on the developer base, survival of the fittest.

In any case, getting a solid base down with Drupal 8 is going to give it the longevity Drupal needs without carrying it from point to point with procedural kludge.

Submitted by David Rothstein (not verified) on

Ultimately, the echoed sentiment is that yes, this is a push-back from a group of people who do not want to use OOP and design patterns to build solutions.

That's incorrect. Backdrop developers have made clear that they are very much not anti-OOP, and in fact Backdrop will likely have more object-oriented code that Drupal 7 (which already uses object-oriented code and principles itself in a number of key subsystems, by the way).

For example, quoting quicksketch in https://github.com/backdrop/backdrop-issues/issues/44 :

"One thing I don't want to introduce is a fear or aversion to OO code. OO makes a lot of sense in many situations, and I think it's inevitable that we'll use a lot of it in Backdrop 1.0 (i.e. the plugins architecture and Views implementation). We're not anti-OO, we're anti-complexity."

Submitted by John Locke on

Thanks for pointing out that discussion. It makes me sad about the fork -- these are great goals, but I still think forking was misguided.

The core work of moving to a real OO framework is a very big win that I think far better achieves these goals, compared to the old Drupal core.

I think there's a lot of merit in the "small core" principle that does seem to have been largely abandoned. Simply yanking out modules that aren't in use on all sites to me seems like enough -- I see they've dropped Forum, Poll, RDF, and several others -- we all would be better off if they made a "small core" branch of Drupal 8 with just the essentials, rather than forking into something entirely new and incompatible -- it's probably far better for those modules to go back to contrib anyway.

Submitted by Brian Vuyk (not verified) on

Drupal 8 pretty much resolves all of these complaints. I'm really excited to see it come about. As long as the community stays behind Drupal 8, I think we'll see a platform poised for even greater success.

I 've actually expanded on this argument today over at http://pingv.com/blog/drupal-8-as-an-intuitive-platform. In short, Drupal 8 is going to be a far more intuitive and approachable platform than Drupal 7 ever was. Drupal 7 is just a muddy mess of procedural spaghetti code...

Totally agree with you. Forking Drupal is a bad idea and come on backdroppers, embracing Symfony components is the smartest move.
Nevertheless, it is not a matter of whether backdrop will stop to exist but just when it will vanish.

Submitted by John_B (not verified) on

"Most people who hung with Drupal from 1-6 largely were hobby coder / hackers, and the shift into OOP and structured coding has had somewhat of a Darwin effect on the developer base, survival of the fittest."

Clearly the changes are good for the developers and owners of the tiny by important minority of Drupal sites where there is enough funding for professional developers. The majority of Drupal sites out there were made by hobbyists (or professionals in the way small WP 'web designers' are professional) who picked Drupal over Wordpress, and who find maintenance a headache (see the d.o. support forums to confirm this). This mass of users. who are the key to Drupal's wide adoption, but who will never make Drupal shops rich, are still being recruited by Drupal Gardens. I fear when their D8 sites 'blow up' they will be even further out of the depth than they were with D6. I hope I am wrong.

Drupal has already followed the money and taken the enterprise route. In a way the Backdrop fork is too late. The one thing that remains is to more frank in presenting Drupal as an OS enterprise solution which great at what it does, but is not a good choice for small site builders.

Submitted by John Locke on

> The majority of Drupal sites out there were made by hobbyists (or professionals in the way small WP 'web designers' are professional) who picked Drupal over Wordpress, and who find maintenance a headache ... I fear when their D8 sites 'blow up' they will be even further out of the depth than they were with D6.
>
> ... The one thing that remains is to more frank in presenting Drupal as an OS enterprise solution which great at what it does, but is not a good choice for small site builders.

I would argue the complete opposite. Drupal has been quite complex for a very long time, leading to a huge number of craptastic sites that don't work well, give Drupal a bad reputation, make site owners flee to other platforms. And this is largely because even really good programmers unfamiliar with Drupal re-implement things Drupal already does but they don't know about it, or these "hobbyists" can't come close to getting right.

A huge amount of our work is rescuing projects that other developers were unable to complete, had screwed up so badly they walked away.

Like any other major release, it's going to take quite a while for the contrib ecosystem to catch up, and it is so drastically different this time that site builders are going to need to learn a lot of new tricks. But when I see stories like this one, advocating putting SQL in the theme, it makes me shudder -- that's the crappy stuff we see all over inherited sites, and I think Twig can do a lot to discourage that.

You are right, this fork is too late -- the vast majority of the amateurs have already fled to WordPress. That's a good thing -- let Word Press own the low end of the market, because then they get the crap reputation. Drupal is already a much better solution, and with Drupal 8, it's going to be far more approachable to new developers than it ever has been before.

I'm continuing to be puzzled by the idea that small, non-enterprise sites and those who create them will not be well served by Drupal 8 because the "hobbyists" and individual professionals (as opposed to shops serving enterprise) won't be able to hack code as easily as in previous versions.

Small sites and individual web professionals don't need custom code to build complex, dynamic websites using Drupal 7. From what I hear, Drupal 8 will make it even easier to build such sites without coding.

So I would ask such hobbyists and individual professionals worried about Drupal 8: what is the service you provide your clients? Is the ultimate goal to create a great website or is it to write code?

Consider also: how likely is it for a Drupal 8 (or 7) site without any custom code to "blow up" in the way you fear? (I've done three site rescues in my career: none of them would have been necessary if the developer had refrained from custom coding and used core/contrib modules instead. In all cases, the solution was to rip out the custom code and properly implement standard modules.)

Small sites and individual web professionals don't need custom code to build complex, dynamic websites using Drupal 7.

Sorry, but you're flat-out wrong here. Have you EVER worked on a Drupal site, no matter how big or small, where you NEVER had to write ANY custom code? Never modified a theme's template.php file?

I have worked on many Drupal sites and frankly, this kind of use case simply doesn't exist.

And there's no excuse for poor coding, but what happens when these low-level programmers that you're leaving in the dust need help? Where do they go? The forums? IRC? Hire another experienced Drupaler?

Submitted by John_B (not verified) on

I largely agree with this. I also make a living mainly from looking after Drupal sites which have pretty much gone wrong, albeit as freelance support. It is partly the clients' fault for picking the cheap / offshoring / confident-sounding Drupal 'experts' over the well-known but prohibitively expensive Drupal shops.

So with Drupal 8 it could go two ways: the client base pf the type who lack the funding to make and maintain a Drupal site well will flee to a more suitable platform (in which case the 'professionalisation' of D8 will do them a favour). Or the changes to D8 will mean they get burned even more badly by the developers who know Drupal less well than they pretend or believe, and who get business but bid unrealistically low.

But I feel sorry for the owners of 'craptastic' sites (this week a client told me his Drupal site was like a bad marriage), and if Drupal core does not help out the people who have invested and feel locked in to a bad Drupal site, and who could not afford a Wordpress migration (for example), maybe Backdrop will.

Submitted by John Locke on

So with Drupal 8 it could go two ways: the client base pf the type who lack the funding to make and maintain a Drupal site well will flee to a more suitable platform (in which case the 'professionalisation' of D8 will do them a favour). Or the changes to D8 will mean they get burned even more badly by the developers who know Drupal less well than they pretend or believe, and who get business but bid unrealistically low.

Hmm. Again, I disagree... There's always going to be the low end of the "developer" pool, and lots of ways to get a terrible site built. I think one of the challenges Drupal has always had was how different it was than most of the professional software world. Which means even really good developers who are unfamiliar with Drupal are likely to have very bad results their first few times around.

With Drupal 8, I think we're going to see a lot more competition at the high end, it will make for an easier entry into the Drupal world for other quality shops and developers. So I'm a little concerned about D8 introducing more competition, which could eventually start driving prices down for end customers, and perhaps start eating into my rates. That's very good for Drupal adoption.

Backdrop, to me, seems like will only be a good solution for current Drupal developers who are resistant to change. And yet it still involves some pretty major change, so again I don't see this as viable. If they're sticking with the old patterns, they're keeping their huge technical barriers to entry for new developers. I really think D8 is going to be a lot easier to pick up for people not already indoctrinated in Drupalisms.

... if Drupal core does not help out the people who have invested and feel locked in to a bad Drupal site, and who could not afford a Wordpress migration (for example), maybe Backdrop will.

Now there's a different issue: migration (and upgrades). And while Backdrop has a very laudable stated goal of making the site much more forward-compatible, much less painful major upgrades, it's questionable how well they can pull that goal off -- one of the technical reasons for moving Drupal to the Symfony framework was to provide more stable, less intrusive upgrades going forward. So in other words, I think D8 has a much better chance of fulfilling Backdrop's goals than Backdrop does.

Submitted by Scothiam (not verified) on

I've always felt that I would move on from Drupal once I was ready... Thought Drupal was for and suited to that crowd. Very curious as to why people that fully know what they are doing are hoping to change that (what has made Drupal as successful as it is (?)) and not just use something else?

Question: do your employees that "dragged kicking and screaming into Drupal" share your enthusiasm for the changes in D8? Are they excited about Backdrop?

Cheeky-ness aside, I've heard frowing talks of 'exit straties' since D7... I fully agree that Backdrop is too late. Before I knew what it was, I was hoping it might be to D7 or D8 what Pressflow was to D6 :(

Submitted by John Locke on

I don't know of any of my developers who are excited about Backdrop. The one who made the biggest impact converting us to Drupal now works for Acquia, and she started dabbling in Symfony while she worked here (hi, @ksenzee !) I've had several developers on board since who have complained heavily about how backwards Drupal is in certain areas, and how much easier it would be if it just had an object-oriented framework.

It's not Drupal's crappy core architecture that has made it successful -- it's a can-do spirit among its developers, a willingness to dive in and figure things out.

And it's not like OO doesn't exist in Drupal -- Views has been OO for a very long time, and there are lots of Drupal developers extending Views quite successfully.

Submitted by Scothiam (not verified) on

Agreed, those with a can-do attitude will get up and running and figure it out, Drupal 6, 7, or 8. I suppose the whole 'exit strategy' talk is a separate topic.
Thanks for the reply, I appreciate the insight.

I disagree with this, for the simple reason that these are guys who know Drupal well enough to realize that NEW Drupal 7 and probably Drupal 6 sites are being created and it will be impractical to upgrade them to Drupal 8 when it comes out.
I see many developers having to decide whether it will be a good idea to create new Drupal 6 or 7 sites or abandon Drupal altogether. The fact is Drupal 8 is going to cause the problems Drupal 7 created for Drupal 6, which is basically mess up development of third party modules, and waste all the time invested in mastering Drupal 6 and 7. Once bitten twice shy.

As experienced Drupal 7 developers get to know BackdropCMS better they will decide whether to stick with their Drupal 7 investments and skills or abandon Drupal 7 altogether. Something like this may determine whether the Drupal community stays together or breaks up and Drupal is more of a community than a product.

My Drupal skills are not that great but It already makes me feel better about creating new Drupal 7 sites.

Take a look at the Services module https://drupal.org/project/services. It has been discontinued for Drupal 6 and what is worse is that the links required for anyone who wants to see what they can do to fix it were simply removed from the main page. I had to Google a lot to see what was going on and what I could do if I wanted to continue it using. Although some patches were tendered the test suite required to verify it for Drupal 6 was not good enough and no one had the time to take it up as most efforts are going into Drupal 8. Given how REST is so important you need to ask how much one can rely on a team who can discontinue such a critical module. Issues like these don't inspire confidence.

Have you noticed that it is now that Drupal.org is switching to Drupal 7, 3 years after its release ? https://drupal.org/node/2085755.
It is irrelevant how good Drupal 8 is or might turn out to be.

Frankly if anyone is at fault here it is Drupal core contributors - that means Dries and Co - neglecting the concerns of those who need to preserve their D6 and D7 investments. I feel that people would be happier to learn Drupal 8 and contribute to it if they were convinced that their D6 and D7 investments wouldn't go to waste. They already did this once and got burned. They can't be expected to do it again.

Submitted by John Locke on

@Frank thanks for persisting through the are you a human thingy! It is the most effective thing I've found for stopping spam, though -- with Mollom we were getting batches of 50 - 100 spams through every day, while at the peak it was blocking ~7000 spams per day!?! AYAH has it down to maybe 3 or 4 a day.

Very good points about the cost of upgrades, and Services module. I totally agree that Services is necessary for a lot of integration work, mobile app support, and more -- it's a shame nobody is stepping up to maintain it in D6 (but understandable). That is going into core in D8, though, so that's another point in D8's favor.

The cost of upgrades is a major, major problem with Drupal these days, and D7 -> D8 is looking to be as big or bigger a jump as D6 -> D7. I'm actually drafting up a post about the cost of ownership compared to value in Drupal, as compared to other platforms. This has long been perhaps the biggest tangible cost to running a Drupal site -- the cost of upgrades. I keep hoping it's going to get better, but if anything it's getting worse, at least up to D8.

Once Drupal is a Symfony app, will future upgrades be less painful? Time will tell. But I'm guessing that with much better object-orientation, future upgrades can be a lot easier -- if well implemented, modules can simply inherit the updated base objects with potentially no changes whatsoever.

So I guess I take your points as the reason why Backdrop is a bad idea -- the very issues you raise with Drupal are what I hope Drupal 8 will largely resolve -- and Backdrop is likely to perpetuate.

Submitted by Anton (not verified) on

As a programmer I have university degree. And I want to warn another programmers about drupal.
I have been working with Drupal for 4 last years.
Working as site builder and programmer.
And I want to warn new programmers about what is not said.
Drupal is not for programmer's use.
It is for web masters' use.
You can think like this: "I will learn how to create the modules and I will be creating good web sites for money".
But it is not like this.
The customers don't want your custom code in their web sites. :( .
They want site built only on base of drupal.org modules. It is an official ideology. They call it "the drupal way".
And this could be done only by advanced tuning of hundreds of modules.
To understand how to do this you would need years and years. And this is nott even about programming. You will not be programming doing your drupal work.
And so you will be turning to a weaker programmer.
And when you would learn your knowledge then a new version appears and you would need to learn again.
Now Drupal 8 is too complicated to waste your programming abilities on it.
It has no sence.
It is my experience.
I wasted my programming time and skills for the trap with name drupal.
Now I am leaving from Drupal.

Submitted by John Locke on

Yeah, I've seen this attitude before.

The thing about Drupal is that it's a huge existing code base. Programmers tend to prefer green-field development, being able to write code from the ground up -- it's a lot more fun. Working with other people's code puts you at the mercy of their development patterns, their bugs, their foibles. And because there is so much existing code for Drupal, it's extremely rare you get to actually write something new.

But Drupal is not the only place that happens -- it's rare for programmers working at a job to get to write anything brand new -- that's a benefit you'll mainly get at startups.

Yes, there is very much a "Drupal way" of building things so you go with the flow, and it has been counter to much of the more formal computer science world. But it's hard to argue with results. Drupal, in spite of its quirks, has been getting the job done for years. And it is getting much better with each version.

The problem with developing in Drupal without using "the Drupal way" is maintenance. We pick up a lot of customers who had previously worked with other developers, and we've seen a wide range of hacked-together solutions that make it really difficult for clients to manage their own content, or make changes down the road. What's great about "the Drupal way" is that you can keep changing your site as your business evolves, adding fields, tweaking views, changing rules, and more, without needing to bring in programming talent.

The whole point of using Drupal is to get results quickly, not to make you a better programmer.

Submitted by Anton (not verified) on

About this topic.
I had a fun.
Do you think Drupal 8 become a good OOP system?
What a laugh.
It's the same procedural a lor, with the same procedupal hooks, which uses some oop code.
It was the same with drupal 7.
And to the site builders drupal 8 gives nothing. The admin functionality are completely the same.
But Drupal 8 is much much much SLOWER then drupal 7.
It would be a real pain to find a virtual hosting for Drupal 8 site.
Or maybe customers now want to hire linux administrators on a permanent paid servise for vps, vds yetc?
No?
They will have to :) . If they want their drupal 8 elephant site to work.

Submitted by John Locke on

Have you even looked at Drupal 8?

Hooks are gone. If you want to provide a new kind of block, you have to use a special annotation to register your code so it will get loaded -- this annotation system has replace hooks (and does bring a new level of weird to the table). And then you extend the appropriate class. It has gone much more object oriented, a far different coding experience from Drupal 7.

And the admin experience gets a nice upgrade with in-place editing, aka Spark.

It's way too early to compare speed -- it hasn't begun to be optimized. But there's one key area I expect to see a huge performance improvement -- with Ajax calls. With a much better routing system in place, I'm expecting a much smaller memory footprint for individual calls, which should translate into a very nice improvement for rich internet applications, letting us break out of having to provide everything on a single page and build far more interesting apps that progressively load things. That's an area that Drupal never handled well, but will now handle as well as any other PHP app...

Add new comment

  1. I recommend you use Linux for your server(s). Mine are so reliable, it shocked me that after years of Microsoft-based expectations, I have no complaints now after many many years experience with Linux servers supporting a mixed Win2K and Apple OSX workstation network. Freelock has really opened my eyes to what I should be expecting from enterprise software. Linux is simply much better than anything Microsoft has done, and even on Microsoft's best day, Microsoft is too expensive, too proprietary and too unreliable. There is just no reason to keep putting ourself through that grief, constant change, and endless high cost.

    George Roberston
    George Roberston & Associates

Need More Freelock?

About Freelock

We are located in Pioneer Square, in downtown Seattle. 83 Columbia Street #401 Seattle, WA 98104  USA [P] 206.577.0540 Contact Us/Directions | Site Map Get Updates ©1995-2014 Freelock Computing