Lately there has been much chatter about Drupal including a front-end framework in Drupal core. Dries has written a few times about the concept and has established that he’s interested in a future where Drupal is “progressively decoupled” from its front-end, leaving the front-end rendering to be handled piecemeal by a JavaScript framework like Angular or React. Progressive decoupling, far from being an industry standard, is a concept that has been coined in the last several months. Without a sucessful model to look at, we are staking our future on a reality that only exists in blog posts. The momentum of front end frameworks distracts from addressing more important issues, and has created a miasma of anxiety that Drupal is going to be “left-behind”, again.
Drupal is not intended for Single Page Apps. Drupal has never been, nor should, be a choice for lean startups to build their exit strategies upon. The community prides itself in producing quality open-source code for one of the strongest foundational CMS frameworks in history. When Trello is rebuilt it will not be on Drupal 8, nor Drupal 9 - nor should it be.
There seems to be an assumption that adding client-side rendering will improve user experiences. When WordPress launched their new JavaScript-powered admin experience, a communal pang of envy could be felt. The allure of pledging Drupal to one of these frameworks is understandable, but ultimately it’s tech lust. Often times the Drupal admin experience can be non-intuitive, and lack even basic usability. Improving Drupal’s usability starts with design. Integrating Ember, or Angular, or React won’t solve any of the admin experience problems we currently face (and have historically faced). Furthermore, if the goal is to improve the end-user’s experience with client-side rendering, then we should focus on enhancing Drupal as a framework-agnostic endpoint.
The community has made incredible strides with Drupal 8 to leverage other communities and their sound technologies. The incorporation of Symphony and Twig are tremendous, new and have barely been explored. Keeping the focus on improving our current systems is more important than which JavaScript trends we’ll want to jam into Drupal’s long-term future.
I’m not suggesting that keeping with current trends and languages in the industry is poor-form, but I am suggesting that pledging our Drupal allegiance to a singular framework is a bold step that will ultimately sever much of Drupal’s flexibility that we hold so dear. I’m proposing that Dries and the larger community aim our efforts to strengthening Drupal as a framework-agnostic endpoint. As Drupal developers we should focus on creating a Drupal ecosystem that thrives by itself. The more we tie ourselves to other frameworks and languages, the more we lose our identity. Before we know it Drupal 9 will just be a shell for Angular 4.
