Let me start by saying this article refers to Drupal 7. I have no experience with 8. I’ve read that it may address some of the concerns I outline below, but I haven’t investigated. By the end of this article, I hope you understand why.
I’m not new to Drupal. Over the past 4 or 5 years, I’ve consistently found myself involved in a project using it, and I’ve done a bit - from custom module and template development, to aliasing drush commands. I even went to the first DrupalCon Conference in Chicago. I know not to hack the core, how to update, what a distribution is, and much of what I think most devs would consider the basics. I’m far from an expert, but I know enough to get a project off the ground.
My main problem with Drupal has nothing to do with how it's built, maintained, or even how it performs (in terms of actual backend execution). My main problem is that it doesn’t support single page app architecture, which I will refer to as service oriented architecture, from this point forward. I’m a big fan of single page apps. They’re faster for the user, easier to maintain, decoupled from the backend, and reusable. I probably don’t need to spend much time touting the benefits of SOA. Unless you’re a die-hard full stack developer, you’re probably with me.
Drupal uses reusable templates (themes) for the UI, which could lead one to think “SOA,” but it’s completely different. The front and backends are not separate; they are fused. Each “page” requires a full trip to the server, and subsequent bootstrapping. This is where performance and user experience crash. It also opens the door to unnecessary errors (network failure, failed resource loading, etc.), and the inability to scale your app. Drupal is a “backend” framework, just one ill-suited to service a decoupled front end. It’s designed to generate renderable html, not manipulate headers, or return JSON.
This is where Drupal 8 supposedly comes into play. I say “supposedly” because I’ve only read these things (headless Drupal and all of that), but for argument’s sake, let us assume it true: Drupal 8 is designed to service frontend applications. Drupal 7 definitely is not. Given its roots, and need to support porting from 7 to 8, I have a hard time seeing how completely different use-cases are easily implemented in a framework. If this were done truly well, I’m sure there would be more of a buzz in the developer community.
There’s also a serious learning curve. Eight is completely different than 7, according to Dries Buytaert, the creator of Drupal, and I just don’t have time for that. I might be more inclined to experiment if it were just a bunch of new functions, modules, or whatever. Instead, it sounds like I need to invest time into learning an essentially new framework. I already use a micro-framework (Slim), and the only new one I’m interested in learning is Laravel. Consequently, I’ve decided to move away from Drupal.
I’m not new to Drupal. Over the past 4 or 5 years, I’ve consistently found myself involved in a project using it, and I’ve done a bit - from custom module and template development, to aliasing drush commands. I even went to the first DrupalCon Conference in Chicago. I know not to hack the core, how to update, what a distribution is, and much of what I think most devs would consider the basics. I’m far from an expert, but I know enough to get a project off the ground.
My main problem with Drupal has nothing to do with how it's built, maintained, or even how it performs (in terms of actual backend execution). My main problem is that it doesn’t support single page app architecture, which I will refer to as service oriented architecture, from this point forward. I’m a big fan of single page apps. They’re faster for the user, easier to maintain, decoupled from the backend, and reusable. I probably don’t need to spend much time touting the benefits of SOA. Unless you’re a die-hard full stack developer, you’re probably with me.
Drupal uses reusable templates (themes) for the UI, which could lead one to think “SOA,” but it’s completely different. The front and backends are not separate; they are fused. Each “page” requires a full trip to the server, and subsequent bootstrapping. This is where performance and user experience crash. It also opens the door to unnecessary errors (network failure, failed resource loading, etc.), and the inability to scale your app. Drupal is a “backend” framework, just one ill-suited to service a decoupled front end. It’s designed to generate renderable html, not manipulate headers, or return JSON.
This is where Drupal 8 supposedly comes into play. I say “supposedly” because I’ve only read these things (headless Drupal and all of that), but for argument’s sake, let us assume it true: Drupal 8 is designed to service frontend applications. Drupal 7 definitely is not. Given its roots, and need to support porting from 7 to 8, I have a hard time seeing how completely different use-cases are easily implemented in a framework. If this were done truly well, I’m sure there would be more of a buzz in the developer community.
There’s also a serious learning curve. Eight is completely different than 7, according to Dries Buytaert, the creator of Drupal, and I just don’t have time for that. I might be more inclined to experiment if it were just a bunch of new functions, modules, or whatever. Instead, it sounds like I need to invest time into learning an essentially new framework. I already use a micro-framework (Slim), and the only new one I’m interested in learning is Laravel. Consequently, I’ve decided to move away from Drupal.
No comments:
Post a Comment