Why we stopped using Drupal for our platform

Me with Dries Buytaert, creator of Drupal

Me with Dries Buytaert, creator of Drupal

I love Drupal. I have been engaged with the technology, the community and the vision for about 2 years now. So much so that I attended DrupalCon 2012 in Denver and loved it (I compare it to Google I/O when I consider the quality of tech conferences I have been to). But unfortunately, due to the reasons I am about to describe, I have come to the realization that Drupal is actually a horrible solution to build apps (content or non-content heavy) in agile environments, which is pretty much the case with most web start-ups. This has led me, the sole developer/engineer of my startup, to switch from building our core platform on Drupal (which I did for several months) to now building it in Django from scratch. This is not a pro-Django article, as I think I could accomplish the same with more or less similar difficulties in the 7+ MVC frameworks I have worked with in the past. I want to tell you exactly why Drupal is not right for such a context.

Drupal, much like many other CMSs, follows a development methodology that I call reverse development. It is the simple idea that the most fundamental moving parts of the technology have been already built for you, or are modifiable using a trivial UI, and for you to be able to accomplish a certain special functionality, you are required to engineer your way backwards by “hooking” in to its current processes, and modifying the functionality or data to your preferences. This is not only true with non-user-facing functionality, but also with views data fed into templates, and sometimes also with designing themes. The benefit of this approach is that it allows non-developer site administrators to do simple changes to functionality with modules/plugins without ever writing a line of code. In fact, Drupal today supports creating models and model objects (using concepts like “Field”s and “Entity”s) using amazingly intuitive UIs. Unfortunately, this has some very serious bad implications for developers trying to build “apps” (CRUD++):

  1. Lack of familiarity with core functionality. Because most functionality is actually hidden from the developer, as the process of development involves interacting with an API and “injecting” code snippets in existing operation flows rather than defining the flows by yourself with rich abstractions, he/she has no idea how most things work. This includes having no idea what the database schema looks like, or having any clue that you’re modestly small app has already left a footprint of over 200 MySQL tables. This not only gives rise to horrible debugging experiences (for which there may be good tools) but also inability to optimize performance.
  2. High development time. I have personally trained at least 3 developers to get started with Drupal. Unfortunately, they say the exact same thing as I said when I first started learning: this takes way too long as is too confusing. If you’re going by the assumption that someone who can write PHP can easily pick up Drupal-like CMS development, you couldn’t be further from the truth. Despite spending so many nights on their API docs, I still require tremendous reading time whenever I am confronted with a new situation. What’s worse is the fact that a lot of the API changes with every new release, making half of the StackOverflow debates on “how to get xx done” outdated after a couple of years.  No start-up can afford a high initial learning curve, as it just doesn’t fit into their agile development practices or MVP goals with often scant freelance tech labor. It just takes way too long to get really really simple things done at times. There is a reason why Drupal devs are some of the most hotly desired tech talent in the market.
  3. Custom comes at a big cost. Drupal comes with rich defaults in just about everything it comes packaged with. It is a pleasure to use these when you want to play nice. But unfortunately, when you are trying to build an app with a very specific look, feel and functionality, you often want to build things from scratch. Trying to do anything custom, such as pump in your own variables into overly complicated and obscure views objects, can suck up your time and energy before you know it.

Another really important development concept around Drupal is modules. This is the equivalent to modules or plugins or extensions in most of the CMS world. One can say this is similar to apps in MVC frameworks like Django, but no, its not. It’s not similar because writing a module in Drupal requires a massive amount of boilerplate. It’s not similar because one never defines models or views or controllers or templates in their traditional sense, but rather writes functions and functions and more functions not forgetting helper functions. It’s not similar because the scope of a module’s functionality is not just confusing, it’s scope is undefined. Sure modules are re-usable and distributable, but they are barely comprehensible because of the breadth of API hooks they use and implement themselves.

 

To sum it up, Drupal, for the reasons mentioned above and more, may not be a good environment for your agile development needs. It is an extremely robust, powerful and beautifully architectured technology ecosystem for its purposes, but can easily become a developer nightmare in ambitious contexts. Some people consider it a good tool to build an MVP – I won’t debate that, but I do not fully agree too, as it can very easily become a pain depending on what you are trying to do. All hope is not lost, there is good news – Drupal has partnered with the Symfony (a dying PHP MVC framework) community to bring some of its components and app development philosophies into Drupal 8, Drupal’s next release. I have been witness to the discussions on what is planned for the same, and I am sincerely impressed. With the amazing brains behind the same, I won’t be surprised if one day Drupal is amazing to build things from “scratch” with, but unfortunately, today, it’s not.

 

UPDATE: I take back the adjective “dying” for Symfony. I do not actively follow the progress on Symfony and Symfony2, but my friends following the community closely mentioned that it is certainly not thriving in popularity. I pissed off a couple of people I sincerely respect, in the process. So, apologies for that!

This entry was posted in Entrepreneurship, Technology, Web. Bookmark the permalink.

106 Responses to Why we stopped using Drupal for our platform

  1. Terje Tyldum says:

    I guess this is normal for every CMS out there. You get a lot out of the box but as soon as you need more and more custom code the CMS starts to get in your way.

  2. rami says:

    So what you plan to use instead of drupal?

    • Varun Arora says:

      It’s a lot of content management, so CMSs like Drupal seemed like the obvious best choice initially. Now moved with Django/Python, and very happy with that decision

      • Asofyan says:

        We also have experiences more than 10 websites we built with Drupal. Lots of hassle, especially when we have more than 15 modules installed, next to our own developed module.

        We are moving to Django, especially mezzanine, which I am happy with the decision.

      • luis says:

        IMHO Drupal is a huge nightmare. I’m a Django developer as well. Never used other python frameworks like web2py, so i can’t say it’s the best, since i can’t comapre it with anything.

        But i can’t compare using Drupal with using Laravel, for PHP, even when i’m also a total n00b @ that. And since i’m a developer and not a final user, I can say Drupal is HORRIBLE regarding coding. “Drupal is good despite php” is FALSE: Laravel is good despite PHP, in comparisson. Developing in Laravel is beautiful (even when PHP has serious disadvantages against python, Laravel circumvents many of them and “emulates” many of the django features).

  3. Sal says:

    I have not worked with Drupal, but if it’s a content management system like WordPress, then I agree that programmers would be better served working from scratch. In fact, I was asked to debug a WordPress site because of my knowledge of PHP/MySQL. In response, I advised that they should look specifically for a WordPress plugin designer.

  4. Kris says:

    This post does a great job of saying something I’ve been wanting to say myself. I am moving away from the excellent WordPress platform in favor of developing in scratch using light frameworks like PHP/Slim and Python/Bottle.

    It could be that greatness is what has made WordPress big and sophisticated. If you are doing a blog it can’t be beat. I know WordPress ninja guys can make it do anything.

    For me the time and energy to figure out how to do what I want within the framework and workflow that they have defined is simply too large and doesn’t create the kind of snappy and unique look and feel that I want. The power comes at a great cost to flexibility, simplicity and efficiency. I like the idea of having just the code that is needed – not an extra line or module.

    Thanks!

  5. Axel Bouaziz says:

    Are you serious ?

    Symfony is going very well !

  6. mamadou says:

    Senior drupal developer, i allmost agree with this in general. Being agile with drupal ! that is a real challenge.

    Laravel is the php framework to follow these times

  7. Josh Taylor says:

    Whilst I agree with everything you have to say about Drupal 7, Symfony2 is NOT a dying PHP MVC Framework.. have a look at their github and their current bundles, the work that has been created as a result of symfony2 – composer, etc…

  8. Dunno what makes you say that Symfony is a dying framework… any credible source? Their Github seems to have consistent number of commits in the last two years https://github.com/symfony/symfony/graphs/contributors

  9. Tom Singer says:

    Interesting points and I’d agree that I wouldn’t use Drupal for application development but for content site development it’s very powerful if you know how to use it. I would however disagree that symfony is a dying framework, what leads you to draw that conclusion?

  10. Mushfiq says:

    Absolutely perfect,I worked with both Django and Drupal. And exactly had the same experience.

    • Vladimir says:

      So, can you advice to switch from drupal to django. Or not?

      • Mushfiq says:

        Hm, if your project dont have “Drupal Expert” dont go with it, wrapping your head around different concepts take time in drupal. On the other hand Django is really easy to learn and you can implement features on the day one. I will not ask anyone to switch but should take decision based on resource in his team.

  11. Three Pipe Problem says:

    Nice article.

    I think what you call “reverse development” is commonly known as framework development.

    • Varun Arora says:

      Thanks for pointing that out, TPP. Definitely did not know as I haven’t heard the phrase before. I am sure there a tonne of similar phrases floating around the web, we all need to come to a consenses on what to call this.

  12. Matt Farina says:

    I’m curious why you call Symfony a dying MVC framework. Symfony is observed to be growing rather than dying and it doesn’t say it’s based on the MVC pattern. MVC is a specific pattern. Do you mean MVC or separation or concerns? In either case, I’ve used Symfony or parts of it in ver non-MVC setups.

    I also find some of your assumptions interesting.

    1. The scant freelance tech labor force goes beyond freelance. I’ve observed a lack of a experienced web tech labor force going well beyond freelancers. I see people who claim to be experienced doing bad work and not able to talk through the technologies. Or, I’ve seen them not understand simple solution patterns to common problems (e.g., CSRF protection).

    2. High development time depends on what you’re trying to do and who you have. A handful of experienced Drupal developers can build something faster than a handful of people who need to learn Rails at the same time they are starting something up. What you use, the time it takes, and how it turns out is often related to people and not a particular piece of technology.

    3. The reverse development (as you call it) can be a real problem for a lot of developers. Novices and site builders seem to really like it. Many more experienced developers complain about EXACTLY this same problem.

    Good luck with Django. I hope that works out better for you with what you’re building.

    • Varun Arora says:

      Matt, first off, thanks for reading and responding. I am a fan of yours.

      I have taken the use of that adjective back. My apologies. I meant the use of Symfony with the MVC pattern there. Should/could have been more clear there.

      To respond to your points:

      1. Agreed. I think I meant scant tech labor, but in the context of start-ups, freelance. Semantics
      2. I think I mentioned that to be true only for CRUD plus a little more functionality apps. Which is very much the case for prototyping. Unfortunately, I don’t think that Drupal has only a high initial learning curve. It generally takes a lot more code, a lot more understanding of distributed files, to get stuff done. The correct answer is “it depends”. But most web startups don’t have or have access to experienced Drupal talent, so this would hold true for them.
      3. Agreed. I would say site adminisitrators like it. Not people who have previously played around with app development using this fancy frameworks built in the last 10-ish years.

      Thanks for your wishes! I hope it works better too. Have to write all the content revisioning code from scratch this time around, but in all honesty, I don’t mind as I am finally understanding how it works, rather than node magic

  13. This is where Drupal’s dual-personality as a CMS application and a quasi-framework can cause problems. It’s so tempting to use as a pure app framework, because it offers so much for you… except when you want to go outside of the normal workflow, and then the normal workflow gets in your way. I’ve seen some really compelling application-esque systems built on Drupal, but truth be told that’s not its sweet spot.

    I’ve written about the difference between an additive and a subtractive (what you call “reverse development”) system before: http://www.garfieldtech.com/blog/small-core-big-ideas

    Symfony is anything but dying. The reason we adopted it was because it was doing so much well, and it would save Drupal 8 a lot of time reinventing wheels we didn’t need to invent. As they like to brag, it’s the most watched PHP project on GitHub. :-)

    An important side-effect of that, however, is that the distance between Drupal and Symfony gets smaller. That means even though Drupal 8 should be a more additive, flexible platform than Drupal 7, if you find you really need a for-reals framework instead of a super-flexible application (which is often the case), Symfony is right there and shares many of the same concepts. In fact, with HttpKernel it should be possible to embed one within the other. Neat. :-)

    The distinction I usually draw is “Which is more important, your content, or your business logic?” If your content is foremost, and your business logic is just variations on the usual CRUD theme, then a good CMS (such as Drupal) will serve you well. If, however, your business logic is more important, and easily configurable content is there to support the business logic and not vice versa, then you’ll be better served by a “true” framework (Symfony, Django, CakePHP, take your pick).

    Drupal 8 will definitely be better for what you’re describing than Drupal 7. However, if you want to “build everything from scratch” and not use UI-based configuration… then yes, Drupal is not the tool for you, and that’s OK.

    • Varun Arora says:

      Larry, thanks so much for taking the time to read this and comment. I remember meeting you at the DrupalCon and was just so impressed on where you are taking this. I am a big fan of yours.

      Thanks for sharing your blogpost on your ideas on addtive and subtractive development. It is similar to what I am calling “reverse development”, but I am sure you understand this problem way more deeply than I ever will.

      My sincere apologies calling Symfony “dying”. I have taken that back! I am fully aware why it is being adopted in Drupal 8, and I cannot wait to see how it gets integrated into core.

      I like the distinction you are drawing out there between content and business logic. But I feel that it isn’t all that simple of a question to ask. And this I say from personal experience. The site/platform/app (whatever you call it) that I built, all revolves around content. In fact, its core goals are good content and revision management. With little business logic around it. And looking at great contrib modules like workbench and the node revisioning system, I thought Drupal was the best bet. Until, 8 months into it, I realized how painful the journey had been. Business logic and content cannot be separated in an “app”. In a static public facing organization website, your distinction would make perfect and complete sense.

      Looking forward to everything you are working on for D8. I think my “” were around scratch and not the “build everything from scratch”. But I get and appreciate your point – thanks!

  14. Mike Milano says:

    It sounds like this post is making a case that Drupal has a steep learning curve and a strong understanding of how to develop productively was never achieved.

    I definitely agree, the learning curve is steep, but the technical arguments beyond the learning curve are a little weak.

    For example

    because writing a module in Drupal requires a massive amount of boilerplate

    This is pretty far from the truth. A .info file with a few lines that tells the system the name and version of your module, and a .module file itself, is all you need to create a module. Depending on what that module does, it could be a few lines of code. As with any app you develop, the code is going to grow with the functionality you need to implmement, but in general, a module definitely does not need a massive amount of boilerplate.

    It’s not similar [to MVC] because one never defines models or views or controllers or templates in their traditional sense, but rather writes functions and functions and more functions not forgetting helper functions.

    It’s not MVC in the traditional sense, but it does good at providing the tools to separate the display logic. The developer could apply MVC principles in practice by using the module as your controller. Within a module, you have the full capability of defining your own templates to separate the display logic. Then treat the entities (nodes, users, etc…) as models.

    Writing functions and helper functions sounds like standard development to me. If you feel you’re writing too many functions, you may be taking the wrong approach.

    High development time. I have personally trained at least 3 developers to get started with Drupal.

    Respectfully, I am not sure how effective training developers would be when so much doesn’t make sense to you. With the steep learning curve, maybe “high development time” should be “high learning time” because development time really isn’t unusually high when the concepts and APIs are understood.

    All that said, it’s just a tool in the toolbox, and it makes perfect sense to go with tools that are more comfortable for the tasks at hand.

    Also, not sure if anyone mentioned yet, but the upcoming Drupal 8 will also be incorporating many core Symphony libraries.

    • Varun Arora says:

      Mike, thanks for your thoughts. I sincerely appreciate you taking the time.

      To address the points you raised:
      1. A .info file = boilerplate. A database schema definition hook with need to specify to the detail of number of characters in a varchar field (if we don’t get into the discussion of control) = boilerplate. Defining themes to present you’re views in a custom way = boilerplate.

      2. What makes an MVC framework a framework that is good at MVC is its ability to encourage MVC-oriented development behavior. A not-deeply-experienced developer should not be expected to enforce the pattern if the framework and its documentation does not encourage it. And I have repeatedly read arguments about “but a great Drupal professional…. blah blah blah” in other contexts, when defending Drupal – but hey, Drupal isn’t meant to be hacked only by elitists, now is it?

      3. You’re comment is taken respectfully. But my argument is more that I consider myself fairly competent at Drupal, and I still struggle with teaching several concepts and touching deeper moving parts for some fairly simple behavior. I shouldn’t be expected to know how to hack the core for simple things, now should I?

      • Matt Young says:

        “Hack the core”… seriously, you just used that sentence in that context? http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means

        I liked some of your article, some of it. I agree that Drupal makes a great CMS, I agree that writing your app from scratch makes it more agile for you (as long as you can remember what you did as it grows) I will say that Drupal can be used for “lighter” “apps” by providing those “apps” it’s content/data… as well as many many other cases.

        The right tool is the right tool only when used for a specific job and specific resources with the future of that job and future resources expectations taken into consideration…

  15. Jon McLaughlin says:

    I think these are valid points, but I also think there is something to be said about the differences of working on one web site/application full time and working on 10 sites a year. There’s not always enough time to build everything from scratch in a project. I’m glad that I can lean on the huge Drupal community and contributed modules so that I can get projects completed for clients quickly. Hooking in and altering existing functionality saves a lot of time, especially knowing that the same code is being tested by the larger community.

    • Varun Arora says:

      That is certainly true, Jon. But it is also true that one can use “contrib” apps in MVC frameworks in just a similar way. I used to fight endlessly with my developers to prove how the Drupal community’s work can be so easily re-used, but after having re-used apps in Django, I didn’t think Drupal had any edge after all. The only edge was the readiness for site administrators – there is nothing easier for a non-developer administrator than Drupal’s environment when it comes to installing new modules.

  16. Did you just call Symphony a dying PHP MVC framework? I wonder why, I see no signs of Symphony’s iminent death.

  17. Amy Stephen says:

    The partnership with Symfony is brilliant for both projects. I follow Symfony on gitHub and frankly I don’t know of any project that is more active or alive. They are leaders in the PHP space.

    In the 30 years I have worked with IT, I have trained many devs and I have been trained in many new technologies. In all honesty, I can’t think of a single application that wasn’t confusing at the start.

    I agree that it was easier to understand when we built applications from scratch, years ago. But, the level of sophistication required for applications today makes it impossible to rebuild all functionality. Let alone in a way that we can be assured of any level of correctness.

    Today, learning how an application works, understanding how to add a little code here and there, is largely what a good application developer is called upon to do today. The better one understands the environment, the more quickly they can get the job done.

    I am eager to see the Drupal community, with an insane amount of knowledge about all kinds of technology will do with a frontend controller, plugins, and that HTTP Foundation beneath that CMS. It’s going to be good, I’m confident of that.

    I am curious, though, why the picture of you and Dries? In context, maybe not constructive? I don’t know. Sticks out to me.

    • Varun Arora says:

      Thanks for the comment. My apologies for considering Symfony dying, Amy.

      All very sensible and good points there. They are not over-the-top and loud like my arguments, but very much the truth of how things work. I am also very confident in Drupal’s future.

      The photo was to emphasize my love for th Drupal community. And hopefully convey this to be constructive criticism. Possibly add a little personalized touch too. Thanks for pointing it out, anyways :)

  18. I have felt your pain of trying to work within the constraints of a cms. Realizing that on wordpress or joomla building the things I wanted to do was going to be super difficult. I chose Ruby and Rails instead of python and django. After a month I was absolutely sure that jumping ship was the right thing to do. What you get out of the box just isn’t worth the pain.

      • Laz says:

        i think the original post makes some excellent points, and is spot on it its critique of drupal, imo.

        when the only tool one has is a hammer, everything looks like a nail.

        these days, almost every website i develop or update is a dynamic content-driven site, with some amount of additional (sometimes fairly complex) functionality that i have to develop. drupal is awesome for this type of development. a large-scale business application would absolutely warrant a look at more fundamental building blocks/frameworks, depending on the business and technical requirements. prior to about 2 years ago, i used my own custom php framework for all web development i did. the reason for that was i had looked at all the major php frameworks, and decided they were all just ruby-on-rails wannabes. i had worked with rails for a year or so, and despite some fantastic concepts (which, sorry if this sounds like a self-back-pat, i had implemented in toolsets for distributed application development back in the early ’90s), i literally HATED the implementations, not to mention the dogma and condescension of the community.

        i am a bit of a dinosaur these days, having been doing software development for well over 25 years. i find that these days almost anyone can fancy themselves a developer and throw together something using any number of php frameworks/tools, or rails, or whatever. when i look at some of the (php) open source applications out there that are widely used, i am truly shocked at the poor quality of the technical design and code (i know i am not alone here). wordpress, oscommerce, zencart, squirrelmail, these are just some major examples. drupal does a bit better imo, as at least it looks like some forethought and technical design went into it. but seriously, these days the underlying assumption seems to be that blazing hardware and massive caches can cover up any poor/lack of design.

        and that is my primary complaint about drupal (and even moreso for all the rails-like frameworks). the desire to make the developer’s job easier has resulted in some design tradeoffs that imo reduce the overall efficiency, stability, and performance of the final product. as someone who had to focus on large-scale database design efficiency and performance for so many years, when i see that rendering a single html page requires 30-50 sql queries, i am appalled. sure, people just throw hardware and caching at it, but does that truly solve the problem in the long run?

        what we used to call model-driven development (models in this case being design models such as db models and object models, not mvc models) provided what i think is a great balance between solid technical design, excellent flexibility, and runtime performance. you design your models, then you generate very specific and optimized code for the specific context of that particular system or functionality. (caveat – i wrote a great many code generators in my day, and as a system architect and experienced developer in a wide range of languages, i understood how to generate optimized code for each toolset being used, from sql to c/c++). obviously the design allows for custom coding that can be plugged in in such a way as to not be impacted by re-generation of the models (many current frameworks have adopted this, hence “core” vs contrib or whatever). i thought rails had this concept down, but when i saw all the runtime activity behind the scenes … wow. having to query the system catalogs/data dictionary at runtime for virtually every operation in a high-volume system… holy shit!

        the one php framework that i really liked was kohana. well designed, efficiently coded, and nicely object oriented (as much as php allows anyway). true, kohana also wanted to have that rails-like auto object-relational mapping, but i was easily able to simply not use it. v2 of my custom framework was actually built on kohana. problem was i had to create too much common functionality myself – that is why i eventually adopted drupal for the majority of sites i do. the drupal learning curve is fairly steep, and i would have made some of the design decisions very differently. but the coverage of useful functionality right “out of the box” makes it a viable contender for all but the largest and most complex of applications, imo.

        to summarize my rant: i feel like current web development focuses far too much on making the developer’s job easier, at the expense of solid design and runtime performance/efficiency. the latter is somewhat offset by using high-end hardware, gobs of ram and cache cache cache. to me that is a band-aid. no amount of hardware and tweaking can substitute for good design, in the long run. an unfortunate side effect of making development easier, is that the quality of code overall is hugely degraded, because almost anyone can do it.

        like i said, i am a dinosaur. and i no longer have as much desire to keep up on all the new technologies and languages, so no doubt there are aspects of this discussion i am missing.

        this is a good discussion, thanks!

  19. Muhammad Aslam bin Ahmad Suhaimi says:

    Hi.

    As a certified requirements engineer, I believe your issue could have been avoided with proper Requirement Analysis. I have been using Drupal for 6 years, but Drupal has never been my only solutions, as I also plan for custom developments and also using other solutions as a basis. I can never say Drupal, or any other system, is a solution to every project. Only after a proper requirements analysis should we decide the solution that we want to use.

    • Varun Arora says:

      Thanks for that, Muhammed. Just fyi, I have two degrees in Information Systems from one of the best universities in the world, and that is one of the most vital things taught. No level of requirements analysis per se can give you a sense of painful development experience that I have experienced. No requirement analysis tools give you a chance to ship an MVP to gauge adaptability to needs. And realistically, which start-up does that?

  20. Very interesting discussion.

    1. I can share the author’s feeling around reverse engineering – and I like the term. Because often with Drupal it feels like you need to search relatively deep to fully understand what to do in a specific case (especially when you do it the first time).

    2. The problem for me clearly comes from the following contradiction: Drupal is very easy to install and use even with little PHP knowledge (which helps grow its market share). But once you reach a certain point of customization, suddenly a lot of knowledge/research is needed to get little things completed. Hence the frustration.

    3. Final problem (but also strength, of course) is that there are so many different ways to do things in Drupal. Just compare: why does Drupal’s theming documentation have more than 100 sub pages and the one from WordPress is a single, well structured page?

    http://drupal.org/documentation/theme

    http://codex.wordpress.org/Theme_Development

    • Varun Arora says:

      Thanks, Stefan.

      1. reverse development, not to be confused with reverse engineering. Very large difference.
      2. Great point!
      3. I think theming is an all-time disaster when it comes to CMSs in general. Needs to be addressed sooner rather than later.

  21. Douglas Karr says:

    This is an interesting perspective and one that I’ve honestly not heard before. My own agency is a WordPress shop and we find ourselves doing much more customization than ever in the past. We have a client who is a Drupal shop who is developing new features and rolling out new site components every week and are incredibly happy with the platform. They have over 3 million pages on their site, it’s incredibly fast, and the CMS is providing all the functionality they need or the flexibility to develop it. The problem that I see with your objective criticisms are that you don’t balance the customization, development time and lack of training with the advantages of getting a CMS “out of the box”. Are you evaluating the time that you spent with the time that you saved? Developing a CMS from the ground up these days are just plain nuts. Every CMS provides content management, media management, search engine optimization, and other foundational principals that are missing from virtually every website we see that are home developed.

  22. Tim Kamanin says:

    I’ve been developing on Drupal for 7 years and what I tell you, whether to use Drupal or not depends on goals. For myself I understood the following:

    a) Use Drupal when you need to build a content driven WEBSITE for a client and when client wants to be able to move blocks, have access controls and stuff. Drupal gives you all this out of the box and tons of modules are to help you there.

    b) Use framework (Rails/Django) when you need to build an APP. Be it web app, facebook app or mobile app with web backend.

    So to sum up, use Drupal for WEBSITES and Rails/Django for APPS. Simple.

  23. Varun, you’ve said what some may not want to say, and it’s good to keep an open mind. I run a small Drupal shop myself, and Drupal is all we use. However, there are some projects where Drupal may not be the best solution. We usually provide honest feedback to RFP’s or simply decline those projects. But why decline? I’d like to consider some alternatives, such as Django/Python. Perhaps being too specialized can limit a development team’s potential. “Do it with Drupal” holds true to me still. And WordPress is still on my radar, although each of these systems and frameworks lacks something due to the fact that the same things are done over and over again, which is why I really liked reading this, about the “DRY Principle“: http://c2.com/cgi/wiki?DontRepeatYourself. Thank you

    • Varun Arora says:

      Thanks for your thoughts.

      DRY is a beautiful concept, but an engineering nighmare when it comes to the way Drupal-like CMSs are architectured. There needs to be a reasonable discussion and assessment on where Drupal falls in that spectrum.

  24. Seth Conley says:

    Nice to see some constructive points about where this platform falls short for complex (enterprise) implementations. Microsites, campaign sites, social sites are much different than developing business applications for the web.

    I only use TYPO3 for many of the reasons you have stated above. No other opensource CMS can really compare. However, as Muhammad Aslam bin Ahmad Suhaimi stated one must consider the requirements and then determine which platform provides the best framework for the project.

  25. Chris Reed says:

    After reading your article, I agree with your assessment of Drupal almost to the letter. I’ve tried multiple times to get into the framework, but found that the further you want to get away from their basic configuration and more into custom functionality, the steeper the curve became. Hopefully version eight will change that.

    My reason for posting though, is I’m curious as to the reasons that you chose to go with Django as opposed to other web based solutions out there, such as other PHP frameworks/other Python frameworks/Rails/Perl/whatever?

    • Varun Arora says:

      1. Willingness to have a scalable backend in a language that can support it, thus not running dev environments for different languages which become hard to manage all over the place
      2. Low dev time and easy debugging. Replacing Java in many CS programs across the country as “language of instruction”
      3. Community
      4. Is certainly the easiest framework by far I have come across
      5. No unnecessary CRUD views generation. Much more sensible in C & U & D with it’s admin panel approach – just like Drupal
      6. Documentation and libraries (Google supporting a language is almost a good reason in itself)
      7. It’s cool

  26. Pingback: Make your website your communications hub

  27. Wilman Arambillete says:

    I could not agree more with you. I went through the very same experience of programming with drupal for almost 2 years and it was a nightmare. The last straw was when I had to deal with groups. Taxonomy and groups are so much confusing that I could not continue with that. I hated it. My new reality: WordPress when a basic CMS is needed and Compound.js, Yii, Laravel or whatever MVC fits best for web apps.

    Very happy with this decision.

    In fact, during those dark months of Drupal, I had to make a prototype for a web app I then developed using Yii. Thanks God I took that decision otherwise I would be dying today to support all I had to do with that project.

    I left Drupal and despite this new comment in Hacker News (http://codedrop.com.au/blog/re-why-we-stopped-using-drupal-our-platform), I backup your position 100% based on my personal experience.

    Regards!

  28. Priya says:

    Thanks for sharing such a nice information, its helpful for me. I have you bookmarked to check out new stuff you post.
    Keep sharing.
    CMS Development US

  29. Frustrated with Drupal Webmasters taking weeks and even months to respond to a 10 minute project ownership transfer. The problems with the system are more apparent than when I started including the amount of bugs, lack of maintainership, and general politeness in many cases.

    Looks like Django…. or Ruby on Rails…

    Bye Drupal,

  30. Thomas Rendleman says:

    Django is great. Small learning curve compared to Drupal. It runs faster. No need for all these off the wall ways to test code. It’s simple comparatively. Switch from Drupal to Django and you won’t be sorry. It’s only been 2 weeks and I am 100 times happier. Thank you Drupal webmasters (sreynen) for being so unprofessional. I would have never made the switch without your bad behavior and I appreciate it more than you know.

    The bugs are few and the coding is new. Come see Django.

    Thomas Rendleman

  31. Sam says:

    Just curious as the article suggests knowing PHP is not enough to be able to interact with Drupal. 2 years with Drupal and I’m tearing my hair out on a very frequent basis with hooks/process/preprocess (WTF?!), although I have little programming experience, I decided to learn Python instead of PHP, hence my interest in this article.

    So, when it is said thay Django is ‘easy to learn’, does that really mean it’s easy to learn (if you’re an expert at Python)?

    • Varun Arora says:

      Hey Sam,

      I started learning Django after around 5 part-time days into learning Python. I still don’t feel like I learned a “new” language – it was that simple.

      Varun

  32. Pradosh says:

    You almost took my words “sweet spot where MVC frameworks and CMSs will converge”.

    I started with Zend Framework 5 years ago before I ventured into the world of CMSs and after learning Drupal which I am at the moment more full time devoted into. I always had a feeling if some how these frameworks could provide more than the code (not just scaffolding) but also some sort of widgets, bundles (symfony is great on bundles) etc. that a CMS like Drupal offers.

    I have never been more excited about Drupal 8 as it is using best practice that Symfony provides, then Drupal could be considered as an App Framework instead of a CMS. Something which Dried lamented about in DrupalCon Sydney 2013, why Drupal is not thought in the same vein as Rails for start-ups. Looking at Drupal 6 and 7 and on top of your comments, it is quite obvious why it has been all along.

  33. Tony P says:

    I am considering giving croogo CMS a go. Built on CakePHP MVC framework. It looks like a developers type of CMS. May be a better alternative to feature rich CMS’s like Drupal.

  34. John B. says:

    Have you tried, Prometheus on Drupal. It offers MVC within a Drupal 6/7.

    https://drupal.org/project/prometheus

  35. Helping this company start, specially guiding what to use and why, I come across this same decisions constantly. One hing I have learned in the time working with different projects using Open Source is that we will always have this discussion, is not CMSs, it’s not PHP, MVC, etc.

    It is a matter of specialization or not. Do I want to specialize or do I want to know many tools and have different “weapons” for different projects. Well… there is no perfect answer; I have been in both sides I have vouched for specialization and vouched for “generalization” (quoted since I want it to mean be able to use any or many tools).

    Today my experiences showed me that specialization is better, if you know your tool you can do ANYTHING, not to say it is better or you need to forget about the rest. But if you know your tool you can fix everything.

    it is god practice to choose the right tool for the right project, of course, but when resources are short and you need to be able to do everything it is better to have a Swiss army knife than a fool tools shed with several specialized tools. That is, if you know your Swiss army knife better than any of those tools.

    For us,that is Drupal! Is it complex oh my God!!! yes! will it do most of the common tasks of a web shop? Sure!!! is there a module for that, most likely!!! are we learning to use it for anything they throw at us? yes! is the best solution? nah! sometimes overkill….

    But since we decided to specialize we decided to learn how to tackle most of the common tasks with it. And that works better than having the few resources available trying to learn two or three different tools so we can use what we need when we needed.

    In other words our decisions was to take the company to be a Drupal expert and not a general web Developer and tackle everything as a Drupal experts, we do not let this transfer to clients the best we can of course.

    We decided for Drupal for it kind of “In the middle” approach, it is a CMS with so much out of the box but at the same time it isn’t since it has a lot of framework too. This gives us the opportunity to focus learning on one tool and be experts on it instead of trying to gain expertise in a couple of them. Maybe in my head I compare it to Queues theory. one learning queue, even as steep, is better than three easy ones since time won’t triple but worst.

    That is our approach, and I feel this posts comes from something I learned as a Martial Arts trainer and instructor… lately we have been training (my head instructor and a couple of us) our young people to compete for the Olympics and that means learning different drills and new techniques and my head instructor has a say that applies perfect to this topic. Every time we practice a new drill he tells us to do a couple hundred reps on any drill, listen to any advice, try to apply it and then decide, if it fits your fighting style keep it, if not let it go. You should use only what fits you and you can use fast and effectively. And coming back to this, if Django goes better with the way you feel more comfy developing a project, your tool is Django. or Drupal…. but if that tool does not align with your mental map, it does not matter how good it is, you won’t be able to solve much with it.

    We love the concepts of Drupal, love the “monetarization” model of the project,love the handle on creating new modules (the collaborate before create new module, etc) and that makes it better for us… we tried a couple, and could not pass the “Why the heck would they do this” or “it does not make sense to me”.

    You are right in your post, but the question is not what is the best tool, the question for a “computer expert” (quoted cause it may mean so many things) should be “What is the best tool that really works for me”.

  36. Well, after pondering this article, I realized our shop is a Drupal shop. I had never really thought about it in those terms but there you have it.

    We abandoned our in-house CMS about 6 years ago and decided to learn Drupal inside and out. The upside is that we haven’t experienced the frustration that the author has and have yet to run into a project that can’t be accomplished in Drupal. We eat, sleep and sometimes dream in Drupal so maybe we’re not all that typical. We’ve been building websites since the mid-late 90′s and I really can’t remember all of the sites we’ve built in that time.

    Since we adopted Drupal we have developed, launched and mainatain about 50 Drupal websites. The majority are smallish sites but about a dozen of them are for large organizations and are complex sites integrated with a CRM back-end for memberships, events, ecommerce, etc… You would think that maintaining that number of sites would present a maintenance problem but it really hasn’t. We use a selection of vetted modules (+ a few of our own) and we use the Drush tool to update the sites. Typically updates last a few minutes. Upgrades (D6 -> D7) take a bunch longer. Hopefully the new MVC platform will help reduce that in the long run but that remains to be seen in the next few years.

    I personally am very excited about Drupal 8 and the integration of Symfony 2. This will help remove some of the cruft from module code. You’re still going to need to know how Drupal works because it is the foundation and does a lot of heavy lifting but using Drupal as a platform for developing on will be much better organized with the MVC and OOP direction that’s being promoted in D8.

    So I guess I’m glad you love Drupal and sorry to hear you’re giving it a rest for a while. Maybe you’ll come back when D8 arrives (and stabilizes). You aren’t going to loose anything from leaving Drupal and embracing other technologies or methods. Who knows, maybe you’ll come back and enter the Drupal world reinvigorated or maybe you’ll stick with Django and Python. Nothing wrong with that.

    Cheers,
    Andrew

    • Michael Stevens says:

      Yeah, until you want to add a custom field in ubercart checkout. Something that would take me 3 mins anywhere else, takes an hour + in drupal. I guess I would dream about drupal and it would be on my mind all day, because i spent all day doing simple tasks! Drupal slows down the development process, makes things harder etc. I think the people having trouble understanding that lack real programming skills!

  37. Bèr Kessels says:

    A bit late to the party, but I got pointed to this article by a friend, only now; I made a similar decision http://berk.es/2012/10/01/farewell-drupal/ a while ago.

    No start-up can afford a high initial learning curve

    I’d like to go further: No start-up can afford a high learning curve. Which is important, because in all the eleven years of Developing with Drupal, each and every new project, site and implementation that got on my path proved a steap curve. You point our something similar; about having to re-learn the stack over and over again. That too, is worse, because it not just core and contribs that require re-learning after each release. Each combination of modules requires new learning.

    An recent example (as a Rails developer): Getting to show Campsites on a map, making them searchable by distance and whatnot. Quite ordinary Geo-stuff. In Drupal, that would involve learning and implementing several views-addons. Gmaps, module and learning how to combine all these. When you look at stackoverflow, or drupal.stackexchange, you find that a large portion of the questions is something like “I have FooBar module and Foozbaaz, how do I get them to FazBooz?”.
    As a rails-developer: I pull in some gems and develop all the geo-stuff the way I am already used: active-record, OOP, some views, some helpers and that is that. It is far more predictable and follows famous patterns.

    This is but one of many reasons to leave Drupal (and other CMSes) and do what I do best (and like most): develop. In a Development-Framework.

    Nice to read that others have the same issues as me. Even better to learn that you manage to word them a lot better then me :) .

    • Hi Ber:
      You’ve just used as example exactly a feature I had to deploy on a project I’ve worked on some time ago. Just bear in mind that when developing the functionality in a framework such as RoR, you would be doing exactly that: ‘web development’. While to implement the same functionality in Drupal, you should not have to write a single line of code. Provided that you are an experienced Drupal builder, it should take you a couple of hours of work. Can you learn Ruby + Ruby on Rails in two hours?
      ‘high initial learning curve’ : it’s a relative and subjective concept. It also depends on what your background is. You choose the tool which is more convenient based on your knowledge, the project at hands.
      At the moment my two web platforms of choice are Drupal 7 and Laravel 4. Often it takes me a lot of time to decide which one is best for the job at hand. Laravel can be learned in 2 or 3 days. Drupal takes considerably longer. Nevertheless, until I delve deep into a project architecture I cannot be sure which technology would be the most appropriate and faster to develop.

      • Bèr Kessels says:

        While to implement the same functionality in Drupal, you should not have to write a single line of code.

        People often present this as if it is something good. It *can* be a benefit, sure. What is it, that makes “not having to write a single line of code” better?

        In no particular order, this is what I have heard:

        * It allows less experienced people to participate (also known as: I don’t know how to code, but I can still build a site).
        * It is faster.
        * Requires less effort.

        I agree with the first. But wether or not this is an actual benefit, depends mostly on the kind of project: yes, for your small e-commerce, or bootstrapping startup, that might suffice. But certainly not for a governmental site.

        The last two issues, are, as I have been trying to explain, simply untrue. Yes, there are situations in which pulling in a (well known) module by an experienced Drupal-developer is fast. But there are just as many, if not more, examples where this goes completely the opposite site: just have a look at nearly every question on Drupal Stackexchange. Difficulties and issues arising from combinations of modules, configuring modules in unique ways, and so on, are causing 90% if not more of the entire development-effort of just about every Drupalsite where people “don’t need to code”.

        You seem to acknoledge the same problem:
        Provided that you are an experienced Drupal builder, it should take you a couple of hours of work. Can you learn Ruby + Ruby on Rails in two hours?

        LMFTFY:
        Provided that you are an experienced Rails developer, it should take you a couple of hours of work. Can you learn Drupal with most of its modules in two hours?

        You are comparing apples and pears. If, and when, your project requires development effort, a framework optimized for development is simply always the best. Whereas, when you have a simple, predictable and off-the-shelve site, using an off-the-shelve CMS with minor configuration is always the best. And inbetween is the grey area in which sometimes a custom-built tool will be the best, and in other cases, building on a CMS is the best.

  38. Anton says:

    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.

    • Avenida Gez says:

      WOW!!! Your are just right, precise and concise.
      May be the word programmer fits on everybody who has commented this article, but I would call them System Integrators, which of course it is a great deal in that arena, but are far form being programers in the context of a pure language, name it PHP, Python, or whatever. Even if you know a framework from top to bottom that does not mean you know and understand the whys, why have to code this PHPO module this way and not another, why a database schema is this way and not another, and that is what system integrators try to avoid using frameworks and of course it is little what they can do secure and fucntional outside the framework. Ok, ok, copy this routine or this code from the framework and lets do this… ups, it does not works or does not fit, why? I have to learn more about the framework because it seems I did not understand it? NO, you need to know how really things work, like the Internet, the browsers in all their brands and versions, the sql server and all of its settings, multibytes and no multibytes functions, bla bla, a framework will never be on top of a language and and there is a reason why a language does not include the functionality of a framework.
      I see this discussion as which spreadsheet is better for programing? don’t use a spreadsheet, use a wordprocessor(non sense)

  39. Eric Corriel says:

    how i explained the difference bt symfony and drupal to my boss:

    the diff bt symfony (where you’re given a framework sandbox full of sand) and drupal (where you’re given a sandbox replete w lots of pretty sandcastles) is that w symfony you have to know how to build sandcastles from the ground up. since, in order to do so, you have to know how everything works, you end up w a complete understanding of the system, which ultimately makes for a much more manipulable sandbox. w drupal, the second that you–a mere mortal–have to move or change the preexisting sandcastles that god built, you’re in for a world of pain.

  40. For traditional front-end content delivery, Drupal or WordPress are a safe bet, but for application development, there are now a lot of developers using EmberJS and AngularJS, etc to transfer view construction and even data modelling to the client side. The servers in these cases become more or less a CRUD and authentication processors, so it doesn’t really matter whether you are using Ruby, Python, PHP far less Drupal or whatever, so long as the server can receive and deliver data in JSON or XML and/or can work as a rest server. In the apps I’m building now 70% of application code (logic, modelling, view constructs) is client side. As the demand for mobile versions of HTML5 apps is increasing rapidly I see this as growing trend.

  41. Cynthia says:

    I am reading your posts with great interests as I tossed and turned all of last night, trying to decide if I was coming back to Drupal after a stint with WordPress. Unlike you folks posting here, I did not earn a degree in CS. When I graduated, they didn’t have such degrees! :-) I have been working on a computer since before little microsoft icons appeared on the screen and annoyed me. I was among the first group of people who mastered hand-coding in a vanilla editor and was among the first people online when we called it the Wild West, ready for the first building. I’ve gone through all the stages of internet growth and now I’m at a wall, for the first time.

    I was “forced” into Drupal about 8 years ago when a university client demanded it and I foolishly thought I could do it. I nearly became a bald drunk. I began studying PHP in the evenings. I get it; I don’t write it; if I’m stuck I can spend hours/days but eventually figure it out. It took 14 months but finally the university site went up and I loved it’s feature-filled pages. I finally mastered the basic modules needed in a Drupal site, moved to an install of multi-site, and even, if you can believe this, dove into BOA install on Ningx a couple of years ago. Now that is hard (for a non-developer)

    I am not, though, a writer of code. I do not have a CS degree. I am not dumb, which I wish I actually was, as it would be easier to not think sometimes.

    That said, I have no idea right now which way to turn.

    WordPress drives me nuts after living inside the Drupal community. It’s great for the small client who wants a simple site — grab a theme, go, they like you. I didn’t even read the documentation, which stunned me. But WordPress is a different world. Anything you want that’s good, well, you are going to pay. It nickels and dimes you to death, imho. And to do customizations under the hood, well, that requires jquery, javascript, php knowledge at a higher level than I am at. So if you stick with the front end of development and don’t mind living in a boxed world, you can be happy.

    But I am trying to build a site that my one-person business will own. And every time I turn around in the WP theme to create what I want — I’m back having to look under the hood — or to buy something else. Right now, the WP theme I bought can’t be coddled into what I want (something I didn’t know until afterward) unless I get my hands dirty with code. Theme-installed custom shortcodes are a landmine to me. Change your theme and you lose ‘em. And what these themes can’t do is ridiculous to me, given my Drupal past. I feel like I am in a box, screaming!

    With Drupal, I can do what I want with a site heavy with content that is both static and bloggy. I can create any which way. I rail against modules and fight them with them. But that’s different fight for me than wrestling with someone else’s code. I find myself within a strong community where user names become known and people collab.

    Drupal lets me build what I want, how I want it, where I want it, but with a lot of heavy effort and grunting. It’s a slow build and I need fast.

    WordPress lets me build what the theme creator wants me to build, in the manner they envisioned it — accompanied by constant purchases, it seems. It’s got a no-brains console and click and install updates of everything (wow..that’s not the Drupal way..what ease.) It’s a fast build but I sacrifice what I want.

    I’m not in a position to hire a developer. And my ego is in the way. I want to do this.

    But dang…which way to turn?

    How I wish someone would step and blend both worlds!

    Today is decision day as I have to move forward. It was a sleepless night. I have a yearning for Drupal but….

  42. Pingback: What is a Spruce Goose software project? | Smash Company

  43. Pingback: Drupal is bloated software | Smash Company

  44. Ahmed says:

    Nice article about comparisoning drupal and laravel:
    7 Reasons to swrich from Drupal to Laravel

  45. Glenn De Backer says:

    I must say I started at a job as Drupal developer more then a year ago and it has been a rocky ride. I especially feel what you are saying about “reverse development”. While a lot of frameworks or projects has (more or less) adopted the same concepts or patterns, Drupal has it’s own (sometimes plain idiotic) ways. In comparison with my previous jobs it is sometimes a lot harder to get to a certain point.

    I sometimes have the feeling that I’m spending more time to get things done the “Drupal way” then the complexity of the problem itself, or that I would be already finished if I started from scratch or could use another framework. That being said for my personal projects I don’t use Drupal.

    This year I tried the difficult task of designing a SPA (Backbone) with Drupal as the backend as the requirement was “must use Drupal” and in the end I ended up (without hacking the core mind you) of disabling and moving a lot of stuff. It works (and not that bad to be honest) but it was sometimes a really nuisance.

    The “there is a module for that” attitude I sometimes have a lot of troubles with because there are a lot of low quality modules out there. It is sometimes difficult for somebody who is a bit a perfectionist.

    And I’m Belgian and as Dries Buytaert is Belgian it is adopted by a lot of firms here, it is not that I have a lot of choices. So I have hopes that Drupal 8 with the adoption (which is not dead, it is really a nice framework) to incorporate more industry practices.

    I’ve been to DrupalCon Prague and I really liked what I saw regarding D8.

  46. Karim Ahmed says:

    Interesting article.

    When I developed with Drupal I found the same problems you described with the database structure and steep learning-curve. It wasn’t financially viable for me to use it and I didn’t like the level of abstraction between the application and underlying database structure.

    For me, designing and tuning the database schema and related SQL statements is an integral part of application development. Having the freedom to write SQL statements in your application code means terse, readable code that can execute quickly and efficiently against the database server. You can also then take full advantage of the database server optimisation tools and features such as statement execution profiling, cache tuning and indexing strategies.

    Drupal (and may other frameworks besides) drive a big truck through these options by deliberately abstracting access to the physical database.

  47. Pingback: The Dangers of Using a CMS to Build Your Enterprise Application | Custom Software Development & Consulting | Programming Services | Surge

  48. Matt says:

    Drupal gets 75% of a reasonably complex site up and running in no time at all; it’s remaining 25% that I’ve struggled with in order to match web development briefs.

    Used within its, and the developer’s technical ability, Drupal is excellent. Right tool for the right job, and all that.

  49. Tom Deluga says:

    You are right on point. As i have used Drupal for years, i never use it in my personal projects, or projects i work on as a freelancer. But I haveto use it at work becuase we are required to use it for all client projects.

    Now this problem has many sides, and im sad that the only point the company i work for see as value for Drupal is the UI part, thats easy for the client. But the rest is exactly like you pit it, “reverse development”

    But the more serious problems i see with Drupal is the technical debt that it gives the developer. I see devs who have worked for years in Drupal, but have zero knowledge of PHP and design patterns as a whole, devs who has no knowledge how to do anything other than drupal hooks.

    This leads to a very narrow skillset, and it hard to loose the drupal way developing. Many modules are also of very poor quality, and usually theres no tests at all, the fact that Drupal encourages no testing is horrible. Actually, it is untestable in many parts.

    So, if you are as me and haveto work with Drupal, i highly encourage you to learn other programming styles on your free time, or try to convince your bosses (might be impossible) to concider something else as an platform besides Drupal.

    I have used some symfony components, and i really hope drupal 8 will be of better quality. But im not that hopefull that the core ideas will change too drastically. Last time i had a look at drupal 8 it had the same hook mentality, so the reverse development side seem to be left in the core.

  50. Richard Eden says:

    WordPress is for anyone. A three years child can install and fire it up. Drupal is focused for developers. But they are all good if you see your project is not going to get too complicated. I have dealt with many frameworks and I can tell it for sure. The starting time frame is very promising and that’s what kills all the businesses. They do not see the near future cost of development because of huge customization. For ex: you can make an initial version in 6 months let say 80% of the work. You will end up seeing spending next two years for 20% changes.
    Part of the reason is Drupal is extremely slow in development. Because of the architecture. We have worked with top Drupal developers around the world. Yet we have the slowest drupal site. When you deal with complex sites you can not win with these third party CMS. Worst part is dealing with problems. It makes hundreds of tables and joins. Never efficient strategy. Drupal team didn’t have any choice because there is no way you can make something that will fit everyone without going in this route. But when something is built for everyone also means it may not be for you. So you should see your projects future.

    Don’t take my word, just google it for other peoples thoughts. Drupal saves everything in DB. Bad bad idea. Everything is in array. another bad choice. That’s why most drupal site suffers suffocation and memory problems. I have worked with 15 large Drupal sites. For every single thing you have to do alter. Another worst nightmare is it goes through every function in every page load. I can’t believe why people still says it’s fast unless they are blind sided.

    Now Drupal team says it’s enterprise ready. I disagree. Never seen such a slow site. You can make your public site super fast because it all runs off memory and caching. But in development statge it’s slow like hell. If you plan to make a heavy database based site. Your just spending nearly 3 times more money on it in terms of cost. Now yes, all Drupal lover will be on favor. I love Drupal too. But I have also seen the both sides of it.

    Real fact, we have hired worlds top drupal developers to make a cutting edge drupal site. They did it in a year. It’s a complex site. Now for every single thing it’s taking them forever because everything gets in your way. Because you can’t do anything without following Drupal way. As I said, it’s very good and best choice for simple project. Never ideal choice for large enterprise. If you chose it, you will see what I mean in few years.

    Now what is the best way then? good question. If you have enough resources, go with just a well known easy MVC framework over Drupal. I don’t recommend WordPress either because it’s not MVC or OOP. To tell you the truth, building a site from scratch is not such a difficult thing either as long as you have good expert developers who knows how to architect.

    For those who has limited budget then it becomes a tough choice to pick the right path. Chosing wrong path may cost you fortune down the line.

  51. Jennifer Houston says:

    I also agree with some of the people here. Most drupal developers have very narrow skillset and they can not think outside of the hook system. Which makes them very weak in developing anything other than Drupal. In a way it’s just parallelizing developers. Besides Drupal 8 different than Drupal 7. So you have to learn a lot of new things again. spend a lot of time on learning. In my opinion, it’s for lazy developers who doesn’t want to do creative things. Drupal or WordPress is great. No doubt, but should not be considered for all applications. For larger on going applications, it does more harm than good. Only an experienced visionary developer can foresee the problems running into Drupal sites. I also developed several drupal sites. They are great but when client wants anything everything then Drupal is just a pure nightmare to go with. Those who blindly love drupal, I have no words for them.

  52. Mukesh says:

    For those who love features module you have seen how nightmare it brings when you have a big site. It does have some great benefit. But why do you need that? How difficult to write the code? Why even let a tool generate the code and what are the chances it doesn’t do weird things? Which it happens when you have a bigger complex site.

    Good developer should never rely on any tools that generates automatic codes. Bad choice bad idea. Not only it can break your site it also does things you have no idea at all until you find out six months later.
    Besides, why you have to keep altering everything when you can directly alter the form or code.
    I like the database wrapper. But how big deal is that to write one of your own or grab one from off the shelf what is much easier to use.

    We have been struggling for last two weeks to figure out some weird queries it generated. Because everything is stored in the database we have hardly control over it. We are at a point we can’t roll back.
    Seriously, why you have to store everything in the database if you are a developer. That’s good for novice people who doesn’t know much about programming.

    We are at a point to pull our hairs for choosing Drupal at the first place.

  53. Rohini Bannergy says:

    My boss just told us yesterday to scrap our current Drupal site we built for last two years. He says it’s taking us too much time for on going feature additions or fixes. Even though I feel bad throwing out all the work I did for last two years most of our team is kind of happy to do a fresh start from scratch. Fortunately we have a developer who is bright enough to do design from scratch. That’s why we are moving into that direction. Some says, why re-invent the wheel. We aren’t going to re-invent anything at all. Instead of using all Drupal we are just going to utilize all open source generic PHP tools libraries so we have the full freedom. Even though it might actually sounds a lot. But if you put all the pieces together it’s not really much work at all. Because you do not need all the features comes with Drupal or WordPress. It’s designed for everyone and nobody needs everything.
    We were so excited two years ago when we started this site on Drupal. But last one year our over all output turned into less than 50% because we just couldn’t do simple thing in simple ways. Drupal just stepping our foot every way to follow Drupal way.
    On the bright site, no site is permanent. People built site on Drupal 5,6. Those are worst than what you would do alone now a days. So things will always change. You just have to do something good with time/resources available. Most drupal developer don’t see the future changes. They all get very excited how easy it’s to start with it. That’s the main selling point.
    All though I’m hesitated to start fresh with scratch but most of my team member thinks it’s best for all in terms of future growth. I guess when you have resources available you can easily go with brand new strategy over Drupal. I probably would never do fresh start if I was doing all alone. But also agree that it was taking us significantly long time for silly changes to apply lately.

  54. James carter says:

    Drupal needs a very steep learning curve. The time you would spend the benefit is far less than that. You don’t really need to be a drupal expert to develop a site. A lot of times it’s a hype but nothing.
    Drupal does not let you do your own data structure.
    It creates hundreds of tables and generates complicated SQL queries. If you get into trouble with your site, it turns into nightmares because of that.
    Everything runs off caching. Which is highly inefficient for development.
    Even though Drupal 8 is taken on OOP , most sites are still on Drupal 7 and it’s all procedure based. Really really bad choice in 2014. You should be doing at least OOP for everything.
    Drupal gets your way on everything.
    You don’t learn anything but Drupal and you don’t grow much outside unless you always want to do Drupal. Because you are going to spend lot of time on doing Drupal way for simple thing that you won’t have time to catch up with rest of the world.
    You may ask, so what’s the solution?
    If you are really doing a small site and not expecting to do lot of development down the line then go ahead with it. Otherwise you should always use some other MVC framework such as Zend, CakePHP or something that will save your time in URL rewriting, ACL, Templating etc. You can also build from scratch if you feel comfortable. You may also ask why reinvent? well there are thousands of benefits building from scratch.
    Yes there are benefits using Drupal. but it’s very slim compared to the work you will end up doing. My personal opinion is, I want to be in charge of my data structure. I don’t want any tool to make it’s own tables and keep joins and then I have hard time fixing any on going issues.
    Yes, you will say this… “oh how come some big companies using it then?”
    Sure, wouldn’t you always go for something you are good at it? it’s always whoever in charge to make decision. It has nothing to do with right or wrong. If you are a Ruby expert you won’t chose Drupal. Would you? and tomorrow if you get hired as a CTO of a company , you would probably aim for Ruby for everything. It’s how it always works.

  55. John says:

    As someone who decided to initiate a startup prototype using Drupal I can relate to everything you say. Before I chose a method I had a quick look at Drupal’s existing contributed modules and thought it would make my life easy – everything came free and I could harness the brain power of others. Unfortunately, I have spent the equivalent time of doing it myself patching (sometimes huge) bugs and finding workarounds to missing features or clashes. I honestly find it hard to believe anyone has ever built an enterprise scale website using PostgreSQL based on the unresolved bugs I have encountered (overly long db index names among them).

    Drupal is fun and rewarding but it can take a lot of time doing it the Drupal 7 way. Even for a simple content-based website it also feels unethical building a website in Drupal for a budget operation (like a charity) – without an ongoing support agreement they will be shocked at the subsequent quotes for Drupal experts (at least in Australia, compared with WordPress devs). And the scarcity of documentation for the most popular contrib modules and their APIs) was almost hard to believe at first.

    For me the hardest part is abandoning Drupal just when one gets the hang of it.

  56. Having worked with both Drupal and Django, I feel encouraged to express my opinion: Drupal is a great CMS solution. Django is a great framework solution.
    Translated: if you need to build a kind of typical website with lot of articles, posts, pages, groups, comments and even simple e-commerce go with Drupal and just use views, panels, organic groups. If you need highly customised and original functionalities, go with Python-Django and your life becomes much easier, unless you already are a Drupal ninja.
    Thanks for sharing your interesting ideas.
    Pietro

  57. Interesting Article!!! I worked with both Django and Drupal. So, both exactly having same only,, nothing difference between in both.

  58. Rebecca Morris says:

    Agreed with Carter here. Drupal is fun and great for things out there to use without envisioning lot of work or maintenance down the line. And this is where it gets very tricky. Hardly anyone thinks that part which makes the very obvious choice to pick Drupal or WordPress based on the flavor. But if you have a complicated site and you want to maintain and keeping adding new things. You will need a Drupal ninja. Which can be far more expensive and time consuming. I have seen Drupal can very difficult to work with sometimes even with simple one line change. Drupal developers are extremely expensive to afford because it’s one of those framework takes a huge amount of time to catchup. Honestly, one can become in PHP OOP in far less time than Drupal 7 which is in my theory and old technology because it’s procedure based.
    At the it doesn’t really matter what platform you use. You can even make it on WordPress or some other platform people suggested here. All it matters whatever is best for you in terms of cost and timeline. Because more or less they all give the same output. Some are easy to start difficult to maintain and some are difficult to start and far easier to maintain. It’s a tough choice for those who don’t think the future outcomes.

  59. Peter Chao says:

    huh!! I thought I was the crazy one to dump Drupal. It was so exciting when we started with Drupal and it’s all cool features such as Views, Pathauto, Panelizer. Awesome!! Awesome!! Yay!!!
    As we started building components we realized, these are just doing a lot more damage than good. Because if you are a developer, you should never depend on any GUI query tool. You should have full control over the query and build your own query for complex data structure.
    Drupal will not run fine in commodity hardware. Even though they say it will. It’s it’s all cached. We dumped our two years effort and new building completely using few different open source components and modules. We basically assessed what we need and we might need. We realized we don’t need 100 million CMS features. If fact nobody does. We are now very happy and our development time frame increased three times faster than before.
    So guys, please give a second thought. I also agree with some people here. It’s great for sites don’t need lot of maintenance or on going development. We could have done the same site in 6 months where it took us 2 years. We did everything faster at the beginning like some people here. But then everything slowed down like hell. Specially features module. It’s such a beautiful thing at the same time nightmare. I would rather not even use it.
    Drupal is extremely slow. Whoever says it’s fast it’s just 100% lie. They are saying because drupal cache everything and that’s why it looks like its fast. But if you run on a commodity hardware and have a complex or many rows of data. You are screwed big time.

  60. Monica says:

    I loved views. Then when I had to alter the views. Oh god! it was taking weeks to figure out how to fix or change. These features are awesome if you can use “as is”. Changing? forget about it. You will need Drupal rockstar to make changes that views ui generates for you. Why bother then when changing becomes such a nightmare?
    It made me very lazy in query building and learning processes. I found out I was lacking and going behind in all other areas. I was occupied doing things Drupal way. It seemed Drupal jailed me doing everything Drupal way. Where rest of the world is moving towards OOP. And I’m battling with Drupal. Well, it’s our company foundation. Nothing I can do. I know Drupal very well. It’s just so much time consuming in general for complex view/module development. You get the easy part when you first build the site. Which is what everyone sees. No one thinks what’s coming towards them.

  61. Jason Perer says:

    I kind of agree now that I read some of yours opinions. I feel like I am not learning anything new but Drupal. And I can’t upgrade my site to D8 because it’s too complex. Not worth it.
    I regret choosing Drupal. Where we should focus on cutting edge OOP stuff and I am stuck at procedure bases D7 for years. Oh boy!!

  62. Robert Collegun says:

    Worst part is development time. If you have a heavy site everything becomes slow as hell. If you turn off cache then it’s a pure time hogger. No way around. If you have cache enabled then you won’t see changes immediately. drush clear cache takes long for larger site. Tired of it. Regretting why even picked first place for site like this. I didn’t have any significant issue with my previous smaller sites. But this is kind of a heavy big site. So I do disagree if it’s ready for enterprise. The way I see they push you to use Acquia which is owned by Drupal team. They rely on heavy hardware vs high performance coding. You can always run slow crappy code on a high end machine with faster performance. That’s not really efficient programming. The ideal site should run faster on a commodity hardware.
    I am in Drupal world for 7 years. For this site I even hired professional drupal nerds to optimize. I got slight improvements. But nothing as close as I expected. Now I have a million dollar site with extremely slow performance which is highly dependent on powerful hardwares which is also very expensive.
    What a nightmare…

  63. Tom Bisconti says:

    Remember one thing, every piece of code is disposal. No matter how best you write. The way technology is evolving nothing is set for long term. You aren’t probably going to keep or use the same code you wrote 3 years ago. The end goal is to focus on output with efficiency vs being too paranoid about any framework. If you have done a site in Drupal 5 which is worst than what you can do alone now days. Things always changes. You should always focus on building site with efficient budget, time frame vs completely tied up with any framework. I do personally prefer Drupal. It’s a great framework. But like everyone says, not every framework is for everyone or every project. You always have to judge what is the best route. Just because something is new out there or a lot of people using it does not necessary mean it’s the best choice. If you have a small budget , smaller time frame site with no custom development then you might just use wordpress to save everyone money and time. So it’s all depends.

  64. Tom S says:

    I was a part of a company who had made the switch to Drupal from a Java based CMS, they all praised the simplicity of Drupal, and as time went by they hired more “Drupal developers” and made more sites. The quality of the sites is so poor that it makes my knees shake. The Drupal devs have zero knowledge of anything else but copypasting code from forums and SO.

    My time at the company made me decide never to work with a Drupal only company again, it was really that bad. And the choice has paid off, big time. Now i work with modern tech, and im surrounded by developers who really have the passion needed for delivering modern solutions that scale and are maintainable.

    So if you are in a similar position i was a couple of years back, and want to grow as a developer take some time to think about your future self.

  65. I loved your Article.

    I have worked for several years with Powerbuilder as the Front-End, pure Java with Apache as as the logic and Oracle as our Database for a big company in big internal projects, usually not web-based projects. We also had some Websites but using Java JSP’s and Servlets. I always found that it was so frustrating to do it he manual way.

    Then I had to leave the company and a friend of mine asked me to do a simple website which had to deal with different types of users searching different types of information and different types of roles of users to get in touch using that information. I thought that Drupal would be the best bet because you have Out of the box all this things that I needed … the first time I installed It I was like: WOoooooow, I just created a view the automatic way: What I just did would have me taken 2 or more days the “old way” because I had to do monually al these SQL Checks and Data Checks … but then the problems began and I could not do this join of data with that join of data, and getting the ID of this Content Type is not possible with that Type of Data, and so simple things began to be sooooooo complicated things.

    I dropped dev. for some month (This was a favor for a friend so no money involved), now I am giving a last chance to Drupal for my friends Website, but Drupal 8 in Alpha Stage (I kind hate now Drupal 7). In only 5 days I did more than in 4 month, maybe because I am more used to Drupal, or because I have the help of a book, I do not really know.

    If Drupal 8 gives me the opportunity to control my data in different tables, I will still give it a try (but I think they keep all kind of data in the same Node Table). …. but chances are that I will go to a framework liken django, but I still didn’t found my perfect solution to what I want.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>