Tech Blog :: Drupal’s increasing complexity is becoming a turnoff for developers


Aug 10 '11 3:23pm
Tags

Drupal’s increasing complexity is becoming a turnoff for developers

I’ve been developing custom applications with Drupal for three years, a little with 4.7 and 5, primarily with 6, and lately more with 7. Lately I’ve become concerned with the trend in Drupal’s code base toward increasing complexity, which I believe is becoming a danger to Drupal’s adoption.

In general when writing code, a solution can solve the current scenario in front of us right now, or it can try to account for future scenarios in advance. I’ve seen this referred to as N-case or N+1 development. N-case code is efficient, but not robust; N+1 code is abstract and complex, and theoretically allows for an economy of scale, allowing more to be done with less code/work. In practice, it also shifts the burden: as non-developers want the code to accommodate more use cases, the developers write more code, with more complexity and abstraction.

Suppose you want to record a date with a form and save it to a database. You’d need an HTML form, a timestamp (integer) field in your schema, and a few lines of code. Throw in a stable jQuery date popup widget and you have more code but not much more complexity. Or you could imagine every possible date permutation, all theoretically accessible to non-developers, and you end up with the 14,673 lines in Drupal’s Date module.

Drupal is primarily a content management system, not simply a framework for efficient development, so it needs to account for the myriad use cases of non-developer site builders. This calls for abstracting everything into user interfaces, which takes a lot of code. However, there needs to be a countervailing force in the development process, pushing back against increasing abstraction (in the name of end-user simplicity) for the sake of preserving underlying simplicity. In other words, there is an inherent tension in Drupal (like any big software project) between keeping the UI both robust and simple, and keeping the code robust and simple - and increasingly Drupal, rather than trying to maintain a balance, has tended to sacrifice the latter.

User interfaces are one form of abstraction; N+infinity APIs - which I’m more concerned with - are another, which particularly increase underlying complexity. Drupal has a legacy code base built with partly outdated assumptions, and developers adding new functionality have to make a choice: rewrite the old code to be more robust but less complex, or add additional abstraction layers on top? The latter takes less time but easily creates a mess. For example: Drupal 7 tries to abstract nodes, user profiles, actions, etc into “entities” and attach fields to any kind of entity. Each of these still has its legacy ID, but now there is an additional layer in between tying these “entity IDs” to their types, and then another layer for “bundles,” which apply to some entity types but not others. The result from a development cycle perspective was a Drupal 7 release that, even delayed a year, lacked components of the Entity system in core (they moved to “contrib”). The result from a systems perspective is an architecture that has too many layers to make sense if it were built from scratch. Why not, for example, have everything be a node? Content as nodes, users as nodes, profiles as nodes, etc. The node table would need to lose legacy columns like “sticky” - they would become fields - and some node types like “user” might need fixed meanings in core. Then three structures get merged into one, and the system gets simpler without compromising flexibility.

I recently tried to programatically use the Activity module - which used to be a simple way to record user activity - and had to “implement” the Entities and Trigger APIs to do it, requiring hundreds of lines of code. I gave up on that approach and instead used the elegant core module Watchdog - which, with a simple custom report pulling from the existing system, produced the same end-user effect as Activity with a tiny fraction of the code and complexity. The fact that Views doesn’t natively generate Watchdog reports and Rules doesn’t report to Watchdog as an action says a lot, I think, about the way Drupal has developed over the last few years.

On a Drupal 7 site I’m building now, I’ve worked with the Node API, Fields API, Entities API, Form API, Activity API, Rules API, Token API... I could have also worked with the Schema, Views, Exportables, Features, and Batch APIs, and on and on. The best definition I’ve heard for an API (I believe by Larry Garfield at Drupalcon Chicago) is “ the wall between 2 systems.” In a very real way, rather than feeling open and flexible, Drupal’s code base increasingly feels like it’s erecting barriers and fighting with itself. When it’s necessary to write so much code for so many APIs to accomplish simple tasks, the framework is no longer developer-friendly. The irony is, the premise of that same Drupalcon talk was the ways APIs create “power and flexibility” - but that power has come at great cost to the developer experience.

I’m aware of all these APIs under the hood because I’ve seen them develop for a few years. But how is someone new to Drupal supposed to learn all this? (They could start with the Definitive Guide to Drupal 7, which sounds like a massive tome.) Greater abstraction and complexity lead to a steeper learning curve. Debugging Drupal - which requires “wrapping your head” around its architecture - has become a Herculean task. Good developer documentation is scarce because it takes so much time to explain something so complex.

There is a cycle: the code gets bigger and harder to understand; the bugs get more use-case-specific and harder to nail down; the issue queues get bloated; the developers have less time to devote to code quality improvement and big-picture architecture decisions. But someone wants all those use cases handled, so the code gets bigger and bigger and harder to understand... as of this writing, Drupal core has 9166 open issues, the Date module has 813, Rules has 494. Queues that big need a staff of dozens to manage effectively, and even if those resources existed, the business case for devoting them can’t be easy to make. The challenge here is not simply in maintaining our work; it’s in building projects from the get-go that aren’t so complicated as to need endless maintenance.

Some other examples of excessive complexity and abstraction in Drupal 7:

  • Field Tokens. This worked in Drupal 6 with contrib modules; to date with Drupal 7, this can’t be done. The APIs driving all these separate systems have gotten so complex, that either no one knows how to do this anymore, or the architecture doesn’t allow it.
  • The Media module was supposed to be an uber-abstracted API for handling audio, video, photos, etc. As of a few weeks ago, basic YouTube and Vimeo integration didn’t work. The parts of Media that did work (sponsored largely by Acquia) didn’t conform to long-standing Drupal standards. Fortunately there were workarounds for the site I was building, but their existence is a testament to the unrealistic ambition and excessive complexity of the master project.
  • The Render API, intended to increase flexibility, has compounded the old problem in Drupal of business logic being spread out all over the place. The point in the flow where structured data gets rendered into HTML strings isn’t standardized, so knowing how to modify one type of output doesn’t help with modifying another. (Recently I tried to modify a date_select field at the code level to show the date parts in a different order - as someone else tried to do a year ago - and gave up after hours. The solution ended up being in the UI - so the end-user was given code-free power at the expense of the development experience and overall flexibility.)

Drupal 8 has an “Initiatives” structure for prioritizing effort. I’d like to see a new initiative, Simplification: Drupal 8 should have fewer lines of code, fewer APIs, and fewer database tables than Drupal 7. Every component should be re-justified and eliminated if it duplicates an existing function. And the Drupal 8 contrib space should follow the same principles. I submit that this is more important than any single new feature that can be built, and that if the codebase becomes simpler, adding new features will be easier.

A few examples of places I think are ripe for simplifying:

  • The Form API has too much redundancy. #process handlers are a bear to work with (try altering the #process flow of a date field) and do much the same as #after_build.
  • The render API now has hook_page_build, hook_page_alter, hook_form_alter, hook_preprocess, hook_process, hook_node_views, hook_entity_view, (probably several more for field-level rendering), etc. This makes understanding even a well-architected site built by anyone else an enormous challenge. Somewhere in that mix there’s bound to be unnecessary redundancy.

Usable code isn’t a luxury, it’s critical to attracting and keeping developers in the project. I saw a presentation recently on Rapid Prototyping and it reminded me how far Drupal has come from being able to do anything like that. (I don’t mean the rapid prototype I did of a job listing site - I mean application development, building something new.) The demo included a massive data migration accomplished with 4 lines of javascript in the MongoDB terminal; by comparison, I recently tried to change a dropdown field to a text field (both identical strings in the database) and Drupal told me it couldn’t do that because “the field already had data.”

My own experience is that Drupal is becoming more frustrating and less rewarding to work with. Backend expertise is also harder to learn and find (at the last meetup in Boston, a very large Drupal community, only one other person did freelance custom development). Big firms like Acquia are hiring most of the rest, which is great for Acquia, but skews the product toward enterprise clients, and increases the cost of development for everyone else. If that’s the direction Drupal is headed - a project understood and maintained only by large enterprise vendors, for large enterprise users, giving the end-user enormous power but the developer a migraine - let’s at least make sure we go that way deliberately and with our eyes open. If we want the product to stay usable for newbie developers, or even people with years of experience - and ultimately, if we want the end-user experience to work - then the trend has to be reversed toward a better balance.

Hit the nail on the head here.

Having a larger/robust API is not necessarily a problem. Drupal 7's problem is it has a lot of APIs, they don't all communicate, and they are not all documented that well (Entity API, JS layer, TokenAPI looking at you).

Drupal needs a thorough review for D8. To continue down this path is madness, as D8 could only double in size to deal with D7's shortcomings.

I agree with your points except I think that leaning towards enterprise clients is beneficial even for smaller sites. The enterprise sites will always be the ones funding most of the larger new projects, as has been the case so far. As far as I know, most of the main modules came from developers working on enterprise sites, bringing code they created while building those sites into a module and graciously spending time to put that back in the system.

Although I do agree that there is so much upfront time needed to create a small one off site (unless you're using a distribution out of the box), I do not see too many major contributions to the module system coming from small projects.

I agree with you completely. However, I think it's important to understand that Drupal has *always* been the most complex (and least popular) of the 3 popular PHP CMSs.

Part of what brings good developers to the Drupal community is that Drupal has a beautifully organized complexity.

I think the exponentially increasing complexity, major release over major release, of Drupal is a result of that same community.

Is the increase in complexity a result of the push towards enterprise adoption? Or is enterprise adoption the only path left for a CMS that is getting harder and harder for novices and individuals to understand?

Unfortunately, in order to simplify something complex, you have to understand all of the complexity, use cases, etc. which you rightly note is nearly impossible given the state of documentation. Good test coverage for all intended use cases would help a lot in a refactor.

I completely agreed about initiative. And look like you feel like 'CHX',who is one of the best tech knowledge in community, which even feel down and was so disturbed about the code.

Learning a whole new language is even easier than learning Drupal. The tutorials market still not competitive enough to be able to produce something very easy to understand hard stuff.

I will support if:
1.) Drupal Association do hire a team of full-time developer for this code task.
2.) Why Core Documentation can't be easy to read like commercial books? Can we have full-time real editorial to help work on them? And push those commercial books to be even better.

It will be the real benefit, if hire / bid process done right and transparency. Also, to me the $80-$100/hr working rate is WTF for normal business, it means not much dev do understand Drupal as the result of complexity. Good ecosystem should be more diverse.

There will never be a CMS that so hard to learn like Drupal, but I think there will be CMS that can be done 80% of Drupal with great usability within a few years.

Thank you for writing this. its nice to know i am not alone :)

You forgot to mention the sheer size of all that bloat. Say you want to create a new site. It's just a namecard type thing for your mom, where she can also have a gallery of pictures, cause she's into photography. That's quick and easy to set up, right? Wrong. You spend almost 15 minutes waiting for FTP to finish putting everything on the server. That's even with a good connection. There's such a massive amount of files, and FTP typically creates 1 connection for each file, that it takes aaaaaaages. Throw in CCK and Views in the lot and you're looking at almost 15 minutes.

That's the main part that gets me procastinating each and every time I got to make a new Drupal site. I set myself to start on it and... hup, gotta wait ages and either twiddle my thumbs while I wait for the 20-30 or so Mb (with all necessary modules for the use case I wrote above) to be uploaded, or I can start doing something else, which results in not working on that site as soon as it's uploaded.

That said, it's also true that the APIs can use some serious cleaning up, but also some serious documenting. Api.drupal.org is a great tool, but alot of the pages aren't clear at all and you're left to either using Google (which beats the purpose of api.drupal.org) or to toy around til you figure it out yourself. Alot of core functions and variables aren't documented either, or are poorly documented (both in contents and in style. Try reading the comments that pop up while typing in a function name in Netbeans. It's all messed up)

I love working with Drupal. It saves me ALOT of time over writing everything from scratch. But... at the same time, it tends to have me waste alot of time on stuff that could've just been done right instead.

PS: You forgot to rant about the Rules module. That thing's great in concept, but in reality near-unusable due to its gargantuan size.

You seriously need to get a host that gives you SSH access. wget and tar will make your Drupal life sooooo much easier!

Michelle

You seriously need to get a host that gives you SSH access. wget and tar will make your Drupal life sooooo much easier!

Michelle

It doesn't even have to be hosting with ssh access - I mean, even Godaddy and other low-rent hosts provide a file manager which will untar for you.

Damn... One of those sites IS on Godaddy, and that one took me the longest to put up. Was more than half an hour on there for a simple, basic gallery site. Never found a file manager or such on it, but then again, Godaddy's control panel / control panels is / are a complete mess. Takes me aaaaages to find PhpMyAdmin in there, too and I end up with several new windows (yes, not tabs, but windows).

Ever since trying to get my head around entities in Drupal 7, I've been worried about the same thing. I've been using Drupal for 6 years and have watched it get more and more complex with each release.

I've heard many of the core devs say this or that needs a total rewrite but the problem is trying to get funding to rewrite something that works, even if it doesn't work as well as you'd like. And, really, it would need to be a coordinated effort to rewrite all of Drupal at once so all the parts play together nicely. Getting funding for that is likely impossible.

Michelle

Hi.
I completely agree with author of this article.
I have 3 years experience with php programming and 1,5 - with drupal. I thought and think that drupal 6 - a great solution.
But Drupal 7...
It is too heavy for programmers to work with all this abstraction. For solving easy common tasks !!!
Еarlier I had created a lot of sites based on pure php+mysql+js and it was nice work for me. My clients had what they want.
Then I began to work with drupal as Im a freelanser.
And had not been writing my own developments - my own cms system for example, or online-shop. Using this from drupal.
If leaving drupal then I have zero for the modern sites(with its demandings).
I do not see my programming future with drupal 7 and do not know how to earn money as programmer working with drupal 7. It seems that drupal becomes only solution for big companies with many specialists when someone know just his part of system. But I am a freelanser this not my case...
I do not know what to do ...

Me too. I've been building with Drupal for 3 years (D6).
D7 has lead to massive levels of frustration.
Drupal 7 now makes it extremely difficult to make the simplest of changes and there are bugs everywhere. It seems like I've been playing "Bug Whackamole" for the last year.

I am now looking at Orchard CMS (I know, it's windows). So far, I'm seeing pure mvc elegance. Maybe Microsoft finally got it right with mvc 3 and the razor view engine?

"Also, to me the $80-$100/hr working rate"

Why crazy? Charge for knowledge and experience. People pay it.

But yeah, something is really wrong with D7. There are parts of it that are great, and other parts that are way too complicated.

Drupal needs to decide if its for the 'I just want a simple blog' audience, or if its for 'Im a developer who wants the ability to make ANYTHING' audience. You can't do both efficiently and I think D7 and Ben prove that in the argument above.

It shouldn't be a struggle to get Javascript to work with your module.

It shouldn't be difficult to figure out how to make Entities work (there are at least a dozen tutorials online and in books that DONT MATCH UP to documentation).

You shouldn't include an Automatic Updater with your product, only to tell everyone "dont use this because its broken"- who find that out not long after using it.

You shouldn't encourage people to upgrade to Drupal 7 if lots of critical things, like certain Tokens (node terms, node menupaths, etc), are absent.

A lot of the modules promising D7 releases on release day still have yet to make a release that works.

Views should be in core, along with CCK, Pathauto, Securepages, and WYSIWYG (with a Drupal tuned editor like WP has). That should be default D8 out of the box. Fixing/reducing API bloat might take longer.

Acquia just got $15 million in funding. Why can't a small portion of that be used to improve D7 and D8, which is the basis for all Acquia products, and get things on track?

Drupal, I love you, but sometimes I hate you.

Note that Acquia is contributing to Drupal 7 and 8, see this post: http://www.webchick.net/node/87

How can the core community work on both Drupal 7 AND 8?

Why wouldn't it? Work on Drupal 8 is a natural and logical progression from work done concurrently on Drupal 7 and it makes sense. Don't confuse what you call the "core community" with what you originally asked and that was in regard to financial backing by Acquia for which I gave you an example above. To me the core community are people who donate their time on drupal.org to issue queues, forums, patching etc...

Why not address the 9200 open issues and eliminate at least half prior to starting new development?

Try contributing before making snarky comments, then you won't sound like a child. Your one anonymous sentence conveys much more entitlement than you realize.

"Try contributing before $n"

This time worn Drupal community chestnut is poisonous to rational discourse. Telling someone they need to contribute 1. doesn't address the concern they put forth 2. doesn't further conversation in any way 3. is in itself quite childish.

Personally I think addressing the Bug Queue That Ate Calcutta (D7 core) before adding even more complexity to the CMS is a perfectly rational proposal. I invite you to explain to me where cleaning up the house before adding additions is a bad plan.

Note: I've co-maintained 9 contrib modules, supplied code to 12 others and I've got code in D7.

No, Acquia do contributed.

As the community, we should not expect any company to be the main drive force. I see there should be a way to make DrupalCON a business to fund Drupal development, or something that's belong to D.O., not a company.

If there need to be funded by company, it should be D.O. who managed and make some rules about it. Otherwise, there'll always be flame war, like those Linux core, when company do share differently.

And for $80-$100/hour, I means there should be more diverse range like $10-$250/hour. Any thing in this world work this way, it's the indicator of healthy free market. But it's stupdly hrd to find good service below $70-$80, you may say that people pay for knowledge. But in business, the more leverage the better.

Do you think those Apple products suck because it made in china with low wage worker? No way, Apple make money more than many country GDP in this world last year. And the real business is going to be subscriptions, not the product itself.

If done right, the development should be as cheap as possible to get most customer. And the recurring payment is where money is.

Edit: did not mean to say "CCK in core" above. It already is. I meant to say "Context".

There's Butler project:
http://drupal.org/project/butler

Where have you been?

Not the same as the Context module.

Sorry, context module will not become core.
Take a look at the code, they're mostly just boolean.

Also, not to discredit maintainers. I know its hard to release modules when the API keeps changing, and the new stuff isn't that documented to help you get converted to D7.

I am primarily a Drupal themer but because I am a one person shop, I often build and customize sites for clients. I love Drupal and have had immense success using Drupal 6 and many happy clients who refer me to others and come back for more. I have been able to really dig down, do custom node templates, views templates as well as some custom functionality with Drupal 6.

Admittedly, I have been hesitant to jump on the Drupal 7 bandwagon for exactly the reasons outlined in Ben's post here. Sure I often team up with other developers on projects, I really like working collaboratively.

I have a new upcoming project that fits the specs of using Drupal so I need to decide if I will use 6 or 7. In a way Drupal 6 is a no brainer because I know out of the box I can do the project. But for me Drupal 7 is still somewhat of an unknown.

Certainly I have played around with it in my free time so I need to decide if I am going to get serious about it. Things like the Media Module for Drupal 7 are a good example, embedded media in Drupal 6 works like a charm so I hope that when the time comes, modules are a bit more in order for Drupal 7.

Great post, thanks!

I was all set to dive into learning PHP and Drupal with 7.

Now I am hiding under my sheets.

If I could gave a advice to two year younger myself I would say:" Do not connect with Drupal. Do choose php+zend".

If things like this - http://drupal.org/node/942782 are not fixed how ppl want to work with D7 ?...

" I'm using latest i18n with DA and having BIG problem with drupal MENU. This is actually a CRITICAL issue cause without some core hacking/custom module installing u can't get to the site content... I hope it will get FIXED soon cause now you have to use 7.4 witch #101 patch to get your site working."

" How is this _not_ critical? How can it be ok that in 7.7 you _cannot_ have a multisite setup with more than one level of navigation (since you'd have to create custom menus for each site)."

and there are many issues like this one...

Drupal is a great tool and u can do everything thanks to it, of course this is occupied by more complexity - it's natural in this case, but don't get the complexity of things get to hight cause it will be the drupal COMMON open source CMS end.

The Menu system has been a complete pain in the ass since Drupal 5.

About drupal issues - check this one http://drupal.org/node/691078

they are many modules related to this one... they won't move on until it's fixed. I hope some day drupal developing community understand that the adding new, new, new things, won't make drupal better. But upgrading old ones and help develop crucial modules (like token) makes ppl happy. New things should be added after many hours of thinking how they impact some things and only if they are well tested and documented. Drupal is a great cms a hope it will better and better. But after half year of D7 live even now it's "not completed" and I don't move from D6 to using it.

Drupal developers should seriously think about multisites. Thx good for DA but it has some limitation. I think multisites are the future of CMS. And at the moment we speak drupal DB and many core functions are in COMPLETLY wrong directions to achieve it.

Well since I'm mentioned by name I figure I may as well comment... ;-)

One of the "Aphorisms of API Design" I mentioned in my Chicago talk was "There is no problem that cannot be solved by adding another layer of abstraction... except abstraction." Every layer of abstraction adds both flexibility and complexity. Good layers add more flexibility than they do complexity. Bad layers add more complexity than flexibility. Aim for the good ones. :-)

I actually agree entirely that Drupal has gotten to the point of excessive complexity in many many areas. That has a negative impact on developer usability, on performance, and on flexibility. In some cases, too much flexibility leads to inflexibility. For instance, Render API: Great, flexible, wonderful, and completely obliterates the ability to do ESI (Varnish) partial page caching because there's so much flexibility from hook_page_alter that you can't assume *anything*. That was architecturally a mistake.

Well-designed APIs are easily separable. That is, you can gut and rewrite one system without destroying another. Drupal... has very few of those. That's part of the problem.

I don't think a "simplify" initiative in and of itself would be successful. Rather, simplification needs to be a part of every initiative. For example, the Configuration initiative is working on a new common configuration system. Yes, that's a new complex system... but if done properly, there's a dozen one-offs that we can replace. That is overall simplification through unification.

The Web Services (WSCCI) initiative has that sort of simplification-through-unification as one of its core principles. We want a single, unified context API in core rather than 2 dozen one-off functions, all with different signatures. We want a single unified plugin API rather than a dozen half-assed implementations in core, none of which are anything alike and all of which defy all known conventions of software design.

Right now, you have not one but three semi-compatible page building mechanisms available for Drupal: Core blocks, Context module, and Panels. All have their issues, some are entirely backwards from others, and all are screwed with by Render API. Where the WSCCI initiative started, really, was the idea of unifying those into a single, flexible, good rendering pipeline that we can rely on and optimize.

The HTML5 initiative includes overhauling Drupal's templates to not be 15 excessive layers of "maybe divs". That's simplification on the front end, hopefully.

So the work is happening for this sort of simplification. There are three things standing in the way.

1) Commitment. We have to be able and willing to commit to removing the old systems. When we add a new unified approach, we need to commit to killing all of the old ones. That means every plugin API in core goes away and gets ported to a single one, even if it's a lot of work. That means that you don't get a choice of blocks (inside out) or panels (outside in) page building... You get one, and everything assumes that one. That means it's gotta be good. It also means that certain approaches to certain problems will simply go away and become impossible. hook_page_alter simply has to go, which means we need to find other approaches that are good enough replacements that don't complicate the system. But taking away people's familiar toys is not easy.

2) Consensus. Unfortunately, Drupal is prone to bikeshedding. Both CMI and WSCCI have run into this challenge where progress is slower than we'd like because points need to be debated at length for cultural reasons rather than technical ones. Some of those debates prove valuable in the end, to be sure, but they take too much out of people. This is a cultural issue, not a technical one, and is very difficult to resolve.

3) Manpower. It's like pulling teeth to get people who can commit time to work on some of these initiatives. HTML5 is actually doing fairly well, but the rest of us are struggling. All of the skilled people are busy, myself included. :-) This is also not a technical issue but a logistical one.

If you want to help simplify Drupal, talk to me. Like, right now. Or next week in London. I can put you to work right away. I have an issue right now that needs someone to write the patch for it so that we can start test-converting core over to a unified context system. We need people who can dedicate time and elbow grease to the goal of simplicity-through-unification.

Let's make Drupal simpler.

This is one of the best blog posts I've seen in a long time.

Drupal needs less fan boys and more critics. I've prided myself in being the former.

I would personally love to see Drupal 8 do nothing but simplify, merge and remove things. Things need to become simpler and easier for developers. I've been with Drupal for 5 years, and for me, I'm not a huge fan of D7. It's too complex. We need to stop trying to push Drupal forward and instead look inwards and improve the experience, primarily for the site developer and secondly for the end user.

I would love to see core devs stop working on Drupal 8. Just stop. And instead assist in bringing contrib up to speed. From this practice, I'm sure they would identify many issues which exist in core and hopefully improve the process then when moving forward to D8.

A good idea of "ideal abstraction" in D7 is Drupal Commerce. Drupal Commerce heavily uses all "best in class" contrib. This includes deep integration with EntityAPI, RulesAPI and ViewsAPI. While it's a wonderful idea in theory, it's a frigging PAIN to work with. Drupal Commerce has abstracted itself so much, that it doesn't even solve the most basic use case for eCommerce, easily create an online store which sells products. Instead you need products and a product display node, making the end user experience too difficult for non-programmers to figure out.

I've recently taken on my first Ruby project and might be exploring that more.

"Drupal needs less fan boys and more critics."

Is that really an issue? Reading through all comments here I can't see any fanboys at all. In fact almost everyone agrees with the post and acknowledge the problems listed.

I started with Drupal 6 and thought it was the greatest thing ever in terms of Open Source CMS capabilities. You could build all kinds of sites.

So Drupal 7 came out, and the Date module didn't work properly, so anything that needs a simple date wouldn't work. It was a clear sign that the upgrade to Drupal 7 wasn't going to be a clean and easy process, and seemed like a site could break at any moment.

I decided to use php frameworks for all new projects. I'm glad I did because as the author mentioned, 14,000 lines for a date module is ridiculous when it can take much less.

I really missed ImageCache but found something to replace it, no user interface of course but my version has increased security and flexibility. I also made custom uploaders and image croppers, something that was difficult to implement perfectly for end users with Drupal.

I saw a suggestion one time that Drupal's best features should just be abstracted into a framework. I think so too.

Excellent comment on the Date module. A Date should be a Date. Other things such as start date - end date should be a data structure that, for example, contains 2 dates.
Dates are fundamental data structures--a basic date capability should be part of Drupal core.

On Render Arrays--what a nightmare to work with. Basic to almost everything now, but too complex yet not documented well. Form render arrays can only be used in a custom module, and are different from other render arrays and use different functions to get rendered. (And that difference is not documented well either.)

Brilliant post, keep up the good work.

This is exactly how I feel about the new versions of Drupal. Version 5 was pretty much the last "developer friendly" release.

7 has too many layers and far too much abstraction for performing even the simplest of tasks. This is extremely dangerous from a security standpoint because increasingly fewer developers know exactly what there code is doing under the hood.