Decoupling the front-end without APIs and JavaScript

There has been amazing progress with Drupal’s API-First Initiative in the past few years. A major milestone was when JSON:API was added to core as a stable module in Drupal 8.7.

An API-first Drupal enables many things, but probably the best known use case of APIs is a decoupled front-end. Numerous blog posts and at least one book have been been written about decoupled Drupal. There have been many conference sessions on the topic, and there is an entire conference focused only on decoupled CMS architectures.

These exciting developments ensure that Drupal stays relevant, and that it is a first-class choice for building ambitious digital experiences in the modern web development landscape, where component-based JavaScript front-end libraries and frameworks like React and Vue are so popular.

A lot of the activity around decoupled Drupal originates from developers and other employees of Drupal agencies working on projects for large enterprises and organizations. These projects might require a content service not just for for app-like websites, but also for other publishing channels like native mobile apps and digital kiosks.

However, from a practical requirements and resources point of view, the vast majority of website owners just need a traditional website. And for someone like me, who often works as the only developer on (non-ambitious?) traditional website projects, JavaScript-based decoupled front-ends are interesting, but not required.

There are other ways

When so much attention is focused on APIs and JavaScript, it is possible to miss or forget the fact that loose coupling and components are general architectural principles that can be implemented in many different ways. A different approach can be used to get many of the benefits of a decoupled, component-based front-end.

Component-based theming is a commonly used name for a specific way to develop and organize Twig templates and related assets in Drupal themes. I am not sure how well known it is that component-based theming is actually a way to decouple most of the front-end from Drupal.

The best known benefit of this decoupling approach is the possibility to develop most of the theme layer independently of Drupal, with the help of a tool like Pattern Lab. But while there are already some very interesting examples out there, I believe that the full potential of decoupled Twig components is yet to be realized. By this I mean Twig component libraries that can be used with minimal integration effort in both Drupal and WordPress, for example. I believe that agencies offering services for both platforms could benefit a lot from this.

For ‘small Drupal’ too

Since it is often associated with style guides and design systems, it is possible to get the impression that component-based theming is only useful for large teams working on projects for large clients. However, I know from my own experience that even single-developer projects can benefit from it.

Component-based theming adds very little overhead to regular Drupal theming. Thinking in components can improve the quality of your work in many ways, and most importantly, building anything from blocks is fun!

There is no requirement to develop a style guide – although you might find that you end up with the beginnings of one as a happy side result.

A decoupled front-end means that work on the theme can be started even before Drupal is installed, and clients can be shown the design in a real browser much sooner.

So unless you are working on a project that requires a JavaScript-based front-end, I can warmly recommend component-based theming to teams and projects of all sizes.