Drupal's front-end future: A compilation of ideas
Drupal 8 was a monumental leap forward for the Drupal front end, including Twig theming, asset library management, and no more theme functions in core. Meanwhile, the front-end landscape around us has evolved considerably, leading many of us to ask questions challenging Drupal’s traditional role as a customizable front end coupled tightly with a capable CMS.
For instance, the ongoing JavaScript renaissance has contributed to growing interest in fully decoupled Drupal, in which Drupal serves as a content store exporting data via RESTful API to client-side applications, whose JavaScript variants are typically rendered isomorphically on both the server and client. But this jettisons so much of what we have taken for granted in Drupal’s front end, particularly display and layout management.
Where is Drupal’s complicated relationship with JavaScript headed? Are there better approaches to achieve the interactivity that developers and business increasingly want to build, such as progressively decoupled Drupal (decoupled components of a page outputted by Drupal) or exporting presentation data as well as structured data (e.g. Panels configuration in JSON)?
Since the start of the year, I’ve been hosting a BoF roadshow and traveling both near and far to learn about the Drupal community’s most diverse and fascinating approaches to the front end (whether in Drupal or not) and to document Drupalists’ opinions about decoupled Drupal, isomorphic JavaScript, client-side rendering, Twig, and the Drupal theme layer. I’ve gathered a lot of knowledge, and I’d like to share it all with you!
Here are some of the questions I’ve been asking:
-
How will front-end developers (increasingly JavaScript-focused), themers, designers, site builders, and content editors interact with Drupal in the future?
-
What exactly should Drupal be for front-end developers? Should it continue to be a framework for low-code theming and more involved front-end development? Or should it become an API-first content store for consumption by client-side applications?
-
How should Drupal address increasingly demanding user experience expectations (e.g. optimistic UI, non-blocking workflows, no-latency feedback, and offline workflows)?
-
How should Drupal address increasingly demanding front-end developer expectations?
-
Does Drupal stand to benefit from more JavaScript-driven rendering, whether it takes place after Drupal outputs a page (progressive decoupling) or before Drupal data is consumed (full decoupling)?
Attendees should have a broad understanding of the Drupal front end and theme layer, the current debate in the Drupal community about the risks and rewards of decoupled Drupal, and approaches currently in vogue in the larger JavaScript community (esp. isomorphic rendering, abstract [virtual] DOMs, and JavaScript-only stacks). No specific knowledge about a particular JavaScript framework or library is presumed.