What is the problem to solve?
Frontend developers not coming from Drupal often do not know Twig. By providing support for multiple frontend frameworks we could provide for modern JavaScript frameworks like React, Vue or Astro besides Twig. This would make Drupal a much more attractive option for those developers and evalutors, since it's not necessary to re-train frontend developers on Drupal.
The modern frontend option would allow building sites with high-interactivity with modern JavaScript frameworks without a fully decoupling, like inertia.js does for Laravel.
Who is this for?
Frontend developers not familiar with Drupal, evaluators.
Result: what will be the outcome?
Re-architect Drupal such that the frontend rendering process is not coupled with the rest of Drupal. Make Drupal render into a tree of high-level components and add page metadata, then let the frontend take care of rendering those. The tree must be pure data (e.g. JSON) and provided via some HTTP API by page, e.g. /page-api/{path}. Frontends fetch this API and render the result, either server or client-side.
By default, Drupal core could ship with a twig-based frontend which uses symfony request/responses to internally resolve http requests without network overhead. The rendering happens de-coupled from the rest of the application, thus any lazy-rendering would have to trigger another (internal) http request.
Next to twig, we could provide one or two JavaScript based frontend frameworks which are officially supported, while the community could add more. CMS builders working with core could choose their preferred frontend framework or even allow site-builders to choose from supported options.
Implementation example
Lupus Decoupled Drupal already follows that model, but does not implement a twig-based frontend. Still, it can serve as some example that a core implementation could learn from. Here is some documentation about its page API and here is real-life example of it. Read about it here: https://drunomics.com/blog/inertiajs-inspirierte-entwicklung-fuer-drupal-lupus-decoupled-drupal-221
Implementation strategies
a) Follow the approach of the
Semi-Coupled
🐛
Experiments in rendering Twig as React
Active
theme engine of XB: Make a mapping of render array to components.
b) Propagate a clear cut and build a new render API that only supports the desired component model (and simplify as much possible). Add a compatibility layer for rendering render arrays into the component model like in a). Slowly phase the current render API out, after long deprecation.
Lupus Decoupled Drupal implements a new component model via the
https://www.drupal.org/project/custom_elements →
module. https://lupus-decoupled.org/get-started/how-it-works describes how it works.
Pros/Cons
Advantages that come with this approach:
- Drupal backend and frontend can be developed and tested separately
- Drupal stays in the driving seat, pages are composed by Drupal
- A HTTP-endpoint for the page API allows frontend-developers to easily introspect what is there to render. Great dev-tools could be built on top of that.
- Allows frontend developers to bring modern frontend (templates, components and tooling) to Drupal
Disadvantage:
- JSON-API / API-first is not required. Still developers it's an important addition, such that it's easy to fully decouple parts (or the full) application when preferred.
- Frontend stacks might have to support lots of components to be complete. A fallback mechanism would be great.
How can we know the desired result is achieved
* Drupal core provides an HTTP API for fetching the component-tree of a page
* Drupal core provides a twig/sdc-based frontend based on the component-tree
* Drupal core provides at least one modern JavaScript frontend option, that allows for either server or client-side rendering.