Skip to main content

For the sixth straight year, I joined thousands1 of other web workers from around the world to discuss, conspire, and collaborate on all things Drupal. This year, we took over downtown Los Angeles for our annual pow-wow, and spent nearly a week sharing best practices and learning new techniques for our favorite open-source web framework. Like most DrupalCons, the sessions were less about detailed training, and more about high-level conceptual talks that provide guidance and direction on long-term trends in our industry. I'd like to note three such patterns I observed this week, as I plan to begin incorporating them into my daily work.

Front-End Components and Atomic Design

There was a time when Drupal front-end development mainly consisted of receiving a static Photoshop comp from a designer and integrating that snapshot into pixel-perfect HTML and CSS as part of a theme. Those days, if they haven't passed already, are numbered. The web can no longer be constrained to 960px, as users are consuming content on a variety of screen sizes and devices. Because of this, smart designers have moved toward imagining web systems rather than web pages. These systems are made up of a library of content-specific components that are flexible and not limited to any one display.

While this may not be the newest trend, I certainly was impressed by how sophisticated these approaches to front-end development have become. Many client-side teams have taken to building well-organized "living style guides" for their projects, where the design is broken down in many small, discrete elements (say, a news teaser) and then committed to actual code for reference and further integration. These style guides outline fonts, icons and display variations. Because they are essentially a collection of patterns, these style guides present a systematic direction that can be adapted to cover just about any use case.

Of note, many of these teams are using sophisticated tools to manage this work. There were a few talks with mention of Yeoman for scaffolding, NPM or Bower for library management, and Grunt for automation. While these are probably best discussed in their own post, I will say that there is no doubt that client-side design and front-end development will require more advanced skills in the days ahead.

BEM Syntax

Now that our websites are built-around flexible, component-driven design, it is important that the markup used to semantically describe these widgets follows an equally thoughtful system. Enter the Block-Element-Modifier (BEM) syntax, an approach to using a specific pattern of CSS classes in order to reduce issues with specificity and make our code more flexible. As sites grow larger over time, there can be significant maintenance issues if the CSS relies on widgets being in a certain region of the page (say, a sidebar) or if it is too broad, affecting other areas and elements on the site.

The BEM syntax seeks to keep the CSS targeted toward a single component. That way, if that component moves on a page, or if it takes on an alternative display, the general styles will still apply, and will not affect unintended targets. Admittedly, it looks a little odd at first, but once you get acclimated you can quickly see its effectiveness. Below is an example of single component, marked up the BEM way.

.post {}
.post__title {}
.post__image {}
.post--full {}

This approach can be furthered managed by the generous use of SCSS partials, keeping the styles for each component discretely in their own file. As you probably can see, this allows for an organized convention well-suited for working in a team. As for Drupal specifically, this syntax will be the CSS style standard for version 8, and you will see it used both core and contrib templates. Time to adopt, I'd say. And I, for one, am fully on-board.

API-Driven Development

Perhaps the most obvious, talked-about trend for the last two DrupalCons now is the migration toward building sites with "API-first" development. You couldn't go far, either on the convention floor or within the sessions, before hearing the current biggest buzzword in our community: Headless Drupal. There were multiple talks given and breakout groups organized, as developers championed using Drupal 8 exclusively as a data store and content management tool, while leaving all client-side display to a JS framework and templating engine.

Headless Drupal

The key driver of this shift is the "rise of the machines," where the websites we build need to not only connect with humans, but also other web sites and servers which may be consuming the same content, but displaying the data in another app. Think of a mobile app sucking in data from your website and then providing a unique experience for smartphones. Out-of-the-box, Drupal 8 provides the capabilites to expose the content on a site in formats that are easily digestible by these machines.

A typical demonstration of Headless Drupal consists of showing how simple it is to build a REST API in D8. It is really easy to setup a nice pattern of routes that serve JSON as a response. Click, click, click for the most part. Now that the backend is decoupled from the client-side, there is freedom to explore tools like Angular JS to build out rich, single page interfaces, blurring the line for the typical CMS user experience.

It's hard to say just how long it will be before most builds bypass the Drupal theme system altogether. Who knows if that will truly even become the norm. But with these awesome REST API tools coming in the next version of Drupal, there is probably no reason to at least make the data available as part of a project. We all know that things move fast in our business. Reading the tea leaves and trying our best to be future-friendly is an important part of keeping up with the times.

  1. * The final attendance number was 3,186.  ↩


Back to the Work section »