 Okay, let's start. We don't have a lot of time, only 20 minutes, so let's start on time. My session is Drupal, a tool for JavaScript developers. My name is Wolfgang Siegler. Also, you might know me as Fago. It's like my Drupal work handle. I'm like a managing partner and in situate tonomics, like we are a Vienna-based company. We also like focusing on doing the Drupal with Stack, also called Drupal. Some of my contributions you might know me from in the past. I worked quite a bit on Drupal Core, like doing all Drupal 8 core development. So I spearheaded the Drupal 8 entity API and I'm subsystem maintainer of the type data API in core. I'm also involved with some content modules, also around our stack, like Lupus Custom Elements Renderer and Custom Elements Module, but also did a lot of popular Drupal 7 module, like Rules module, entity API Contrib, Fill Collection, Profit 2, and that kind of modules. You also find me under the Grillefager on Twitter. But let's talk more about JavaScript. The reason I would like to talk about it is because JavaScript frontends are just really popular. Nowadays, when you check about web frameworks' popularity, this is a server like 2021 from Stack Overflow. I mean, it really mixes back and frontend frameworks, but still, at the top, it's pretty clear. It also reacts, and there's Angular, Vue.js, also pretty high on top. So modern JavaScript frameworks are really popular, and I would say they are here to stay. Actually, there's also Drupal on the slide. It made it already on the last place, but it's still there. But I think with that, when you start with web development today, it's really a new generation of web developers. So it's not so likely that they are actually starting with Drupal today. They will probably, if you go to university, you have courses more like in Detroit, React or Vue.js, some similar framework. So how does Drupal fit in that kind of landscape, and how do those new web developers relate to Drupal? So I wonder could those, for those JavaScript frontend developers, just be like Drupal via tool that they're using so that they become like Drupal site builders, and Drupal becomes one of the tools in the toolbox. And actually, during the past three nodes, and also I think it was in May this year, he blocked about that Drupal. He wants to make it actually for ambitious site builders and make that also the frame for the development for Drupal 11. And given that, I checked that, is that a fit? So what is an ambitious site builder? So he actually describes an ambitious site builder as someone who sits between the developer, probably backend developer, and content offer. And he also describes it as someone who gets a lot of things done just by the UI, by installing and configuring modules and doing some configuration. But then also he says, yeah, and when needed, then you use some custom code to just make your site behave exactly the way you want it to be. And this is, I guess, that force part because, like, when someone just starts development and starts with JavaScript, then you are not proficient in PHP, and there's probably a high barrier to get to Drupal PHP development when you're just into that. But then at the same time, like those small customizations, I think they mostly happen close to the user, like in the UI, to the user interaction. And then at the coupled site, that mostly means it's actually in the front end. So then it fits again because then, like, this is where the front end developer has his focus and his work anyway. And then the typical needs could be just, like, zero code configurable via the Drupal user interface. So I think that way it would work very well for a front end developer to just be, like, an ambitious site builder to Drupal and focus on development in the front end. So what would, like, a JavaScript developer who hypothetically then would work like that with Drupal need? So my thinking is, like, first off, they would use Drupal as a headless CMS. That would be the role of Drupal, the content provider. So they needed, like, configurable data model. So I think we are pretty good with that with all the field UI, although it's not necessarily that much focused on, like, the data modeling part. I think it's still pretty straightforward for the use case and we're also pretty good with that. And also they really would need and expect a great editing experience from a headless CMS. So, like, we also have, like, some solid editing experience, like, built-in also, like, with renewed admin theme, claro theme, I think, Drupal is good on track there. Then, like, it's most important to think when, like, a developer evaluates things so that they can get to some quick results so they can actually see, they can get the job done quickly. So for that, probably, yeah, I think it becomes more and more popular to just go with some hosted service because that's the quickest way to get started with something. So maybe some managed service or cloud hosting. And then, of course, I also like the developer experience, like, is the critical, how are the APIs, how quick and easy is it to work with that system. I want to have a little bit closer look at those points. And so I checked, like, what are the popular CMS options that, like, typically, front-end developers would use when they are looking for a headless CMS. So I was trying to also, like, go in a little bit and, like, kind of do the research from the perspective of a front-end developer. And that's, like, what I've come up with. So, basically, there are, like, those two main categories. They are, like, the managed services of the service and, like, the open-source camp. The managed services, like, there are a couple of big names, like Contentful, Prismic, Storyblocks, Sanity, and so on. So there are quite some providers there. And then on the open-source side of things, there's actually a few who are actually both, like Directors and China. They are both, like, an open-source system, but they also are offered, like, as a managed service, as a SaaS product, where you can just launch it and get started very quickly. And then there's Strapi. Strapi, I think, is a really interesting case because, also, like, what they are saying if you go on the website, Strapi is the leading open-source headless CMS. It's 100% JavaScript fully customizable and developer-first. And that's pretty interesting. They say they are the leading ones. And, actually, if you, like, check out some common metrics, like GitHub Stars and, like, where to find these, you find a lot of references about Strapi. And it's interesting because you don't find a lot of references about Drupal. So when you compare it, it's like, Strapi has, like, that features, like, according to the website, it's open-source, it's RESTful, or GraphQL, so it offers both APIs. It's really customizable and flexible, and it's self-hosted. Well, it sounds a lot like Drupal to me, actually, so it's not that different. Well, it's JavaScript-based. I guess that's also, like, a big main reason for the developers to get started, like, with a JavaScript-based backend. But then there's also, like, the big headline, build apps fast. So how about doing headless Drupal fast? So, as mentioned, for quick results, like, the managed service provider is something that you need. I mean, there are, like, a couple of Drupal hosting providers who just provide that. So I think that's also there. I mean, there's, like, I don't know, Pantium, but from this age, I think also Acvia has an offering like that where you can just very easily and quickly spin up a machine and get started. And there's also, like, quick test-drive options, like, just a Drupal part project, where you can very easily spin up, like, Drupal development environment and Git part and also simply test me for trying things out. So there are ways to get quickly started. When looking at the pleasant front-end developer experience, again, we have, like, many options. Like, there's JSON API in Drupal Core, and you can, like, extend it with the JSON API extras to customize it more. Then there's also GraphQL module where actually there was version 3 which was quite popular in that it's just exposed, like, Drupal internal data structures directly. Now there's, like, version 4, which is more customizable, but you need to set up your own GraphQL schemas. And there's also, like, a more recent GraphQL-composed module which, again, tries to make it easier. And, like, the last one, the Lupus Custom Elements renderer module is, like, the one module we are also maintaining and could start it, like, as part of Tomomics, which is just basically a module which provides an API for every page response in, like, a component-oriented API. So there are a couple of options. But then that's not necessarily quick. How do you get started? What are you doing? I mean, every option, you need to configure something for making it work very nicely. So I think there's everything there, but it's not necessarily the quickest thing because you need to set up things. And then there's also the possible hurdle of how are you handling configuration? I mean, it's, like, common best practice in Drupal to do configuration, stage it. But then I don't know, in that use case context, is it even wanted? I mean, it can be easily skipped. So that's... So maybe it's not really a problem. But then it could also be an advantage. I mean, it could be some really decent offering also, like, to say, okay, you do it in, like, a staging environment, test everything, and you can nicely then push things out on production. And you don't have, like, I don't know, like, a managed service you probably would have to actually try data model changes on production. But, yeah, it seems a bit scary. So it's a good feature. But then how would a JavaScript developer use it? I mean, when they don't have a local Drupal development environment, there's no place to easily run trash during configuration export, things like that. So, yeah, there needs to be some tooling around it. So some hosting providers have toolings like that, which make it easier to, like, to do the configuration staging workflows. But then there's also some interesting modules that automatically create pull requests from the Drupal UI. It's like, so, like, basically, you do your changes in the Drupal environment, and when you're done, you could, like, automatically have a pull request graded against the repository, and then it goes all by the regular deployment workflows via a code. So that, I think, would be also, like, a pretty nice option to explore with that use case. But then it doesn't solve how do you get started? So I think this is, like, really the main issue to solve how to get started quickly and which option to choose. So, yeah, there are plenty of options. There are also plenty of options about hosting, which is good, but then again, when getting started, it makes things difficult, which one should I choose? Then there are the options about APIs, and then how do you set up the APIs? How do you solve authentication in a couple of contexts? There are many options on, like, how to tackle all that kind of problems. So I figured, yeah, well, we have guides. Probably it's documented, so I checked out, like, the documentation for that, and there's a guide on the Drupal Drupal, which sounds really great at the first place, but then when you look at it, it's rather disappointing. It was, like, really well-intended, but it just never got really finished. So it's really a work in progress, and when you look at it, it leaves you with more open questions than answers. So I guess when you find it, it's not really helpful. It was even then I noted, like, when you look it up, it even was talking only about bosses and docs for, like, decoupled Drupal menus, because I guess that the documentation was created during the decoupled Drupal menu initiative. So I actually figured I had permission to fix that, so I got this one quickly fixed, but still, all of the documentation pages, basically, if you click on an item, it needs work. So probably we as a community should work to get some more documentation on, like, a better overview, but I think it has to mean it's, like, it suffers from the same problem that I was just having approaches, so how do we decide which one to document? So how could we solve that? And, like, I think the idea, and, like, would be here to promote more, like, different kind of decoupled Drupal stacks. So to basically also to have, like, when you start, you would decide on what's the stack you're interested in, and then you have documentation for that stack and also, like, setups that work easily for that stack. So I think that's, like, a way we could solve that. And we actually, we got quite some decoupled Drupal stacks, so, for example, there's the next Drupal project, which I think is doing, yep. Thanks. Which is, I think, doing a really good job in, like, solving the marketing issue and, like, clearly communicating what it can do. It has, like, a really nice website, and it also has a guide to get you started. So I think that one is doing a pretty good job here already. Then there's also, like, a Gatsby module, so if you're using the Gatsby front-end framework, that also seems to be quite straightforward. I must say I haven't tried it, but it looks really pretty decent as well. Then there's, like, the loopers, the decoupled Drupal, which is the stack which we are currently working on and getting started with, really, to make also the decoupled Drupal easier and component-oriented with an ArcGIS framework. And then there's StructGIS, which is also, like, a solution with an ArcGIS, which is more working, like, I would say it's, like, tries to give you an experience which is more similar to the Drupal theming layer. It's also a pretty interesting project and has, like, a really good documentation website as well. So, like, there's plenty of options and there are even, like, more, which I forgot to list, like, there's content as you may as, like, which is also good, like, with getting started with JSON API. So there's really a lot of things already there. So how could we make this easier, really? So I think this actually goes really well with the current initiatives that we have, like, running, like, distribution recipes, I think is, like, really perfect for that. So it's also accepted that problem, like, combining a couple of modules, adding that configuration that you need, so setting everything up so that you can get started quickly. So I think that's already, like, something huge which can help with that. And then, like, when this becomes also, like, integrated with project browser, it could be already really great so that you, like, when downloading Drupal, you could actually just, like, choose the stacks, like, one of the available stacks in there and get started with that. And once we have that, I think, I mean, we could make this an installed time decision. So when you start a new Drupal project and when you install it so that directly in the UI, when we have project browser and distribution recipes, I think it would be really great then to present the user, like, okay, and what do you want to do with the frontend? Decide, do you want to go, if it's traditional frontend, do you want to, like, use next.js or next.js, present the user that supported options so that then he can get started very quickly. I think that would be a really great way to solve it. And actually, it turns out that Laravel is doing pretty much that. So, like, if you go to Laravel.com, they have it directly on there that's basically bear supporting the Monolith or APIs, and they have starter kits for varying ways of doing the frontend. So it's pretty much that. And I think it's, like, really also the way to go for Drupal. Yeah, that's my presentation and would be really interested in, like, your thoughts or questions, of course. Feedback. Thanks. Yeah, I'll be quick. More of a comment, but thank you for calling out the old menus documentation-related stuff, and I agree, it needs a lot of improvement. And for anybody who's going to be at the contrib day tomorrow, I'm hoping to get some people together to work on that. We're not going to completely solve it, but maybe we could make it a little less embarrassing. I have a question about, for me, from my perspective, it's states and faults with the API, because I'm coming from when I'm programming React or something, you have just the API solving the JSON, and then take all the data and make some frontend with it. So I heard a couple of presentations, and I think when you concentrate on what people want to do when they are coming as a user on the site, so for example, just seeing the data, search some stuff or so, and what Drupal can solve is a good API, picking all the data inside, have something prepared for you to get your components outside, or have something to connect the search server or API to get some stuff, so it's mostly that all the backend ends in just a few endpoints that people can take and then use what they want. And is it too less from your perspective, or is this something you said, yeah, but we need more middle way between coupled and uncoupled, and Drupal has so much stuff that we want to get to the user of frontend development or what's your perspective on this? So raw API or get Drupal into the frontend in your framework, JavaScript framework? I don't think I understand the alternative. What's the alternative to raw APIs? First perspective, just get the API. Drupal makes all the backend, just API. Or, for example, when you have bundles and fields, ah, there's a button, get me some components out of it. And we make this for React, because React is a good framework that brings the advantage that you just get some frontend outside, but that the disadvantage is when someone will, with V or what else, he said, yeah, but only one framework. So what's your perspective on this? So I think that the way frontend developers would like to use it is more like to stay in control and so rather have more of the plain API. But then, and that's also like actually what our D-Coupled Drupal stack, like Drupal D-Coupled Drupal is about is to know to keep editors in control, because that's also like what's interesting when you have NCMS, maybe you want to have page builder layout, builder working and that kind of things. So I think that's the kind of integrations that are also like really important and that would make it as a platform really interesting. So I think it, in an ideal way, we would have both. So we would have the plain APIs, but also the more component-oriented way of doing it, and for that, some ready-made components, like have some libraries that just work very well and easily, I think would be great, yeah. So yeah, I guess the combinations. Sorry, we don't have much. We need to switch to the next question. Okay, thank you everyone. So if you have the cold screens, I'd like more.