Re: Why we stopped using Drupal for our platform(codedrop.com.au)
codedrop.com.au
Re: Why we stopped using Drupal for our platform
http://codedrop.com.au/blog/re-why-we-stopped-using-drupal-our-platform
15 comments
I think the Drupal community needs to get a really solid grip on what Drupal is (CMS) and how it compares to alternatives, and make sure they aren't leading people astray. There's this attitude that Drupal is some end-all solution to any web problem, when simply put, it's just a collection of many solutions to even greater (and growing) number of problems surrounding content.
If you want to capitalize on Drupal, your project needs to be well inside that problem set and you should have a tier of users that can and will learn arcane rituals and minutiae such as which of the five modules for X doesn't suck -- people who are going to be more productive doing so than if you were to have them writing code. These shouldn't be developers, these should be that class of person that is content to spend months complicating together a single spreadsheet, it's that same kind of work.
I've been doing Drupal full time for several years and I often say that if you're working on a Drupal project and you're in a code editor, you're probably doing something wrong. Most of the time, either there's a module for whatever you're doing, or you shouldn't have used Drupal.
Drupal agencies seem to sell Drupal as if it were bespoke development: hourly rates, design from scratch and lofty goals -- until it gets handed to a site builder "developer" who weeps because module X doesn't have support for module Y yet and fixing that properly exceeds the budget and their own skill set.
The Drupal service industry has to realize that Drupal and contrib is an IKEA and they should seek to serve clients as interior decorators do, not as carpenters - although I suspect it won't be quite as lucrative for them under that model, as well as many egos in the way.
Actual developers do exist in the ecosystem, but their time is best spent increasing the breadth and quality of the catalog of solutions for site builders, not cleaning up messes and creating endless one-off cludges on an over-promised project.
I've not yet had my conviction broken that there is a market for CMS, but whether Drupal is a suitable implementation of CMS, whether agencies can sell CMS properly, and whether I want to do this anymore are big questions for me right now.
If you want to capitalize on Drupal, your project needs to be well inside that problem set and you should have a tier of users that can and will learn arcane rituals and minutiae such as which of the five modules for X doesn't suck -- people who are going to be more productive doing so than if you were to have them writing code. These shouldn't be developers, these should be that class of person that is content to spend months complicating together a single spreadsheet, it's that same kind of work.
I've been doing Drupal full time for several years and I often say that if you're working on a Drupal project and you're in a code editor, you're probably doing something wrong. Most of the time, either there's a module for whatever you're doing, or you shouldn't have used Drupal.
Drupal agencies seem to sell Drupal as if it were bespoke development: hourly rates, design from scratch and lofty goals -- until it gets handed to a site builder "developer" who weeps because module X doesn't have support for module Y yet and fixing that properly exceeds the budget and their own skill set.
The Drupal service industry has to realize that Drupal and contrib is an IKEA and they should seek to serve clients as interior decorators do, not as carpenters - although I suspect it won't be quite as lucrative for them under that model, as well as many egos in the way.
Actual developers do exist in the ecosystem, but their time is best spent increasing the breadth and quality of the catalog of solutions for site builders, not cleaning up messes and creating endless one-off cludges on an over-promised project.
I've not yet had my conviction broken that there is a market for CMS, but whether Drupal is a suitable implementation of CMS, whether agencies can sell CMS properly, and whether I want to do this anymore are big questions for me right now.
Sounds a lot like most enterprise development. You don't write much code in that line of work day-to-day, you do lots of plumbing instead. With Java I found myself spending as much time writing XML to get A wired up to B as I was writing Java code.
I also remember using Hippo CMS on a project that wasn't well suited to it. That was the double whammie of enterprise Java and all its warts (complicated maven build system, XML coming out of my ears) AND the 'square peg, round hole' problem whereby the sold solution isn't actually remotely possible with the technology chosen out of the box.
It was around that time I quit that job.
I also remember using Hippo CMS on a project that wasn't well suited to it. That was the double whammie of enterprise Java and all its warts (complicated maven build system, XML coming out of my ears) AND the 'square peg, round hole' problem whereby the sold solution isn't actually remotely possible with the technology chosen out of the box.
It was around that time I quit that job.
Drupal was great for a time. At this point it just makes developers sad to work on. I see it as the tail end of the *Nuke days (DotNetNuke, PHPNuke up to 2006-2007 prior to Python/Ruby/PHP 5 days).A cleaned up pass from that phase but well before the mobile, service based, cloud and responsive web that is also more efficient.
Building custom products you want to make sure your developers are happy and the platform is flexible and fast to iterate on, Drupal is not the best choice. It has the same programmer dread that Sharepoint has.
Most sites I end up seeing on Drupal have upwards to 100-200 db calls per page before optimization and caching but even then still heavy. It is at EOL.
Yes you can build solid and tightly run Drupal ship as you can with any tech really, but why if you are starting a new system these days? There are much better solutions in every area. It is monolithic systems like Drupal, Sharepoint, etc that continue to push people to microframeworks.
Building custom products you want to make sure your developers are happy and the platform is flexible and fast to iterate on, Drupal is not the best choice. It has the same programmer dread that Sharepoint has.
Most sites I end up seeing on Drupal have upwards to 100-200 db calls per page before optimization and caching but even then still heavy. It is at EOL.
Yes you can build solid and tightly run Drupal ship as you can with any tech really, but why if you are starting a new system these days? There are much better solutions in every area. It is monolithic systems like Drupal, Sharepoint, etc that continue to push people to microframeworks.
> "It has the same programmer dread that Sharepoint has."
Ultimate zing. That's my experience too.
There are so many great options that I can't for the life of me think why you'd pick Drupal. Maybe you had to choose between Drupal and Joomla?
> "It is at EOL."
Exactly this.
Ultimate zing. That's my experience too.
There are so many great options that I can't for the life of me think why you'd pick Drupal. Maybe you had to choose between Drupal and Joomla?
> "It is at EOL."
Exactly this.
I work for a company that invests heavily into drupal and I'd highly recommend jekyll. Way better solution to almost all CMS use-cases. Sure some content producers might initially balk at actually having to actually check in their changes to source control but with static site generators you get a ridiculously fast, unbreakable, and scalable site as well as better change management, the possibility for real editing tools, no databases to worry about, and so much more.
As a Drupal developer, I approach it as a right tool for the right job. And familiarity with said tool is also a factor.
The future looks promising: http://symfony.com/blog/symfony2-meets-drupal-8 http://buytaert.net/the-future-is-a-restful-drupal
The future looks promising: http://symfony.com/blog/symfony2-meets-drupal-8 http://buytaert.net/the-future-is-a-restful-drupal
> Once you’ve mastered the Drupal framework, building and maintaining content heavy sites is easy, efficient and also fun!
From a personal point of view, the "easy, efficient and also fun" aspects of it just stop being true since Drupal 7. There is IMHO some well intentioned over-engineering at work there, along with a fairly asphyxiating/monopolistic stance from a certain company.
Drupal is great to wipe out publishing platforms (online magazines for example), but can quickly become an expensive constraint as soon as you start ramping up on complexity or customization.
Good for small to medium (at best) fairly straightforward sites, not at all to build web apps. I'd be sceptic of anybody telling you otherwise.
On a broader note, I think the need for monolithic solutions like CMS is also shifting. Shameless plug of a post I wrote recently about it http://devo.ps/blog/2013/01/31/farewell-to-regular-web-devel....
From a personal point of view, the "easy, efficient and also fun" aspects of it just stop being true since Drupal 7. There is IMHO some well intentioned over-engineering at work there, along with a fairly asphyxiating/monopolistic stance from a certain company.
Drupal is great to wipe out publishing platforms (online magazines for example), but can quickly become an expensive constraint as soon as you start ramping up on complexity or customization.
Good for small to medium (at best) fairly straightforward sites, not at all to build web apps. I'd be sceptic of anybody telling you otherwise.
On a broader note, I think the need for monolithic solutions like CMS is also shifting. Shameless plug of a post I wrote recently about it http://devo.ps/blog/2013/01/31/farewell-to-regular-web-devel....
hey ronan =)
I just came here to say the same thing. However, I dont think Drupal is right for most small projects either.
I think Drupal's ideal use case is when you have a small community site where you will have many people creating and curating content.
Anything smaller, and you can probably get away with Jekyll or some other static site generator. Anything bigger, and you need to look at building a custom app in django, rails or my current fav.. node.js.
I just came here to say the same thing. However, I dont think Drupal is right for most small projects either.
I think Drupal's ideal use case is when you have a small community site where you will have many people creating and curating content.
Anything smaller, and you can probably get away with Jekyll or some other static site generator. Anything bigger, and you need to look at building a custom app in django, rails or my current fav.. node.js.
What I meant was that a small-ish site with a bunch of writers (community or not) would probably fit. We're suckers for Jekyll, node.js and Python, so not really looking back.
There are use cases for Drupal, just probably not the kind of things we'd get involved with. I think the overall state of the ecosystem and community is more of an issue for me than the technical considerations.
There are use cases for Drupal, just probably not the kind of things we'd get involved with. I think the overall state of the ecosystem and community is more of an issue for me than the technical considerations.
Drupal has some attributes that make it great for websites from the nonprofit and government agency perspectives.
- No license fee
- Ton of modules = most common functionality is quick (cheap) to add
- Powerful point-and-click interface lets non-coders manage significant functionality
- A good security record and a large, security-conscious community
- Easy to find hosting = low hosting costs
- Plenty of shops know Drupal = keeps vendors honest
- You can pay a flat fee for enterprise support (Acquia)
In contrast, custom coded solutions have unknown security futures, unknown support futures, and you're dependent on the team who wrote it originally (few companies are willing to try to understand and support someone else's custom code).
- No license fee
- Ton of modules = most common functionality is quick (cheap) to add
- Powerful point-and-click interface lets non-coders manage significant functionality
- A good security record and a large, security-conscious community
- Easy to find hosting = low hosting costs
- Plenty of shops know Drupal = keeps vendors honest
- You can pay a flat fee for enterprise support (Acquia)
In contrast, custom coded solutions have unknown security futures, unknown support futures, and you're dependent on the team who wrote it originally (few companies are willing to try to understand and support someone else's custom code).
Here's the comment thread for the original blog post: https://news.ycombinator.com/item?id=5158837
My company uses Drupal for developing a lot of it's projects, and I find it to be a great platform. It is * definitely* quirky, and does have a high learning curve. There are 5 ways to do any one thing, and it isn't always clear what is the right way to do something (frustrating to new devs).
I will say that it is very easy to develop apps with bad performance (doing 500 queries on a page load) and are not very scalable. It takes a lot of dedication and attention to detail to ensure your app/website is running at it's full potential. At it's core though, Drupal is just a beefy PHP framework, with a very robust hook system and APIs for doing a lot of things. It's node/entity system are very helpful when used properly, and is one of the reasons it remains popular.
Obviously, it's popularity is completely driven by the extensive theme/module development community that helps support the CMS. Without them, Drupal really would not be worth using.
I will say that it is very easy to develop apps with bad performance (doing 500 queries on a page load) and are not very scalable. It takes a lot of dedication and attention to detail to ensure your app/website is running at it's full potential. At it's core though, Drupal is just a beefy PHP framework, with a very robust hook system and APIs for doing a lot of things. It's node/entity system are very helpful when used properly, and is one of the reasons it remains popular.
Obviously, it's popularity is completely driven by the extensive theme/module development community that helps support the CMS. Without them, Drupal really would not be worth using.
I've been using Drupal 7 at my job for about 9 months now, it's the most bloated piece of CMS ever.
I've used symfony1 since the beginning of 2008, then symfony2 from ~2011.
I've found drupal 7 to be good for client websites, custom module development is a major PITA to do anything interesting with, the core drupal 7 is a major clusterfuck...
You need to treat Drupal 7 as a CMF and learn where to hook in from over something `traditional` like RoR or django or symfony2 or any other framework.
I've used symfony1 since the beginning of 2008, then symfony2 from ~2011.
I've found drupal 7 to be good for client websites, custom module development is a major PITA to do anything interesting with, the core drupal 7 is a major clusterfuck...
You need to treat Drupal 7 as a CMF and learn where to hook in from over something `traditional` like RoR or django or symfony2 or any other framework.
As a full-time web developer who works almost exclusively in Drupal, I'm sure that I'm more than a little biased, but I love it. I have a pretty varied background, and a lot of different experience, but Drupal is consistently the tool that I prefer these days for most of my projects.
I often hear that the learning curve for Drupal is high (and it certainly seemed that way to me five years ago when there weren't as many resources), but I can explain the major concepts and architecture of Drupal 7 to almost anyone willing to learn in about 10 minutes.
The biggest problem that I've encountered when working on Drupal sites is actually just bad/lazy developers. These people aren't really "Drupal Developers". They came from Joomla or .Net and jumped into Drupal projects without ever considering that they should find out what makes Drupal different. They won't be contributing anything back to the community, and it's unlikely that they'll develop anything that's reusable from one project to another. There is an abundance of information out there right now (even just on Drupal.org) for someone who wants to learn how to work with Drupal properly, but it seems like a lot of people would rather just complain that it doesn't behave exactly like whatever else it is that they're used to than actually try to learn about it.
For the record, a good place to start would be the Drupal documentation[1]. Drupal Answers[2] is pretty good, too. If you ever want to learn about a specific contributed module, try searching Youtube.
1: https://drupal.org/getting-started/before/overview
2: http://drupal.stackexchange.com/questions?sort=votes
I often hear that the learning curve for Drupal is high (and it certainly seemed that way to me five years ago when there weren't as many resources), but I can explain the major concepts and architecture of Drupal 7 to almost anyone willing to learn in about 10 minutes.
The biggest problem that I've encountered when working on Drupal sites is actually just bad/lazy developers. These people aren't really "Drupal Developers". They came from Joomla or .Net and jumped into Drupal projects without ever considering that they should find out what makes Drupal different. They won't be contributing anything back to the community, and it's unlikely that they'll develop anything that's reusable from one project to another. There is an abundance of information out there right now (even just on Drupal.org) for someone who wants to learn how to work with Drupal properly, but it seems like a lot of people would rather just complain that it doesn't behave exactly like whatever else it is that they're used to than actually try to learn about it.
For the record, a good place to start would be the Drupal documentation[1]. Drupal Answers[2] is pretty good, too. If you ever want to learn about a specific contributed module, try searching Youtube.
1: https://drupal.org/getting-started/before/overview
2: http://drupal.stackexchange.com/questions?sort=votes
Drupal Core is basic enough that you can wrap your head around it in 10 minutes, but Core isn't going to give you a very useful site. So, you need to start adding in modules, often with their own incompatibilities and APIs (ctools). And then things start falling apart.
The code to create a node is simple. The code to create a node with a term reference, two field collections, and images copied from the filesystem is considerably more complicated, poorly documented, and prone to throwing weird errors.
The code to create a node is simple. The code to create a node with a term reference, two field collections, and images copied from the filesystem is considerably more complicated, poorly documented, and prone to throwing weird errors.
The module system is actually what I was talking about. You don't need to understand every single contributed module to understand how the whole system works. I'd like to see your example of how/where Drupal "falls apart" when adding contributed modules.
If you're writing a module when you don't understand how modules work, you're gonna have a bad time. The Examples for Developers[1] module probably would have helped out. The Field example creates a custom field. The Node example create a custom node type. Or you could have just created the node type using the Field UI (and if you need it in code, export the configuration using Features[2]).
1: https://drupal.org/project/examples
2: https://drupal.org/project/features
If you're writing a module when you don't understand how modules work, you're gonna have a bad time. The Examples for Developers[1] module probably would have helped out. The Field example creates a custom field. The Node example create a custom node type. Or you could have just created the node type using the Field UI (and if you need it in code, export the configuration using Features[2]).
1: https://drupal.org/project/examples
2: https://drupal.org/project/features
This post really resonated with me. I'm a Joomla! developer and the learning curve for the Joomla! Framework and CMS is a bit steep but once you understand the extensions architecture building web apps becomes enjoyable. Being able to break down an app to templates, components, modules and plugins is what I feel makes a system like Joomla! (or in your case Drupal) worth the time investment.
My main gripe with Drupal is the missing ease of deployment and/or DB migrations.
It's been a year or two, but thinking up a good way to automate deployments was headache-inducing.
Great points. I would also add awesome developer community around Drupal project. It is not about Dries anymore, it is about community his project created. Hooks system in my opinion is just a reflection on how community works.
The HN title is confusing, it should be "Re: Why we stopped using Drupal for our platform" because this is an answer to another post.
That's what I posted it as. It looks like it was removed somehow?
The way Drupal is constructed is a work of genius. You need to understand that Drupal was invented in a university dorm before design patterns were popular and Dries did an excellent job at creating a content framework in PHP in the days that PHP wasn't even much a language (one can argue further I guess).
However, having said that. Because everything in Drupal is so abstracted, to do even the simplest thing, such as adding or modifying a form, as a developer you need to be across such a large extent of sub-systems and naming conventions that the learning curve on Drupal is simply way to high and totally unnecessary.
I say this because you shouldn't use Drupal for anything than building websites and if you're building websites then why not do yourself a favor and use Wordpress instead...