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++):
- 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.
- 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.
- 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!
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.
Not sure, Terje. I haven’t done too deep a research, but I am sure there are CMSs that are more developer oriented. Which is the direction Drupal 8 is embracing. Which makes me really happy
So what you plan to use instead of drupal?
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
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.
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.
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!
I think there a sweet spot where MVC frameworks and CMSs will converge. We await that happening with Drupal 8. Thanks!
My apologies, Axel. I have made an edit taking that back.
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
Thanks for sharing that, mamadou!
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…
My apologies, Josh. I have made an edit taking that back.
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
My apologies, Nilesh. I have made an edit taking that back.
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?
My apologies, Tom. I have made an edit taking that back.
Absolutely perfect,I worked with both Django and Drupal. And exactly had the same experience.
So, can you advice to switch from drupal to django. Or not?
Nice article.
I think what you call “reverse development” is commonly known as framework development.
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.
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.
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
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.
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!
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.
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?
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.
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.
Did you just call Symphony a dying PHP MVC framework? I wonder why, I see no signs of Symphony’s iminent death.
Sincere apologies, Capi. Totally took it back.
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.
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
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.
Exactly.
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!
sorry, i meant the above to be a general comment on the post, not a reply to the specific comment above. oops!
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.
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?
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
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.
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.
Also, not every website using a CMS today actually needs a CMS. They often may need just partials, templating, js, images, and URL mapping.
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.
You put in surprisingly simple words – thanks! Although, consider reading my response to Larry Garfield (above) on this decision making process.
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
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.
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.
Interesting. I almost fancy the opportunity of a stripped-down Drupal with a non-hookish dev environment. That would kick ass.
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?
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
Pingback: Make your website your communications hub
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!
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