By: btopro

Over on the ELMS:LN team, we’ve been busy every place not Drupal (huh what?) lately. We have barely been touching Drupal and couldn’t be happier (…huh?). In fact, we’re busy these days encouraging people to not focus on Drupal, at all (so this is on planet then why…).

Drupal is fantastic at what it’s great at. It’s great at being a CMF; the crazy abstraction of a CMS that lets us build anything. It’s great for handling complex workflows and raw webservice / integration capabilities (there’s a but coming…).

BUT

Drupal is terrible from the perspective of on-boarding pure front-end developers. While making great strides and way better then alternatives, it’s still not going to save us all from the endless array of lightweight, fun to develop for, NodeJS and SailsJS backends seeking to give Drupal death by a thousand microservices.

What I’ve found though from hunting around other CMSs though, is that this isn’t a Drupal problem; it’s a workflow problem that plagues the larger web. GravCMS is reasonable to theme for, but it still sucks compared to just making something look great on the front-end. Wordpress the same thing (security methodology or lack there of aside). This isn’t a uniquely Drupal problem and it’s not to demean the people like @MortenDK and the other core contributors who have done a great job getting Drupal to where it is in these areas.

So Headless then?

Headless isn’t a rallying cry against the great work they’ve done, it’s a response to the fact that no matter how hard we try, we’re putting a round peg into a square hole. Headless allows our front-end teams to focus on the front end and interface with the systems team conversationally as “I need a JSON array that looks like {} here” and get it. It keeps needless markup (which I know div-itus has been heavily killed in core). Headless isn’t everything though; there’s still a HUGE advantage to hybrid methodologies where Drupal is delivering front-end style assets in a well structured and very intentional way. This helps get around issues of rebuilding Drupal but on the front-end when it comes to forms, admin areas, user management, and other sticky areas. If we can at least make these things look great, then who cares if they come from front-end or back-end so long as they leverage the same templates / rendered elements.

HAX and the way forward

HAX is short for Headless Authoring eXperience. HAX means that our authoring experience is completely disconnected from Drupal or any other CMS, and instead is providing a simple way of integrating a uniform UX pattern into a backend. HAX is an idea that me and other members of the Penn State community have kicked around for years, built prototypes against and now, in the last 2 months, finally have something that looks and functions in the direction we’ve been seeking. I think this is another piece of the adoption puzzle in Drupal 8 if we want to seriously start seeing sites like the Whitehouse not flip from Drupal to Wordpress and instead start seeing mass exodus from Wordpress / others to the most powerful platform.

In order to do this, it can’t just be a powerful platform. It has to be the most approachable and able to quickly make high fidelity experiences for content authors. It has to be drop dead simple to setup and gorgeous to use (yeah, super easy,… I know…). Authoring experience we’re working on; trying to make something highly pluggable on the front-end to match the lego-esk pattern that Drupal has on the backend. We’re teaching Drupal to understand webcomponents so that it can easily integrate with systems like HAX (and we’ve done so).

So in other words, I think the best way to increase Drupal 8 adoption is by making Drupal the most enjoyable platform to do front-end development, bar-none. I think one of the most important ways to do this is to get people off their addiction to tpl file theming and into Webcomponent technology natively. Leaving the island and landing on Polymer has been the single biggest enhancement to our own platforms we’re building in the history of the project. Teaching ELMS:LN (and Drupal by proxy) to understand webcomponents has been completely game changing for our developer experience as well as student experience in what kinds of solutions we can build.

I’m so sure that this is the solution that I’m not spending my free time integrating other platforms with Webcomponents so that it can be integrated with HAX. While others were celebrating, I stayed up into the wee hours writing Webcomponents and HAX modules for Backdrop, GravCMS and Drupal 6 (yes. Drupal 6). Included with this post are videos showing what HAX is and how to get it and webcomponents integrated into all of these platforms.

Drupal 8

The Drupal 8 port of both are in the queue and I’m happy to help anyone take them on as co-maintainer as I can only stretch so far. But I think Webcomponents is the answer to increasing Drupal 8 adoption long term. By getting off the addiction to TPL files, we can start progressively collapsing the module requirements of our existing Drupal 6 and 7 sites. When we reduce the requirements on the module side, we decrease the complexity of our sites and open up pathways to migration currently unattainable. People aren’t on Drupal 7 still because it’s more fun, they are there out of the realities of life :).

So if we enhance these platforms and get people developing in webcomponents to improve workflow, we’re getting them out of their Drupal 6/7 shell and into something that’s non-Drupal and WAAaaaaayyyyy more fun to work with as far as front-end is concerned. At the same time, we’re decreasing the complexity of their Drupal sites on the backend via these hybrid and headless sites which then can more easily transition to Drupal 8. Drupal 8’s “problem” then becomes understanding webcomponents and how to integrate with them and our front-end people won’t have to change their workflow. We’ll create a pipeline for awesome development experiences on the front-end via webcomponents and awesome content authoring experience via HAX (which is just leveraging webcomponents).