Next steps for Drupal Canvas

In this talk, La Timi, a senior product manager at Acquia, discusses the future of front-end development with Drupal, specifically focusing on Drupal Canvas. He explains how recent advancements aim to simplify the site-building process for both front-end and back-end developers. The speaker highlights the integration of tools like React and Tailwind into Drupal Canvas, providing a more efficient workflow for creating components and templates without needing deep back-end knowledge. He emphasizes the importance of creating a better site builder experience to attract new users and developers to the Drupal community. La Timi also introduces the role of AI in enhancing Drupal's functionality, enabling streamlined workflows for content creation and management, and outlines upcoming features that will leverage external AI capabilities for improved efficiency.

All right, I think we can get started. Um, so nice that so many people showed up here. Um, looks like people are interested in canvas. Um, so let's start with a little bit of show of hands. I'm kind of interested what kind of uh personas we have in the room. So, how many of you are front-end developers? Raise your hand if you're a front-end developer. Wow, we

have a lot of front-end developers in the room. That's great. Uh, how many of you are backend Interesting. I actually see quite a few hands raised on both front end and and backend developer. I'm kind of surprised to see that >> an eitheror. >> Yeah. Um that might be the theme of my talk today. So let's see. Um I'm La Timi. I'm a senior product manager at

Aquia. I oversee uh products like Drupal canvas, Aquaource uh and Aquiaite Studio. I've been part of the Drupal community for 15 years. Uh before being a product manager, I I I used to do development. Um I actually was a front-end framework manager for Drupal before. So my background is in in front-end development. Uh this presentation is very dear to my heart. Uh because finally we are at

the point in the in the development where we can actually really talk about what uh it means to do front-end development with Drupal. You may have seen this slide before in in Dre's keynote. So I I stole it from there. We've been showing it around just to make sure that we remind ourselves of what is our what why are we here? uh why the core team the

the people who are building Drupal canvas what is what what is it that we're trying to accomplish and it is that we want to make it easier and faster to build sites. You've probably seen some fancy demos of the the drag and drop editor that canvas provides where you essentially have some components that you can drag onto the page and uh um uh see a live preview

of those changes. You can also edit text uh using the right sidebar and that um also updates the preview in real time. Um you might not believe it but this is actually Drupal in in 2026. 10 years ago if I sh told someone that they probably would have laughed at me. Um so that's where we are today in terms of this is what it looks like for

a marketer to use Drupal canvas. They could use these tools to publish content, build campa campaigns, uh structure content for SEO. Uh but essentially for marketer which we talk a lot in in our Drupal CMS marketing it still means that they can only realize value from Drupal after someone has built that site for them. And that's where the site builder whether that's a front-end developer, back end

developer, whatever background they have uh comes in. They install the site. They built those components that that the marketer can access in their site. Sets up content types and templates. Essentially they define what the marketer can do in there. But what's the the key to remember is just that the marketers that ultimately realize most of the value out of Drupal don't get that until the site builder

actually ships something for them. And so today I'm going to talk about that site builder experience uh more than what it actually means for uh a marketer This is also a slide from from Dreote where he essentially wanted to narrow down our focus on growth. Uh he stated that decline is a choice and we can choose to take deliberate actions that then help us grow Drupal. Um

Drupal actually is is very strong on certain markets markets. Uh these are usually content heavy use cases. For example, 71% of top 100 universities are using Drupal. Uh there's more than 150 national governments using Drupal and and uh at least 60 confirmed Fortune 500 companies using Drupal. I know that there's numbers that are wildly higher than that, but that's what I was able to actually uh get

as the sort of high confidence number and it's great. So Drupal is doing very strong in specific markets. But the challenge here is that usually when you start building, you don't necessarily start building to a Fortune 500 company. There's usually something else that you start with. you usually start with something smaller. And so if you look at actually how many people are joining our community, um these

numbers don't look as as great as the previous slide that I showed you in the Drupal uh developer survey 2025. Uh guess how many respondents were under 21. It was it was very similar to what we saw in the Dre note earlier today where there was one respondent who was under 21. Uh obviously it's there's probably more than one uh person that is under 21 using Drupal,

but it still shows that it's a fairly uh small uh portion of the of the user base of The challenge why I'm going to talk a little bit more about the reason why I believe there's probably multiple reasons which has to do also with the marketing. Uh but I'm going to talk about um why the site builder experience uh introduces some challenges to um gaining new new

users for Drupal. Um so if you think about uh Drupal, we talk a lot about the UI capabilities that you can do to to essentially build lists, different kinds of things uh using the interface. It's it's a great tool for building some sort of a prototype or you know a wireframe of what you're building. But if you go to views and actually build something, it's it's not

the end result that you're trying to achieve. It's just a wireframe because it's very generic what you get out from there because your what your site requires is actually it's usually something very specific to your brand. And and in many cases, you you want pixel perh perfect control over the design. And sometimes it can be really fast to get that to that wireframe stage to to actually

have it fully functional. And then it takes you maybe even weeks sometimes to get to the actual pixel perfect design. And this it's uh I I was actually joking with Balon who is one of the engineers in the in the canvas team about how uh 10 years ago when I was working in an agency or it was before that but we were actually thinking of should we

hire designers who know Drupal so that they can design for what's easy to build in Drupal and uh now come here and I realized that's that's a terrible decision. I don't think we should be hiring designers who know Drupal. it's we should actually make Drupal so that it's easy to to build any design that you have. So the gap between these two is essentially in Drupal what

we call theming. So let's look at what that that actually looks like. If you put Drupal on a on a on a sort of u uh horizontal scale where uh whether you require backend or front end scale in Drupal uh someone with backend skills that can do most of the tasks in Drupal whereas with the with front end you can do just a little bit of tasks

you do you can do HTML CSS so on. Uh to put this in perspective, if you look at something like React where um the backend developer has less control, uh more control is moved over to the to the front end version. Like React very clearly moves for example the state management from the back end to the front end. So now the front end developer can natively manage

all of that in there. To to help contrast this even further, if you know Nex.js, What it's trying to do is essentially trying to move even more of that control over that application to the front-end developer. So, so that the front-end developer can be productive and and without having to learn backend skills or talk to a back-end developer, they can manage those tasks. And and I have

one more example to to help contrast this with something like HTMX where you could say that that's again that's a JavaScript library but that that's a JavaScript library that is designed for uh an application that needs to be very backend centric and what is it that you're building defines what is the best tool for what you need. The challenge with Drupal is that as we saw before

Drupal is creating marketing experiences, but it's a backend oriented system. That's a mismatch between what our market expects, what the use cases that it's used for and between what our architecture optimizes for. So I have another sort of conceptual slide that I that that I will get back to later, but I want to introduce the concept. Um so the bottom layer in here are the sort of

foundational pieces of your your uh digital experience. They are your your content management. They might be your digital assets, search, commerce, anal analytics. Sometimes all of these are managed by Drupal. Sometimes Drupal integrates to external systems to achieve these. But often times it is Drupal that that that still one way or another handles those. And then you have on top of that the experience composition which is

essentially what is it that the visitor sees. So the so the visitor doesn't see what your CMS or what your damn assets actually look like. Someone needs to put it together into what the end user actually sees. And the experience composition is is essentially in Drupal. It is your theme. It is it is where you define what it what the CMS what other things what they output

what it actually looks like when it's delivered to the user. Uh so it could include things like components, layouts, templates, essentially your your your design system and uh doesn't matter where from which system whether it's Drupal or other backend system uh that data comes from theme or the experience layer puts it together into something that as a as a whole just represents your your brand. So now

if you go back to the previous slide and and and then uh look at where does the experience layer in Drupal fall in it's essentially where we have divided the experience layer in half. Uh you can you can you can debate where in that that spectrum it is but it is still fair to say that that in order to build an experience you can't just write front-end

technologies. You can't just write tools that front-end developers know. And this is where the mythical Drupal femur comes in who is responsible for creating that that experience. They they need to figure out how to do back end and uh and and front end. And that's probably why a lot of us in this room actually are this mythical triple dreamer who who know backend and and front end

and and can put it together. If you go back into the what kind of exper expertise we have in the market, uh if you if you look at the skills that people have, there's actually a lot of convergence. There's a lot of front-end technologies out there, but there's a lot of convergence on on how you can conceptually put those together. Like if you look at Vue.js and

next uh React, if you look at KNX and Next.js, there's differences in them, but they're not fundamentally different. If you know KNX and you go look at Nex.js, Yes, you can sort of piece them together because they are so similar conceptually from one another. So there's a lot of concepts that you have to know as as a front-end developer, but the tools themselves can be can be

can be switched. Obviously, there's a lot of craft that goes into knowing the specific tool that you have, but at least to get started with another tool, you are not at a loss to to do that. However, the challenge with Drupal theming is that it introduces like a whole new set of concepts on top of that that are not applicable are not something you can learn from

from those other other tools. You also can bring them back very easily back in there. So, those are things like Twick templating language um which in a way it makes sense. It's it's from Symphony, but it's not a very it's not a front-end oriented uh um templating language in any way. The the challenge is that even if you know Twig, Twig itself is is is pretty easy

to grasp. Um you still have to understand how the render pipeline works so that you understand how your templates get loaded. Uh you need to understand how does the data actually get into your your template so that if you need to for example change the date format of your of your data, you need to understand how you can do that. And you may have to even understand

things like cache invalidation and and and and tags because of if you just pull in data from from arbitrary um objects that are passed into the template, you might actually introduce bugs in there. And then we have systems for library and asset management as well. That is uh unique if you compare it to to many of these other technologies. So, it's a lot of skills that you

have to acquire in order for you to uh be able to leverage uh the power of of Drupal. So, if you think about that front-end developer uh looking looking at different solutions that they might pick um it is a it is a pretty big ask to ask them to take all of these skills um to to learn. And then if you think about also the the front

end developer can you're someone who is not necessarily working for a fortune 500 company or a huge university like what is the value then that you get is is are are those two balanced for them I think in many cases they're not and that's the reason why they end up picking other solutions even though there there could be still value that they could gain from Drupal. So

this is the site builder vision for Drupal canvas which is that any front end developer can create ambitious digital experiences fast and and this is using Drupal of course because it's it's for Drupal canvas. So I want to talk about where we are at that today and and and what we're doing to improve that further. So you may have heard that we are adopting tools like React

and Tailwind um as part of creating components in interup uh interup canvas. Uh I'll have a demo in a bit on what that looks like. So you can use technologies that you already know. Uh we also have an in browser code editor uh which allows you to get instant access to fully configured def environment. Um obviously not everyone's wants to use this. We also have local local

development tooling so you can pull in those components locally. I also have a demo of that um in a bit. Uh the benefit of the in browser editor is that there's actually a lot of other other tools nowadays that do in browser code editing as well. Uh there's even tools that actually integrate with GitHub where you can just go from GitHub into um an in browser u

editing experience. Um I believe this is something that will get more popular uh in future because of there's just less of a reason to have a dev environment if you have a really good dev environment online. Um with Drupal canvas you can define your configuration uh easily using the UI. Um you just select which of the uh which of the props um you want your your component

to have and it's it generates a config automatically. We have the visual page builder which then allows you to hand it off to a marketing person to create things with. Um so it's not just a static codebase. uh we have governance models that help you uh define uh what your editors can do in the um canvas editor. So can they publish? Can they edit components uh so

on? And then uh lastly uh but not least probably from my from my opinion one of the most important ones is that the the rendering has been simplified radically where you don't actually have to know PHP or Twig in order to be able to use Drupal with Drupal canvas. Drupal canvas applies this design system mindset pretty strongly. Um I'm I'm using components as the as the first

example since that's what we implemented first for Drupal canvas. Um the idea is that you built your components once and then you can reuse them for whatever use case that you have. And this is important because of um this is this is where you are driving the the the building blocks based on what you expect in the front end instead of defining them based on your your

data structures in the in the back end. So you can actually go in look at the design break it down and then actually implement it based on that instead of knowing instead of having to know at that point what module you're going to use to to implement the feature or knowing what content type is going to be displaying it. So it's actually a big deal to have

a capability where you can actually work in parallel both the both on the front end um experience and the and the back end experience. And so as I mentioned the goal is that essentially we push that blue line to the left and with Drupal canvas you could you could then manage the whole um experience layer. So let's take a look at a demo of how this actually

looks So I'm going to start by creating a component uh using the in browser code editor. So that's the simplest way of creating a component. I'm going to Tailwind UI which provides uh predefined components. You can download them either as HTML or or React. And uh I create a component in the in the UI. I copy and paste that. We can see immediately that the React code

that we got from outside. They don't know anything about Drupal in there uh just works in in here. And uh I click add to components which adds it to the component library. Meaning that now it's available for content creators to create pages with. We can drag it on a page. It works in that context as well. Now I'm publishing these changes and viewing them on the front

end. And tada. That's how we got our React component loaded in Drupal. Obviously, that wasn't that was just a static component. Uh, in the real use case, you would actually want to define those props that allow your content creators to specify uh what they can edit, what text can they modify. So, I'm adding a prop to modify the header of this component. And we can see in

the preview that it shows the example value from there. Now if we go back to the to the uh page we can see that the prop is available in there and we can make the change. If you've used canvas you may have noticed before that you were not able to use you were not able to change props for components that are already used. That's something that we

fixed in the most recent release. So um that's a great uh new feature for those that are already using using canvas. But that's essentially how easy it is to create React components in in Drupal. You don't have to figure out build tooling, import maps, um really anything because it's it it's it all just works um in here. It's a pretty stark difference to if you if you

go back to how it was developed um React with Drupal uh just a few few years back. So for those who actually don't want to use the in browser code editor and want to use their own ID, let's take a look at what what it looks like. I'm using the canvas CLI in here. Um it uh pulls the components to a separate codebase locally. Um it so

you can have a separate GitHub repository which includes your components. So you can have a one library that is your compon uh one repository that that is your component library. Then you have Drupal separate from that. So you can have your front end developers working in that We can see that that created um these components locally. I'm going to modify one of the texts in here. And

as I'm making changes, you might be wondering, okay, so what can I do with this component locally? So I'm actually using this workbench uh tool that we provide. Right. So that's called canvas workbench which allows you to render the reactbased um components locally. So it it renders the same as it would be in canvas but on your local. So you can do local development of your components

without having to having to go back to Drupal. And now that we push those changes back, you can see that the change appears immediately in the in the Drupal sites. The great thing about Workbench is it's it's very similar to Storybook. That's essentially what we're competing with in a way. uh it serves the same purpose as storybook, but the idea is that it reads directly the format

that cannabis uses and that it can then you it can essentially provide you what storybook provides without having to have separate stories files. We are also adding additional capabilities in there in future so that you can do more complex uh capabilities um in there such as for example adding configure your example values for your props through the through the work prints which is something that storybook doesn't

allow. All right. So let's take another look of where we use the component uh in a different context now. So I'm actually configuring now the display of a um content type using the same component that we just created. So I'm creating a new um content content template in here which is very similar to the view modes that Drupal has. Uh it has the same tools in here.

So we can drag and drop we we can drag and drop the same components in here. It has the same props available in here but now we are linking the prop to something in the back end. So now we're actually displaying data from the the Drupal back end uh in here. Now if I go change this this node uh this could be something that your content creators

modify, you can see that the content changes in that So that's a big advancement because of instead of having to create different components depending or or different implementations depending on if you're using a view, if you're using a node, if you're if you're uh building a web form, uh you can now create single component that then can be used for for uh multiple uh use cases. Obviously,

it puts a little bit more pressure on the design and and sort of front-end development breaking down it the right way so you can actually build these things. um in u this component componentized way. But um ultimately it will simplify the process because now um everything becomes more transferable and generic. And this is one of the innovations that actually makes uh Drupal CMS also much more powerful

in its site templates because if you can create component libraries that regardless of what modules you use are are still um applicable. Um, so you can have a component library that where someone goes and then decides later what the modules are that you should use. So if you compare what the old way of building with Drupal looks like uh and what the new way looks like, it's

actually uh quite different because of in the old way in order to build that that uh banner component that we had in there, you would have to figure out what module are you going to use to build that banner first with. Are you using a block for it? Are you using a view for it? Are you using node for it? And you would have to somehow then

you know um define the data model for it using that module. Then to actually make it look like what do you want it to look like? You need to figure out what is that module outputting for the given thing that you just built. Let's say it's a block. Um it then has some specific templates that it outputs. So you need to now go and debug. Okay, what

is a template that I can hook into? Often times what you get out from the back end as the actual variables, the the props is not exactly what you need. So you need to then go to pre-process and and change those things. So you need to write PHP to do that. Basically everything up until this point is already uh in PHP. And then finally once you've figured

out those things you can write the trick template for it and add the uh theme CSSJS and the library uh for it. Uh in the new way as a front-end developer uh you just build the component out in there and then it gets connected to data using using Drupal uh canvas. So you basically have just two concepts that you have to have to learn and they are

pretty idiomatic in the sense that it's um props and slots are both concepts that many JavaScript frameworks already uh promote. So um easy uh mental model to apply for someone who comes in from that front-end development background. So um let's be honest about where we are with this. Obviously uh what you saw is great for a simple use case. There's many use cases that are still not

supported like if you have custom widgets, if you have custom field types, if you have entity references, entity types, content moderation, so on. All of these powerful capabilities that Drupal has. They are something that canvas doesn't necessarily support yet. It doesn't mean that you couldn't use them for what you're doing with uh your content types and and in in in Drupal. It just means that you can

use canvas for for those things. There's also many features that are just not natively uh uh supported by uh canvas. So so you can't necessarily fully own the experience layer for really complex solution. So that's what we are going to be working on in in in future. Um and then a major gap in the JavaScript experience is that we uh don't have JavaScript serverside rendering available for

that yet. There are some implementations for that. So there's for example lupus decoupled that has defined u a way to do sort of decoupled uh with uh Drupal canvas and then allows you to do um do uh serverside rendering of JavaScript as well. This is definitely something that we are interested to work on in in future to uh make sure that you can also have your JavaScript

compon components serverside rendered. Um, if you've been around, many of us uh have been around for quite a while. You've probably heard that there was a JavaScript modernization initiative. So, we've tried to write more JavaScript before. This is actually my second time of trying to I was actually hired at Aquia first time to try to drive that initiative. And I didn't succeed. It didn't go we didn't

get very far on that. So, we are much further on that. And I do want to sort of uh share what the major innovation was that we made in here which is that we essentially created a parallel experience where you can use the two experiences and mix and match them together. So you can still use the existing twigbased approaches that Drupal provides today uh in parallel with

the JavaScript way of building. If you have tweak based SDC components built in your Drupal site, you can still use code components. the single directory components. You can even place them in a canvas tree and in a way where you have a a twick component inside a uh JavaScript component slot or the other way around. It all works. Uh today we only support React, but we're actually

using Astro Islands architecture to implement this um combination of uh multiple things being mixed together. So server side and client side rendered content uh which would allow us to support other JavaScript frameworks as well. Uh so that's something that if you're interested to have support for other JavaScript frameworks, come talk to me and uh we can see um if uh we could make something happen on that.

In terms of uh where we are going with these things, obviously what I just showed you was pretty simple in terms of like it was a component that I pulled in. It had bunch of tailwind and uh that's about it. Uh what we will have something very soon I believe that we actually have this already released in the product. This is not fully documented yet uh and

there's some limitations in it which is support for third party dependencies. So you can actually now push components into canvas that depend on third party uh npm packages. So how it works is we essentially uh built it into an asset uh when you when you when you run canvas push and we send the built assets back into Drupal. We send all the import maps in there and

then um it just works uh in there. We also have um other design system assets coming in. So we have brand kit syncing coming soon. So you can push for example fonts and and and color variables from your from your local repository. You can you can already define both of these in your um CSS manually. But uh one once you have the brand kit syncing it actually

means that you can have your um non uh developer person modifying some of these uh using the interface. So you can provide for example color variables. So if if you have for example university side you might have different color schemes slightly different color schemes for different um different uh faculties in your organization. So you could allow them to uh configure those kinds of things through the brand

kit and you can define yourself what are the what are the settings that that uh get exposed in there and we have many improvements coming for the canvas workbench experience. What you just saw was uh something that we have put together pretty quickly. It's just a local de uh local development tool. Um and uh we we we put it together pretty pretty quickly this year and we

will be we have a lot of ideas on how we can improve that experience uh for future um little bit more concretely about using different kinds of components. So, so uh canvas has support for single dire directory components which I talked about uh um a lot uh in terms of like you can use both um trickbased single directory components and we have these JavaScript components but you're

not actually limited to those uh as well there's support for blocks as well and layouts is something that we are planning to add in in future as well and the great thing about these different um types of components is that in the UI when you have a content creator using them they all show up the same in the UI for content creator they don't it doesn't matter

what is the source of of that component um all of them uh look all right uh let's move on to the next big u topic which which which trees talked quite a lot about in in the keynote which is AI and unlocking the the site builder persona front end developer persona in 2026 uh it it involves AI for sure because if I go back and think about

what the ideal experience looked like 10 years ago which was a manual configuration through the UI. It now in the sort of in this age of AI it feels very slow and and and prone to human error and human error because of you don't know the tool uh what it does. uh whereas AI enabled workflows feel fast and and and and automated and uh especially in the

front end if you look at tools like lovable where you may have seen the de demo in trees notes um it feels really that you can move really fast uh with those. So in order for for Drupal Canvas to to remain relevant in the market and and to win and and bring growth for Drupal, we need to make Drupal the best CMS to work with an AI

assisted workflow. Doesn't mean that you give a full control over everything to AI. It just means that we need to have the right tools and mechanisms to adopt AI as part of your workflow. And as was shown in the Dre note, we have two different uh mechanisms how we look at uh AI. So we have external Drupal AI which is for uh tasks like the design system

creation, content migration, uh anything that has to do with writing code or creating uh or even creating content types. And then you have the Drupal AI which is inside the interface which is more for the marketer persona which is for translating content, optimizing content for SEO, generating image image alt text and searching content. I do have this creating draft content in the middle in here because of

creating draft contents is sometimes a bit of a mixed task because of you have your content creators creating most of your draft content after the site goes live. But actually when you are building an initial version of the site, it is not uncommon that you have your developers doing a migration or some sort of initial set of content in there. which is why we're also looking to

include some content creation tasks as part of the development tooling so that you can really use your full set of um development tool the development tooling that we have for this external Drupal AI to also create content. So let's say if you're doing a content migration that you can use AI to power that type of uh workflow. So essentially just to summarize is the development task the

developer task where you use something like a local development environment we use this external Drupal AI and then things that you run in your production uh where you have your content creators taking tasks um are done with uh Drupal So how that actually looks like is we have a development starter kit that we provide for Drupal canvas uh which provides some example components that show how components

are created in canvas. It includes some skills. The skills are also available in the versel skill uh library. And then once you've uh run a command to essentially um initialize your development environment, you pick your agent harness of choice. That could be cursor, cloud code, anything really. that scales.sh uh supports which is basically everything in the in the market more or less. Um and then uh we

have the import export the pushpull command which allows you to push and pull. The great thing about the the workbench that I showed you where we were manually reviewing changes is that the agents can also access that. So that's what one of the reasons why we wanted to create the uh workbench is so that agents can can can implement a faster loop from there because with storybook

we run into the challenge where in order for agents to actually see what it actually looks like it needs to write the stories file as well and then sometimes it was hard for the agent to debug whether it's the stories file or whether it's the component that is broken. So we wanted to simplify the stack so that agents can have single source of truth and and that's

what we use as the basis of the development and then you use Drupal canvas to create your your your pages content templates all of that and you have your AI created site. We are also looking into adding some MCP capabilities uh in future or APIs that allow you to actually then fetch context back from the AI create uh from from your Drupal site. So it could be

things like what is your content model? So let's say you prompt the AI to create a component that lists three of the most recent articles. Uh if it didn't have any context, it would have to just make up the the machine name uh the fields that that content type has. But if we provide APIs and skills to tell the AI how to go get that information from

Drupal, it it can actually look back from Drupal what are what are what what the content model looks like. And if you don't have an article content type, it could even offer that, hey, like looks like you don't have an article content type. Should we create one before we before we actually build this component? Uh so that's as far as we can go uh with it. With

this tooling, we're targeting three key use cases. Uh the first one is Figma, the Drupal canvas import. So that's a use case where you've implemented a design um that you just want to essentially import from Figma into into Drupal canvas. Uh the second use case is where you are you maybe have a WordPress site or you know some other site out there that you want to replicate

in Drupal. Uh that's where you can point the tooling at an existing site and it can um import the design from there and it can also import the content from an existing site. And then the third third use case is what you show saw us uh in the Dre note which is which is essentially AI generated site from brand guidelines. And this is probably something that will

get more and more popular in in future. Um where you essentially give AI context around what your brand looks like and then it interprets those and generates you the whole design system and design based on based on that. Um this this is a the third one especially was something where uh we identified this first six months ago and it seemed like this is pretty far out for

this to be realistic. I have to say that in the last I would say month or so there's been quite a few libraries that has come up that actually um inject design taste. So the problem before 6 months ago was that because AI basically it goes to that that medium like the the center of the the parabel and and like it looks average. So it does it

doesn't look great. It's it's like this average of everything. So design is the opposite of that where you want to be very opinionated. You want to express what your brand looks like in there. What's been interesting that there's now specific skill libraries that try to teach AI how to be opinionated about a certain type of design style and it's actually been fascinating to see how successful it

can be with that which means that also it's possible for for um us potentially in future to build actually skills that say that okay um in order to implement an AIA brand it needs to have these things and this taste and and and so on and then using that it could actually generate this. And the great thing about is once you built the skill is that obviously

if you build one website it's probably not worth it to to build the skill for that. It's probably there's probably uh using Figma or something else is is might be an easier approach. But if you actually if your organization has a lot of websites which is very common for Drupal users um it makes sense to look into how we automate that in there. So let's take a

look at what this actually looks like. So I pulled in another component from Tailwind just so that uh this is sort of the example of the existing site. I just told it that implement this uh uh a component that is similar to the design. I use the plan mode uh first to make sure that the the component is structured the the right way. Um it took around

5 minutes to create that one component. Uh then I can review it in the workbench. It becomes available immediately in there. So it essentially created two components uh for me. one which is sort of the container and then it has a slot where I place those team member components. We can see that it created the props in the YAML files directly in here and uh and uh

yeah now the now the AI prompt completed the task. So I run now again the push command. So this time I didn't have the component in canvas before I was pushing. So I'm not updating a change. I'm creating a new component in there. Uh now I'm going to canvas. We can see that the component shows up in the component panel. You can see the slots slot appears

in there and the props appear on the right sidebar. So if you wanted to, we could change all of the text uh in here. And this is something that your your your nontechnical user could then do as well. So, I'll publish that and just preview how it looks like in the actual site. So, this took me I I recorded this actually um last night. Uh it took

me I think seven I think the video was 7 and 1/2 minutes uh and I got it done in in one try. So um it's it was yeah pretty good and it this was a very easy example obviously because it's one one component it had a very well- definfined starting point but um the tooling is getting a lot better so that u you can do much more

complex use cases with it as well. Um, so this essentially def uh shows up what the new creation workflow looks like. And this is something that I as a front-end developer sort of felt I I sort of felt bad in the in in the beginning because of I felt like the the the craft of what we do was was changing so much that what is it that

we even do as a front-end developers and I realized that a lot of the value that I add is actually just it is that going above the the medium building the actual like highly consistent high quality components in there and that's the second part which is that what you get from AI it's it's you can get to really really good results with it but where your brand

and where your work stands out is how you push that to the um something that actually stands out from there and a lot of the work that we as as sort of developers will be doing will be more in this understanding and tweaking and reviewing and and and publishing but it also means that and and what made me feel good was that because I remember from working

on client projects. It's it's it's a constant pressure of doing things faster. And it was I've always felt that I can't actually get the quality that I wanted to get because of it just took so long to get even something basic in there. and and sort of what made me feel better was that this might be our opportunity where we can actually redefine what that looks like

because of now um actually it's much more feasible for for us to to push push the boundaries with this especially because a mediocre now is is so um it's it's it's so much easier to get to that so people will appreciate design also and and and great craft more so going back into the digital experience uh and experience experience composition uh diagram that I had. Um how

I think about this uh in terms of AI and and how it plays part in here is that if you try to split these two sort of the the the lower level and the middle layer is where the the center layer of this is something that has a fairly short life cycle like it's it's probably three to five years where you essentially you do there's this constant

cycle of rebranding organizations to look fresh. Um so and and I looked into different kinds of statistics. It seems like organizations are often like three to three three to five 3 to six years is is is when they essentially rebrand again. The lower level in here is is your content your long assets. And these are things that stay true even if you rebrand your organization. There's probably

things that you have to update in there but a lot of it still say stays the same. Like even if you rebrand your university, it doesn't mean that what you fundamentally tell what how students apply to your university, it doesn't change. It's just how you deliver that message that changes in there. And that's where I think that the bottom layer in here is where we are actually

not necessarily going to see as much um acceleration from AI. going to be different approach at least that we get from from AI because of you have to be very concerned about security because you're dealing with permissions you're dealing with sensitive data in there potentially you have to deal with per performance in your backend you need to think about sustainability because if this is something that actually

stays true for a long time if it's if it's if you're not going to throw it away in three years you actually do care what goes in there so you want to be very careful about what you did what you do in there but then the experience layer is where I'm calling it I coding to to make it sound a little bit more radical. Obviously, you still

have things that you have to consider, but they're different from what you have in that bottom layer because you're you're more concerned about accessibility. You're concerned about usability and and just how does it comply with your brand? What kind of message does it give out? So very different kinds of skills and that's where the benefit also of separating this the the the people who work on these

where giving the front-end developer the access to actually work in this layer where we have different considerations to be making uh giving them access and power to uh actually work in there. uh whereas then you have the agentic uh engineering layer in here which is the bottom layer of that where you would have more back-end developer type of role working uh in and what is important for

Drupal canvas is to define the the the boundaries the right way so that we can actually do what is on the on the center layer a safe way. If you think about the the code components that I showed, the great thing about those is that they only communicate to Drupal Droo web APIs, which means that the API that is used to power those components. All the content

that is coming through uh to there is powered by JSON API, which means that um it's already a codebase that has been hardened that has been proven that it's that it's safe. So that your risk of of running into the the issues that you have on that bottom layer are lower. So it doesn't mean that you you you can completely for forget about those things. It's just

that your risk of of of um running into those challenges there are much lower. So some of the upcoming capabilities are primarily expanding what you can use external AI for. Um so right now uh we have the capability to uh create components externally. Next, we will be adding support for create uh creating uh pages for the migration use case where you need to migrate landing pages from

another site for example. And then uh we will be adding support for things like uh creating uh content templates using the external AI and and creating available regions header and footer using using external AI as well. final section of the talk. I get asked a lot by Drupal developers is when can I use canvas for more complex sites because we've been very deliberate that hey we are

ready for um for for smaller sites and for bigger sites it's going to take a take a while and there's been a lot of discussions that I've been having with um uh developers in the team uh uh product manager colleagues that I have to to figure out what is it that we need to do to actually get faster there and there's a realization that we realized which

is that We've been replicating a lot of capabilities from Drupal in Drupal canvas uh today and there's a very high cost uh in doing that. There's high engineering and high um high engineering cost to implement it and there's a high cost to maintain it uh in the long term. So we've been thinking about how could we reduce some of that duplication as we go or at least

reduce duplication as we build new capabilities so that we can move faster. And so this is a framing that we are applying. I can see that Jess who is a release manager of Drupal is nodding in the beginning in here. So I can see that we are probably at least thinking about something that is that is the right thing. Um so that's that's great. Um I'm going

to show one of the things that came out of this. There's more because this is very new for us. This is the first time I'm even talking about this uh really. So uh outside of um the team um so um I want to show the first thing that came out of this. There's more in future that we can we can uh derive from this. Um the first

is essentially you want to lean on the the CMS capabilities that Drupal provides. Canvas provides today an isolated data model but Drupal has a very wellestablished entity model uh which is provides all the you know enterprise capabilities that you would need like translations, workflows, permissions, validation all of those things but they are disconnected today from one another in the sense that we use it but we the

integration between the two is very shallow. um we don't deeply integrate with it and actually we realized that by adding a single capability which is actually to be just able to reference entities from the entity model is something that will unlock a lot of these capabilities in interal canvas. It means that we can also simplify future capabilities that we add into canvas. Um the first one being

we are looking into symmetric translations. Uh we are working on that in in Q2. Symmetric translations is actually really hard. It's a very complex capability to have because of, you know, there's some fields that you want to translate, some fields that you don't want to translate and and all everything that goes into into managing that. The great thing is that Drupal has already figured it out in

the CMS. So, what we're doing is that we're adding the entity reference which allows you to reference entities from from the entity model. Uh, and we add a basic translation system for canvas which is more penated, easy to set up, easy to build. And then we allow you to reference entities from the canvas which can use the full translation capability that Drupal offers. So you can guess

get best of the both depending on uh what is the need of of complexity in the translation that you need. So that's what we are um going to be thinking as we move forward. it will increase the the speed at which we can deliver uh this these advanced capabilities and the engine reference is the first one that will unlock a lot of what Drupal provides today for

those that use Drupal canvas. I do want to actually give another example of that uh which is that uh content templates the feature that I showed where you're mapping entities from the u entity entity model uh into a uh template I I explained that the not all of the field types are supported in there. So that's that's a challenge. However, JSON API already supports all field types.

So we can actually get that data in the components. However, there's just no way right now to connect the two. With entity reference, what we can do is actually you could create one component that is your uh product display component. That may not be the right way to display it, but it can essentially you can give access to the whole entity uh through JSON API then through

the entity reference uh to something content template. means that okay now content templates you may not be able to do the linking to every field type but there's actually there's a way to get the data in the component for every single field type that Drupal has in JSON API supports something that we haven't had before is road map uh I could actually I had a friend of

mine mine Mike Herchel during triple cam Florida tell everyone every attendee of the conference to come ask me for a road map uh it was a very fun experience uh he also told everyone to by beers for everyone who has contributed to Drupal campus which is also a very interesting experience to have. Um but I did take action from that and we now actually do have a

published road map. Uh um so you can either scan the QR code or just go to drupal-canvas.com. Uh it is a site that is built with Drupal canvas. Surprise surprise. And uh we will be keeping it up to date as we go. Uh on that road map you can find dates for things that we are working on currently which are in the now column. Uh the ones

that are in the next and later columns they are they purely represent sort of their relative priority right now. Uh we don't have dates for those capabilities right now. Um any feedback that you have uh is still uh is welcome on the prioritization and what we have on the on the road map. All right. So what all of this means for you, uh, if you're already building

Drupal sites, canvas is extending what you already know. So your skills are are still valuable. Uh, they're actually more valuable, uh, not less than before, especially now with the new additions of leveraging more of the entity model. Um, it means that you can actually do more powerful things with Drupal uh, Drupal Canvas than before. uh if you are if you're hi hiring or being hired it's important

to consider that actually Drupal canvas does change the skill set that is required to work with Drupal um so it's good to think about what it means for hire uh for your for your hiring strategy and if you're evaluating for uh Drupal for new projects uh Drupal can now actually serve uh much a broader spectrum of sites than it could before um a lot of customers a

lot of Drupal users that I talk to they actually don't use Drupal so many of them use other tools as well. So this is something to think about when uh if you are using Drupal in your uh in in your uh set of tooling um are there other things that you want would want to use Drupal now for so that you don't need to manage um there's

a lot of great content on Drupal canvas during the event I didn't go into a whole lot of depth in terms of how to use the specific features or how to build with canvas I wanted to focus more on just what is it that we've built how we think about it and where we are going uh these talks that we have in here will give you a

lot of uh in-depth knowledge on how you can build with Drupal Canvas. In terms of providing feedback or just ask um asking questions or seeing where we're going, uh I I recommend joining Drupal Slack and the Drupal Canvas channel on Slack. Um we it has gotten fairly active since we since we released the 1.0. There's a lot of activity every day. So uh join the fun and

uh uh provide us some feedback and questions. That's all. Uh thank you. I believe that we have few minutes for questions. Maybe if anyone has a question. Seems like maybe no. All right. Easier for me.