My Takeaways from DrupalCon Nashville

I’m more than a little late on the traditional DrupalCon recap this year, but even with some time between me and Nashville what I took away is still quite vivid. Better get it in writing before the remaining echoes of country music drown it out.

My most important takeaway from my trip was that the Nashville Predators let fans smash a car painted with the opponents logo before games. Beyond that, I did also learn some things while at DrupalCon.

There is a lot of excitement behind Layout Builder and layout related initiatives

What the Layout Initiative was able to accomplish with the release of Layout Builder as an experimental module in Drupal 8.5 was extremely impressive. It is a great foundation that the initiative already appears to have clear plans to flesh out and improve. It was promising to see many well attended sessions on this topic, coverage in the Driesnote, and quite a bit of excitement about layouts and Layout Builder buzzing through the halls of Music City Center.

The biggest gap I see in what exists thus far is the disconnect between the block based layout builder and the blocks UI. You currently have to leave the layout builder interface to create new custom blocks before you can add them to a layout, and these blocks have the potential to flood the main Drupal custom blocks UI. I was very happy to hear that there is an issue related to inline creation of custom blocks that should help bridge this gap. In a BOF on Components and The Layout Initiative a number of other relevant issues were identified that could potentially improve the experience and make Layout Builder play even more nicely with component based workflows. I’m hoping to follow along with these, go hands on frequently, and help out where I can.

Many are decoupling, but approaches vary

To poorly paraphrase Matt Davis:

Many people build websites this way outside of the Drupal world, they just don’t call it decoupled

There was a lot of great discussion at the Decoupled Summit (Lullabot has a good recap) but also a feeling that while decoupling continues to gain momentum in the Drupal community, there are still a wide variety of strategies and some alignment on best practices yet to come. That said, I think some of that feeling may just come with the territory of the flexibility of an API based approach and the wide array of application frameworks that can consume these APIs.

An interesting topic that came up was the concept of content preview and managing editorial layouts. In the developer case studies portion of the summit we saw a number of attempted solutions to these problems, including an amazing offering from 1XInternet that allowed content managed in Drupal to be edited in either the Drupal or React UI with updates syndicated in near real time. Wow factor aside, conversations later in the summit brought that entire approach into question. The counterpoint being that these editorial conveniences are page-centric in nature and thus won’t always make sense in a truly decoupled context. In this case we’re either putting in a large amount of effort to replicate the traditional coupled website editing experience, or this only represents one portion of the editorial experience we’re trying to manage. It is understandable that we’re often falling back to the page centric approaches we’re familiar with, but this is more evidence that our approaches to decoupling are still maturing.

Discussions during the summit also often crossed into two key initiatives...

The Drupal community is pushing to modernize...

The Javascript Modernization Initiative looks to improve Drupal’s JavaScript by improving the experience of maintaining Drupal’s current JavaScript codebase, and also creating a new alternative admin UI for Drupal based in React. The initiative has already introduced the AirBnB standards and a JavaScript build process to Drupal Core, but there are more welcome changes on the horizon. One focus area is improving Drupal’s JavaScript based test suite by phasing out the use of PhantomJS and transitioning to Nightwatch.js. They are also attempting to manage aspects of the project primarily on Github which I’d imagine would be a welcome change for many JavaScript developers.

Another common theme that kept coming up is that the JS initiative has a small group working on these issues and could really use additional help. This is another area where I’d love to find a way to contribute in the coming months.

In addition to serving as a proof of concept for how Drupal might utilize React, this UI also crosses over nicely with the API-first initiative since the alternative admin UI that is being developed depends on Drupal’s API. The API-first initiative aims to advance Drupal’s web services in support of decoupling and other new types of integration. Closing gaps in Drupal’s API (file upload support was one that came up as a high priority for 8.6) that could support a decoupled admin UI would also make Drupal’s API more suitable for consumers outside of core.

…but there could be more alignment on how we’re approaching modernization

Complete with its admittedly clickbait title, core conversation A Farewell to Twig received the passionate discussion that the session appeared to be aiming for. This early and theoretical discussion focused on the concept of making client rendering a first class citizen in Drupal and potentially focusing more on decoupling rather than solving all aspects of front end development. One possible approach involved enhancing Drupal’s front end to be decoupled out of the box and then offering one or more decoupled front ends that could optionally be used with Drupal. There were various theories on how far this would go - from shipping with a Twig front end by default (a common concern from the audience was related to continuing to support Twig for small to mid range projects, and also for general consistency) all the way to the concept of not shipping with a front end by default.

It was a thought provoking discussion that also sparked some dissonance with the other things I’d been hearing and thinking about throughout the conference. Much of Dries’ focus in his keynote was on improving the content creator and site builder experience, along with promoting Drupal to non-technical decision makers. This aligns nicely with the layout work (which also featured prominently in the keynote,) but it feels at odds with the focus within the community on decoupling. Can both directions be correct? Should both efforts be happening in parallel? Should I just relax and enjoy all of the new functionality and improvements Drupal has to offer? No easy answers here, so I’ll just link to a relevant meme.

Tangentially related, Steve Persch talked about Drupal’s mission statement compared to WordPress' during the What's possible with WordPress 5.0 presentation. Those missions are best summarized as:

Wordpress: Democratize publishing
Drupal: Ambitious Digital Experiences

I’d agree that Drupal’s mission statement isn’t as easy to hang your hat on when compared to WordPress. And does ‘Ambitious Digital Experiences’ really represent what was focused on during the Driesnote? I’m not so sure.

Presenting at DrupalCon was a ton of fun

I also had the pleasure of presenting Hot JAMS(tack): Building a Music Discovery App with Drupal and React. This was my first time speaking at DrupalCon and I had a ton of fun doing so.

Probably my most interesting takeaway from the session was from an informal poll before the recording even started. The vast majority of people in the room either identified as being new to decoupled Drupal, or new to React. In fact, the vast majority was new to both. This seems to confirm my working theory that there are a lot of people interested in decoupled concepts in the Drupal community but are struggling to find a way to get started. I hope this talk provided a decent starting point and inspired some people to dive in and start experimenting.

Thanks to everyone who attended, packed the room, and provided thoughts and feedback.

This was my most social sprint experience

This DrupalCon sprint was different for me in that I spent the majority of my time having some great conversations rather than actively writing code. I finally had a chance to meet Kaleem Clarkson face to face and talk about how he’s been using the Foundation Patterns theme. I also got to meet and have a nice conversation with Murray Woodman talking to him a bit about how I’ve been using the UI Patterns module, along with his work with Bricks and Modifiers. Especially interesting as earlier in the week I had been talking with Scott at HS2 about how he’s been using the Modifiers module.

And I got lunch at the best BBQ place in Nashville (according to one of my many Lyft drivers anyway.)

Kevin!

It was a damn pleasure to be there in person to see Kevin Thull accept the Aaron Winborn award

Looking forward to continuing the momentum

As always, DrupalCon has me energized and ready to run with this Drupal related excitement (although not enough to get this post out quickly for some reason.) I hope to continue speaking at camps, find some ways to contribute to the initiatives that took up most of my focus at DrupalCon, and an episode of the Developing Up podcast that I recorded with Mike Miles at DrupalCon will be released sometime in the future as well.

Other Great Sessions:

• Advanced Configuration Management in Drupal 8
• Keynote: Drupal and the secret of my success | Steve Francia
• Site Building 2.0: How Layout Builder will change everything
• Introduction to React Design Patterns

Sessions I’m Still Hoping to Watch:

• Build banging sites with BPM: Bricks, Paragraphs and Modifiers
• Advanced topics in decoupled Drupal
• Next Level Twig: Extensions
• Shifting UX to the Editorial Experience
• JavaScript and Accessibility: Don't Blame the Language
• Weather.com's Project Moonracer - Decoupled User Interfaces

See you in Seattle!