I have to work with Drupal 6 on occasion for parts of a number of projects with my employer.
Before I was hired I'd had zero knowledge of Drupal or anything to do with it. "How hard could this be?" I thought.
Let it be said beforehand that I tend to use OOP practices when coding.
With that in mind, I was given some Drupal related task in my first week and my mind was utterly fucking blown. My OOP stuff was useless when dealing with the procedural nightmare of a Drupal module. I had to learn how to deal with Drupal's pointless reclassification of HTML when using its APIs to create forms, and had to get used to the idea that the people behind it are dangerously obsessed with multidimensional arrays, to the point they're used for everything (check out the module list function, which returns an array whose keys and values are identical).
As a developer, the tools included within Drupal that are intended to make life easier are not abstractions, but obstructions. The documentation is neither help nor hindrance, because there is barely anything that qualifies as documentation.
When it came to performance, I was just as blown away as I was by the development process. It's hard to even use performance and Drupal in the same sentence. Everything requires a horrific number of database calls. My colleague and I ditched the horrific concept of nodes and developed our own solution that, because Drupal is neither a good framework nor a good CMS, had to hack a lot of things to fit in. So we cut down on database calls but it was still slow. I logged calls to module_init() and noticed modules were being initialised not one, but up to 4 or 5 times on a single request. There were no doubt a good 20 or 30 db calls in that.
Then there are the practises it encourages amongst poor developers. Why not roll your own code when you can download a module that is barely any better than the Drupal core itself. Abstract existing functions within PHP to the point of them being abstruse and then spend the rest of your day trying to make sense of the non-existent documentation. And you end up with a project with a modules list that could stretch to the moon and back and an extra few hundred MB of bloat.
Considering I came to Drupal with no prior knowledge, bias, or experience, it couldn't have made a worse impression if it tried. This isn't entirely on topic of course but I find it hard to disagree with anyone who says it needs sorting out.
Yeah I had a similar feeling with Zen Cart recently, my mind was blown by just how many files were included in each page and the complex paths through which it happened, also the very high complexity search queries which perform terribly.
I think the issue is this software is more designed with allowing non programmers to get most of the way to a functioning website in mind rather than programmers. To someone with limited knowledge of what's under the hood they probably love the choice they get with modules and configurations abstracted away from the code.
Before I was hired I'd had zero knowledge of Drupal or anything to do with it. "How hard could this be?" I thought.
Let it be said beforehand that I tend to use OOP practices when coding.
With that in mind, I was given some Drupal related task in my first week and my mind was utterly fucking blown. My OOP stuff was useless when dealing with the procedural nightmare of a Drupal module. I had to learn how to deal with Drupal's pointless reclassification of HTML when using its APIs to create forms, and had to get used to the idea that the people behind it are dangerously obsessed with multidimensional arrays, to the point they're used for everything (check out the module list function, which returns an array whose keys and values are identical).
As a developer, the tools included within Drupal that are intended to make life easier are not abstractions, but obstructions. The documentation is neither help nor hindrance, because there is barely anything that qualifies as documentation.
When it came to performance, I was just as blown away as I was by the development process. It's hard to even use performance and Drupal in the same sentence. Everything requires a horrific number of database calls. My colleague and I ditched the horrific concept of nodes and developed our own solution that, because Drupal is neither a good framework nor a good CMS, had to hack a lot of things to fit in. So we cut down on database calls but it was still slow. I logged calls to module_init() and noticed modules were being initialised not one, but up to 4 or 5 times on a single request. There were no doubt a good 20 or 30 db calls in that.
Then there are the practises it encourages amongst poor developers. Why not roll your own code when you can download a module that is barely any better than the Drupal core itself. Abstract existing functions within PHP to the point of them being abstruse and then spend the rest of your day trying to make sense of the non-existent documentation. And you end up with a project with a modules list that could stretch to the moon and back and an extra few hundred MB of bloat.
Considering I came to Drupal with no prior knowledge, bias, or experience, it couldn't have made a worse impression if it tried. This isn't entirely on topic of course but I find it hard to disagree with anyone who says it needs sorting out.