Drupal 8 architecture decisions. Standing on the shoulders of giants.

(Below are the two cents of someone who came to Drupal nearly nine years ago knowing only HTML and CSS, who worked hard to become a full fledged PHP developer, and has continued their programming education vis-a-vis rolling their own JavaScript framework and platform architecture for a large web application)

Until recently I've been less than enthusiastic about Drupal 8, but I've changed my tune (and of course nothing is perfect; I am still a bit concerned/sad that Drupal 8 could possibly be leaving some smaller sites behind, but this is a ship that has likely sailed, so c'est la vie).

What led to this change of heart? Simply, my understanding of just how much, and in what ways, Drupal 7 and previous versions of Drupal differ from widely established/modern techniques and/or best practices of higher level computer science/programming. Arguing whether this is true is comparable to arguing whether square wheels work better than round ones. All of the best programmers, across many different languages, and frameworks don't end up at the same basic conclusions for no reason. This is empirically evident for anyone who has looked around, studied, and experimented with solving problems that, as it turns out, have already been solved before. Drupal 8 will stand on the shoulders of these giants of programming.

To wit, a Drupal 8 programmer will not need to feel behind the times to anyone developing in Java, Rails, Django, or you name it. In fact, a Drupal 8 programmer that embraces the changes and learns the fundamentals underneath the implementations will have a much easier time being able to grasp those other languages/frameworks because Drupal will share more fundamental paradigms with them than it differs by. The reverse is true as well, of course (e.g., programmers from other languages will have an easier time coming to Drupal).

So, to keep this short I'll just close with this - embrace Drupal 8 and the future by starting to learn all the design patterns and OOP fundamentals you can (I recommend not just reading, but making something medium to large sized from scratch). The truth is this; if you think it's time to ditch Drupal and reach for anything other than WordPress -- objects, interfaces, design patterns, dependency injection, event models, etc will more than likely still be waiting for you there (and if it isn't I'd recommend passing, anyway). Drupal's architecture is just catching up with the rest of the more advanced computing world. Hop on board.

P.S., the scale of refactoring that Drupal 8 is undergoing to shed it's imperative/procedural/tightly-coupled skin is truly a monumental task. Allocate your criticism and judgement appropriately, and give things some time to expand and evolve.

11 September, 2013

Comments

I think you've hit the nail on the head.

As a developer who grew up on these modern patterns during the noughties, I
came to Drupal 18 months ago and couldn't believe how messy it was. The magic
function names (aka hooks) stood out particularly as it wasn't always easy to
work out what the function name was meant to be or debug it if you got it
wrong. And don't even get me started on the constant cache clearing.

If you grew up on Drupal then all these Drupalisms will be second nature to
you, so it's easier to stick with them than learn a "better" way of doing
things.

Wow, this is truly the best comment on this discussion I've seen. I'm really excited about finally working with "real" code and not a functional soup. :)