Meeting notes: May 20th 2024 - Isomorphic rendering

Experience builder meeting

Attendees EclipseGc, bnjmnm, e0ipso, nod_, tim.plunkett, pdureau, larowlan

• Broad goal: Attempt be able to dynamically update components client side when working with the experience builder without needing an AJAX call/round trip. Achieve this by some form of Isomorphic rendering of templates on both frontend (FE) and backend (BE)
• Meeting purpose: Ensure we're not competing with each other in our experiments in this space.
• Pierre demoed dilla.io - an approach for isomorphic rendering using WASM. Twig templates are converted to minijinja via build (make) task. Then compiled into WASM. PHP loads the WASM and uses it for rendering. The browser can also load the WASM and use it for rendering too. The WASM includes handling of other non-template aspects of Drupal rendering such as handling libraries.
  • Pros: Genuine isomorphic result between FE and BE
  • Cons: Requires PHP compiled with WASM support which isn't the
    default. Requires build steps
• Lee demoed building a component abstract syntax tree from Twig using the Twig compiler and a Lexer that uses masterminds/html5
  • Pros: Generating an AST allows for other options outside React.
    Renders as plain JS so no build step. Can leverage existing Twig
    compiler caching to disk.
  • Cons: Still a lot of work to do, there will be some Twig functions
    where adding support will be difficult (or perhaps impossible)
• Ben demoed the React JSX theme engine which makes use of React and hyperscriptify to render JSX in Drupal
  • Pros: Can intersperse Twig with React. Understands Form API.
    Compatible with state management like Redux.
  • Cons: Requires rewriting Twig components as React (JSX) and an
    equivalent JSON file detailing prop. Client side rendering only
    (Drupal emits a template tag only). Needs a transpiling step when
    editing JSX files.
• Tim demoed Alex's Svelte AST approach where Svelte code can be converted to Twig and JSX
  • Pros: Write in one language, output as multiple targets. Safer to
    let site builders/editors author in Svelte than Twig (possible
    security/stability issues)
  • Cons: Need to rewrite all twig files in Svelte first. May need a
    server side JS runtime (need to confirm). React is output as JSX
    (not JS) so needs transpile step (Babel).

Meeting conclusions:

• It feels like all of the approaches have synergies and aren't directly
  competing. E.g. If Lee's AST were finished then Ben's approach could
  leverage it to do the Twig to JSX conversion or Alex's approach could
  use it via a console command to migrate from Twig to Svelte.
• The WASM approach feels the most technically superior but (by Pierre's
  admission) is not a solution for right now. When PHP adds native support
  for WASM this future will arrive.

Other notes:

Pierre noted we will likely need to limit what Twig can be used in SDC components because some twig functions rely on system state rather than pure component state - e.g. things like format_date make use of config entities.