Drupal Canvas: Field Notes From a Config-in-Code Holdout

Field notes: I spun up a fresh Drupal 11.3 site, pulled in Canvas 1.8, and gave myself one job. Build a real landing page the way a client would actually ask for it. A hero, three stat cards, a call to action. No custom module scaffolding, no theme templates. Just me, a browser, and the new React page builder that ships as the default editing experience in Drupal CMS 2.0.

What Canvas actually is

Let me get the terminology straight, because the name changed under us. Drupal Canvas is what used to be called Experience Builder. It hit 1.0 on December 4, 2025, and by the time I write this the project is on 1.8.0 (Drupal 11.3+). It is a visual, component-based page builder with the following traits:

• A React front end with drag-and-drop composition and multi-step undo.
• Pages modelled as their own entity type, not just a field on a node.
• Building blocks backed by Single Directory Components (SDC).
• An in-browser code component editor where you write JSX and Tailwind.

Building a real page

The headline feature for anyone who writes code is that in-browser editor. You open a panel, write JSX, style it with Tailwind classes, and it appears on the canvas immediately. Under the hood each component is an SDC: a component.yml with props and slots, plus the JS and CSS in one directory. My stat card was about this small:

export default function Stat({ label, value }) {
  return (
    <div className="rounded-2xl bg-slate-900 p-6 text-center">
      <p className="text-4xl font-bold text-white">{value}</p>
      <p className="mt-2 text-sm uppercase tracking-wide text-slate-400">
        {label}
      </p>
    </div>
  );
}

The part that made me exhale: those code components are stored in Drupal configuration, which means drush cex exports them and they land in git like everything else.

The config-in-code story is real once the component exists. But the birthplace of that config is a click-ops surface, and the round trip back into a proper editor is not yet smooth.

Where the git instinct itches

Here is the itch. I wrote that card in a textarea in my browser. No ESLint, no Prettier, no Storybook, no PR diff until after the fact. For fifteen lines that is fine. For anything a team maintains, the authoring surface fights the muscle memory of twenty years of editor-plus-git. That said, the good genuinely is good:

1. Iteration on a self-contained component beats the write-template, clear-cache, refresh loop I grew up with.
2. Editors get true on-page visual editing without me building a Paragraph type for every variation.
3. Because it is SDC underneath, the components are not locked inside Canvas.

So does it replace Layout Builder?

Honestly, nothing cleanly, yet. Layout Builder still owns templated, per-bundle layouts and stays in core. Paragraphs is still the mature, predictable choice for structured content editors reorder in a field. Gutenberg is still the free-form rich-content editor. Canvas overlaps all three without fully displacing any of them, and it is the youngest, so the contrib ecosystem appears thin. A CLI for discovering and building code components is in progress, which tells you where the seams still are. My verdict after a day: this is the most genuinely new thing to happen to Drupal site building in years, and the SDC-plus-config foundation means it is not the click-ops trap I feared. If you do not already live in an editor and a git history, you will love it. If you are me, you will use it, export the config, and quietly wish you could have written the JSX somewhere else first.

Links

• Drupal Canvas 1.0 announcement (drupal.org)
• Canvas project page
• Canvas documentation
• Canvas roadmap
• DrupalCon Atlanta 2025 session video