The Drop Times: Who Builds Drupal Now?
Visual page builders often arrive with a familiar promise: fewer developer handoffs and more control for editors. Drupal CMS 2.0 makes that promise concrete by using Drupal Canvas as its default editing experience, with drag-and-drop composition, live previews, and editing directly on the page. The change does not remove front-end development. It moves the unit of work from the individual page towards reusable components and the rules surrounding them.
Single-Directory Components make those rules visible in code. Part of Drupal core’s render system since Drupal 10.3, a component can keep its Twig template, metadata, CSS, JavaScript, and related assets together. Props define structured inputs, slots create controlled areas for nested content, and schemas can restrict the values a component accepts. Drupal’s SDC quickstart describes these inputs as an application programming interface, or contract, for the component.
Consider a featured article card. Developers can encode its semantic markup, heading structure, image treatment, responsive behaviour, accessibility requirements, spacing, and permitted visual variants. Editors can choose the article, label, image, and approved presentation without adding arbitrary classes or rebuilding the markup. The editor gains useful control because the developer has already decided where flexibility is safe.
Recent Drupal publications make this division of labour clearer. In the 4 December 2025 blog post “Drupal Canvas 1.0 Released,” Drupal founder Dries Buytaert described reusable components that match a team’s design system. His 23 October 2025 State of Drupal recap presented visual page building for end users alongside component work for front-end developers, while Drupal.org’s 24 March 2026 post “Drupal at 25: Built to Last. Ready for What’s Next.” said Canvas can speed page creation without sacrificing structured content. The pattern is clear: visual tools redistribute development work rather than make technical expertise unnecessary.
Canvas also extends component development beyond traditional Twig-based theming. Its code components contain JavaScript and CSS, can receive page data and custom inputs, and can be created in the browser or maintained in a local codebase. They render through Preact with a React compatibility layer. For teams that need source control, shared files, static assets, or package dependencies, the local workflow supports development outside the Canvas interface and synchronisation with the Drupal site.
Greater component power creates a governance question. A schema can restrict the values a component accepts, but the development team must still decide which choices are meaningful, who owns the component, and how changes will affect pages already using it. Too many exposed options can weaken the design system, while too few can recreate the bottlenecks that visual building is meant to reduce. Reusable components should therefore be reviewed as public interfaces, with clear defaults, accessibility checks, documented variations, and predictable behaviour.
Existing custom themes do not need to adopt this model in one large rewrite. Teams can begin with repeated elements such as cards, teasers, calls to action, and heroes, then move their inputs into documented props and their flexible regions into deliberate slots. Components can be tested within the theme before mature and stable choices are exposed through Drupal Canvas. The future Drupal developer may assemble fewer pages directly, but will carry more responsibility for building the platform on which those pages can be assembled safely.
Readers can follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.
(Kazima Abbas, sub-editor at The DropTimes, writes and curates this week’s Editor’s Pick.)