Make Drupal core multi-frontend

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Thanks

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.

For simplification, see @pdureau's comment on #2702061-106: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) → which would drastically reduce the number of #type and #theme, concentrating on #type => component pointing to SDCs, and possibly remove the preprocess layer. I think we should be doing that independently of anything here, and it also might turn out to be a hard pre-requisite.

Thank you for the pointer! I've commented on the other issue.

For keeping this issue up2date, I'm also crossposting here. I think 🌱 Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) Active would be the perfect first step for going towards a multi-frontend architecture. As I commented at #2702061-114: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) → we need to have a 2nd-step through to entangle the control flow such that we are able to generate a complete tree of components first and render it in a 2nd step. Once we have that we can also serve it via an HTTP API for a) multi-frontend usage and b) better debugging XP.

@fago Thanks for all the great work and discussions here! I've created a custom module that builds on these ideas — it generates a full component tree for any entity and supports rendering it in a second step. The structure is designed to support multi-frontend use cases (Twig, React, etc.) and can serve the tree via an HTTP API for better debugging and decoupled rendering.

I'd love to contribute and test this approach with others who are interested. Please let me know if you'd be open to reviewing or trying it out!

Thinking about this somewhat, the default rendering of Drupal is to HTML.
But that is a serialization format. JSON is another.

Perhaps if we reworked the renderer so that all of the processing aspects were part of 'normalizing' and then the render array to HTML was 'serializing' we could support serializing to JSON and other formats for render arrays.

These sound like the 2 steps you're talking about in #8 @fago

We already have these concepts for entities, but not for render arrays (which with 📌 Slowly, very slowly start OOPifying the render system Needs review start to move towards objects anyway).

This was the same approach I proposed in 📌 Stop taking over the twig theme engine for the whole site, just to render the edit form, move to a custom serialization format Active

Generally speaking nowadays probably Markdown is another demanded format, it can provide YAML in "frontmatter" and text render
IMO it's more demanded to allows LLMs read sites, other option could be Abstract Syntax Tree (maybe someone's summer project)