 All right, you ready? You ready to dream a little bit or a bit more hopefully? I'm going to try to navigate like I have a lot of energy and I usually walk around. I also walk in the middle of the screen. I don't know what that means for the recording but I'm going to move a lot like you're going to have a lot of work with me. This should move if I press this button. Yes, it does. Excellent. Okay, so the future of Drupal teaming. A lot of it is dreaming and a lot of it is very energetic. So get prepared to spend every ounce of energy you have for today the next 50 minutes. Okay, so my name is Mathias Pellebein. I am a freelance Drupal front-end developer. I am one of the organizers of front-end United which is a global organization where we organize Drupal front-end events but I'm not going to talk about that today. I'm also the inventor of Componi. Componi is the thing that I'm going to be talking about today. It's also the little trail you see on the ground. It's my personal, how do I call it? I call it my ambition. Some people call it my tunnel vision. If you feel like you want to reach out to me, please feel free to reach out over at Twitter, LinkedIn, wherever you see this face online or a face that looks similar. I'm not going to be able to give you a lot of time to ask questions in person because there is a lot of things to cover. I have like around 500 slides that I'm sifting through and I'm trying to squeeze four hours into 50 minutes. But if you want to ask me questions, please go to slido.com, fill in the hashtag front-end. You can ask questions anonymously or in person I'm going to answer them all on Twitter afterwards because a lot of them require half a blog post to explain and I'm sure you're gonna have questions. So what are we going to talk about? When I say we, I mean me obviously, I just said that you can't ask questions or at least that we're not gonna have a lot of time for that. We're gonna talk about three things. We're gonna start off with an analysis and that analysis hopefully is going to show you the problem we collectively forgot we had as a Drupal community. And once I've been able to show you that problem I'm going to make you dream up a solution with me. How does that sound? Good. All right. So let's get started. We are going to start with the analysis. Mind you, I am a freelance Drupal front-end developer. So this, I don't know how many of you do back-end. This will insult you. It's with good intentions. It will only insult you in the first half minute, I guess. So mind you, the numbers I'm about to show you are very holistic. It's also holistic because I'm a front-end developer. And it's also to prove a point. Now the analysis was done on a project, quite a big project. We worked on this project for a year and a half with around 10 to 12 people full-time. So it was quite big. And after we delivered the project, we kind of thought like, okay, what did we actually build? What did we actually ship? What did we actually sell to the end user? And that kind of looked like this. Now the back-end layer, right? I'm going to start walking around. What you see here is the back-end layer, is the way of how we divide up complexity. So if you ship a big project, this is usually how that looks. So 62% of that you download. Drupal core. It's the big blue one over here. Okay? On top of that, now of course holistic numbers, but it's one massive project and it kind of fell to me that it was very similar to how other projects were. On top of that you download an extra 33% of contract modules, which only leaves you with 5% of custom code. Now when I showed this slide to my colleagues, my ex-colleagues, I was working with, because I'm a freelance developer, right? They were very insulted by this number. They felt like we worked on this for a year and a half. How is it possible? It's only 5%. You must have done it wrong. But the 5% is not a bad number. The 5% is an amazing number. The 5% means that you only have to write 5% and you can download 95% of it. Even if you ignore Drupal core, you can download, for every feature that you develop in custom modules, you can download eight other features first. That's massively productive. So it's not a bad number. The 5% means whatever you're going to build, you're going to have 95% built for you. A lot of tools are already there. And it's also one of the reasons Drupal got this big and this far because of this massive productivity. Now, we're going to do the same thing for the front-end analysis. And the number is going to be a tiny bit different. Yeah, so 4% is coming from Drupal. And this is just one project. Usually, right? Usually we try to strip away this little bit. We want to go ahead with this because we really don't like that 4%. And then we have 96% of custom code. You didn't follow the trail. So we have 96% of custom code. Custom code that we start from scratch nearly all the time. Now, what does this mean? It means that we don't really rely on already written code. We don't rely on what Drupal is giving us. We start from scratch nearly all the time. Now, if we put this back-end layer and front-end layer next to each other in perspective, then it looks like this. And the massive difference is really shown. Now, no matter if the percentage is a bit off or how much is going to be off, you're still going to have a picture that kind of looks like this, right? Now, this is what we call the back-end layer, right? Now, this is what we call the front-end layer. But that's a lie, isn't it? A layer. A layer for me in coding terms means an abstraction on which we combine things together. The back-end layer, we combine things like core and contrib modules and custom modules. We combine them all together with configuration settings and so on and so on. On the front-end, we don't really do it that way. It's not a layer. What you're looking at, in my idea, is a front-end blob. A blob because we have this personal need of compilation. And again, I'm a front-end developer myself. I can find myself in saying this, so I'm kind of bashing my own here. But what we're looking at is a front-end blob. It's a closely knitted together thing which you can't take anything out of. It's all stuck inside of it. Now, it's a bit silly if you ask me because how many of you do front-end? I hope to see as many. Ah, good. We all write SAS. We all write less. We all write CSS, right? Every rule of CSS, every selector that we write, we write component-specific, right? Everything we do is component-specific by its very nature in the cascade of CSS. Yet, as soon as we wrote that SAS, we compile it into one massive file, one massive CSS file, right? The personal need of compilation. When we write JavaScript, we do the exact same thing. Everything we write is component-specific. And then as soon as we ship it, we bundle it into one massive file. And then apparently, we seem to have a performance issue on the front-end. Well, yes, obviously, because we load in every line of CSS and JavaScript, any developer on this project has written for the teaming layer. So, yes, we're going to have a performance issue. Now, Drupal has been able to do it in a different way. Drupal has been able to give us the library's API. And the library's API, if you ask me, it's the single most amazing thing ever. You can't explain this to anyone else. I don't know whoever worked in WordPress or any other CMS. You can't explain this. The library's API, for those of us that are not deep into it, the library's API is a system on which we can teach Drupal to know when to load which assets. It's amazing. We can teach Drupal when to load which CSS file or which JavaScript file. Yet, how many libraries do you define in your custom team? I'm going to take a guess. One. Am I right? I don't know if I'm right, but if I'm right, then I'm probably also going to be able to guess the name. You're going to call it global. Right? Because this is one global blob of a thing. Now, if we start using the library's API, then a whole lot of options open up. Now, we have a 95% readability and predictability of what will come out of the backend. And if we have a 95% predictability of what will the Drupal backend give us, then why is it that we're not relying on any of it? And that's what's baffling me. If we would write all of our Shas and all of our JavaScript, the same way that we're doing right now, but we don't compile them together. If we get over our personal need of compilation, we're actually going to have components. It should load. Yes. We're actually going to have components. We're going to keep components. Maybe people, if you see a seat next to you, because I see two people standing in the back up. All right. So if we keep components separate, we don't compile them together. If we get over that personal need of compilation, we're going to have an actual layer of compiling components together or bundling components together. This is a front-end layer in my aspect. Now, I've worked already quite a long time in this way. And what I find is that one in three components we can actually reuse. And all of a sudden, the amount of blue is going to stampede over the amounts of red. And that's my dream. The dream for me is that we have independently teamed, functional, cutting-edge, triple front-end components by just keeping them separate. It's a very small notion, but it's amazing notion. Now, I could say thank you all for coming, but I'm not. This dream I had a year ago, absolutely a year ago, around the beginning of December. And I was dreaming about it at home. My girlfriend didn't really understand me. Well, anyway. I also dreamed about it at work. I dreamed about it so much. And as a freelance developer, they kind of figured, like, Mathieu is no longer working on the projects we're giving him. So we're going to fire him. Which is amazing news, right? Because they fired me a year ago. And in this year, I wasn't sitting still. In this year, I figured, screw it. I'm going to go for it. I'm going to dream this up. And I'm actually also going to build it. I'm going to open source. I'm going to give it to everyone. And the reason why I'm standing as a Belgian in Australian room right now is because I have the feeling that I cracked it. I really have the feeling that I fixed it. And one of the solutions is that we have to explain it well enough to front-end developers. And there is, we can't really rely on backend developers for that and seeing up the history. But this is how the solution looks like. The solution comes in three layers. And it also takes the shape of this horse. Funny story. I asked the designer, so the idea is called Componi. Okay. So I asked the designer, could you please make me a logo? And whatever you do, don't make it look like a pony. I'm really not interested in a pony. And he assured me that it's a horse. Exactly. Very frustrating. Now anyway, hopefully that's the only confusing thing. The very first layer I'm going to talk to you about is the new team structure. And the new team structure is there because we have to have a team structure that stops accommodating us as front-end developers to think in a blob way. And as soon as we can do that, all the rest is like children's play. Now, the new team structure is the very first layer. And I'm hammering on this because it's the only required layer. The other two layers are optionally built on top. However you want to use them or not use them, it's fine by me, you're still going to be able to use the Fundaments of Componi. Now, if my first assumption is correct, that you're going to like the new team structure, then I'm also going to assume that you're going to want to build all of these components in a very fast way. You don't want to have to rebuild and rethink your entire tooling workflow. So therefore, I'm also open-sourcing a tooling workflow for everyone to use so we can get this going really, really fast. Now, if my first two assumptions are correct, that you're going to like this one and this one, which I haven't really explained yet, then it would be selfish if you're able to create by default a lot of independent Drupal front-end components. You're going to be able to build them really fast and you're going to keep them to yourself. I don't need to explain the advantages of open-source and to this room. Look where we are. So therefore, I also invented or I created a platform invented. I created a platform where we can all share our components. Now, the cool thing is, as all three of these layers already exist, the platform is called Componi.io and from there, you can download the new team structure with the tooling workflow embedded into it. You can download it right now. Everything is open-source. It's free to use in the spirit of the open-source of Drupal. Now, the very first thing, the new team structure, first layer. It's the longest one to explain, but I think you're going to like it the most, too. If you go to the platform and you download the team, the team is going to look like this. You have three files. You already know these three files if you've ever opened up a Drupal 8 team. So an info.yaml file, libraries.yaml file and a .team file. You also have two folders and the three files, you can order those. They're going to be the same like any other Drupal 8 team. The first folder says essentials, helper folder, also not relevant for this presentation. The only relevant folder is the components folder. Why? Because we're going to accommodate you and not thinking in a blob way, which means all of the CSS, HTML, JavaScript, PHP or Twig that you're going to write is going to belong to a component. However, it means that you can still have your global component if you really want to. But you're going to have to see it as a component. Now, this is just an example, right? Let's assume that we would have three components in there. As we start working in the beginning, you're not going to have any teaming in there. If you download the team, there's no teaming in there. It doesn't do anything. It's merely a shell to hold a collection of components. Now, it's relevant to show you this because it's important to know that all the stuff you're going to write in the teaming layer, by default, you have to think and do which component does this actually belong. Now, very simple to explain, right? You have now three components. Very simple to explain this to a non-Drupal developer. If you go to inside a component, this is where it really gets interesting. Let's assume we have a status messages component. Then the first thing you should realize is that we have two layers. We have the root, and then we have the disk in this component. Everything in the disk is compiled from things in the root. It's very simple. The SAS file is generating the CSS file. This JavaScript file is optimized and linted and being put in that JavaScript file. This mild SVG is generating the SVG in the disk folder. Very simple to explain. The only two files that I haven't shown you yet is the library.yaml file and the status messages as html.twig. You already know these files. You already know what these do. Yeah, it's the first time you see them inside a component. Now, it's really cool to see them in a component because if you open up the library.yaml file from the status messages component, then it's again very simple to see what this does. It's linking to a CSS file. It's linking to a JavaScript file. And where is that? Where are those two files? Where they're just in this, right? It's completely self-explanatory. Again, super simple. No rocket science here to be found. Now, if you open up the html.twig file, this is where you should have your aha moment, even if it's stuck inside your head. We have an html.twig file and there we define html.component, right? But what if we attach the library that we just created onto the html that we just written or we just copied from core? Then all of a sudden we, what we're looking at, and you didn't realize these three slides ago, but this is the very first completely independent Drupal front and component and completely stands on its own. It doesn't need anything else, which is super cool, right? Because Drupal is going to load in this html.twig file and it's going to load in and they're going to see, oh, we're attaching a library called status messages. Where is this library? Well, it's going to find it in here, it's going to open that up and this one is going to link to the CSS file and JavaScript file. And a tooling workflow is going to make sure your dist folder is always compiled, which is pretty wild, right? We have, we're looking at the very first completely independent Drupal front and component. It's wild in my terms. Anyway, tunnel vision. What are the advantages of this new team structure while they're close to infinite? Like, I challenge you to keep asking me questions after the session. I'm going to be able to bore you to sleep. There are so many advantages of this, but I'm only going to be able in these minutes to cover the most cool ones, I guess. One of them is conditional loading. I've seen a lot of companies. I worked with a lot of companies, a.k.a. I was fired by a lot of companies, and they all are working within their own system of trying to find out how they can build front-end components and have Drupal load them in conditionally. If you work this way, it already is conditional. Everything is conditional, because let's say, let's assume we all know what the views in for the scroll module does, and we have to know for that that it's going to use this html.twig file. This module is opening up the possibility of using this html.twig file, which means if this module is not enabled yet, Drupal doesn't give a shit about this html.twig file. It literally doesn't care. It will never load in this html.twig file until click. You enable the module. As soon as you enable the module, Drupal on a page that it's going to need, it's going to say, oh, I need this html.twig file. It's going to find it in your components folder, it's going to open it up, and again the same thing will happen. It's going to find that library, and it's going to load in that CSS file. But only on the pages that that twig file is being used on. Which is massive, if you ask me. And this works by default. This has been working for Drupal 6 already, yet no one explained it to us well enough. Now, it also means that we have a big advantage for maintainability. As a Drupal front-end developer, I have written JavaScript, and therefore I have broken entire UIs. But what if, if you write JavaScript for Node article, what if you only break the things that you wrote the bug for? That would be pretty wild. You're still writing bugs, I know, but you could only break the entire UI on the pages that are actually using that JavaScript. Which is pretty cool. And that kind of brings us to performance, because if we only load in the assets as soon as we need them, performance benefits are huge. I would love to hear your guess on this big project how much of a performance benefit this is, but I'm just going to tell you, I'm too excited. For example, if you use, if you write a Node component, and assuming now every time I'm going to show a folder the inner structure of this component is the way how I explained it, then the Node CSS is only going to be loaded on nodes. It's not going to be loaded in taxonomy term pages. Or if you have a page component, well that by default is going to be loaded on node pages, and on taxonomy term pages. It just works by default. You don't have to do anything for this. And it boils down that one in 10 lines of your CSS and JavaScript will only be loaded on any page. One in 10. I'm not saying that I'm going to be able to optimize 10 percent of your assets. I'm saying I'm not even going to load in 90 percent of it. It's a 9 and a 0. It's massive. And my terms, this is enough to start using it today. Now, obviously I'm very biased because this is my presentation. Right? The other aspect of one of the advantages is flexibility. If you now think like, okay it all sounds amazing Matthew, but I'm not gonna do it. Like I'm just going to use a global component and you're gonna have to leave me alone. It's fine. Go for it. Only use the global component. And when you're ready and when you have some time on your hands to kind of go, I might want to reuse something out of my global component. Well, maybe you're only gonna abstract four lines of CSS. Maybe only one selector and two lines of CSS. And you're gonna create a library.yaml file for it. So you're gonna have a CSS only component. That's perfect too. You're already optimizing. You're already starting to start thinking in components. Or maybe you're going to want to create a HTML only component. And maybe that component is going to load in that CSS component you created earlier. Like it's super flexible in terms of how many libraries you want to attach. Or maybe you want to have a JavaScript only component. Or maybe an HTML and JavaScript only component. Or maybe an everything component. Whatever combination that you're thinking of, you're gonna be fine. As long as you stick to the fundamentals of the web, which is HTML, CSS and JavaScript. In that order. But you can tackle me afterwards. Now, we have loads more advantages. Kind of summarize them here. One of them is that we never have to start over. And that feels really good to me. Like they, we start on a new project. You can already start compiling things together. Not compiling, grouping things together from different projects. And also for a lot of business owners, this is very important. The reason why everyone is going headless these days is because we can't find Drupal front end developers anymore. Nearly everyone died off, to be honest. They all went to JavaScript frameworks or this new fancy thing. But if we, why are we going headless is because the teaming layer became very complex to explain. If we make it simple to explain again, we're back to building things for Drupal. We can again use the power and the strengths and all the advantages Drupal is already giving us in the front end. So it makes teaming layer incredibly readable for non-Drupal people. And if you in the last few seconds heard that I'm against headless, then you're not not right. I'm not against headless. I'm against people that take the deliberate decision of creating an entire super expensive project and rendering it completely with a framework of choice. I'm against that. I think that's really obnoxious and really not very, what's the word I used? I didn't write it down. It's just not smart. Because whatever framework that you're using now, you have the possibility of choosing a framework that is going to become the future Angular 1. You don't know. You literally don't know. Like, and it's fine to use it. I'm not against experimentation. Go for it. Decouple the components that you want to decouple and build them with those frontend frameworks. If you want to have reactivity, look at where that reactivity will happen in your website and implement it there. But there is a very high chance your static footer won't need to react to render. It's a very high chance. So experiment. Please do. I love experimentation myself, but only on parts. Do it on components. And working with components will give you that flexibility. Anyway, that's the hairy part of this presentation. I'm glad no one is leaving. Now, that's the first layer. That's the only layer that is required. If I get anything across, I really hope it's up until now. From now on, everything I'm going to explain is optionally on top. I'm going to start with the tooling workflow because if you already like the first part of this presentation, you're going to like the second part too. The tooling workflow, for me, I built it with Gulp. Now, how does that look? Well, it looks like the internet is gone. No, there it goes. If you download it, I actually lied 26 slides ago. You actually have an extra folder in the team. It's called gulpfile.js. Who, by the way, knew that you could have a folder named gulpfile.js. Random. Anyway, in there, all of the Gulp setup is built. You don't need to open it only for having a bit of configuration in there. Now, as front-end developers, we are massively... Let's go. We are massively opinionated. We rather quit our jobs, like I do, than to give up our opinions. And that makes us very interesting human beings, but also very good at our jobs, I think. It's a benefit. But it's also very hard, I found, to group front-end developers together and trying to make them work with the same tools. So, therefore, I made everything within the Gulp player optional. Literally. We have... I counted it on the way here. We have over four million different combinations that you can have. And I'm very sure you're going to find one combination in there for you. Every setting is divided up over project-specific stuff or environment-specific stuff. For example, project-specific stuff, let's say me and you are working on the same project. I'm using auto-prefixers, so I'm changing my CSS file to include which browsers. Well, you're going to have to use it too. Like, otherwise we're going to have different CSS files coming out of our setup. And then environment-specific things are there for developer experience. If I'm using Browser Sync that refreshes my browser every time I change the SAS file, it doesn't really impact the CSS that we're going to generate. So, you don't have to use that if you hate the damn thing, right? Now, four million combinations, I'm not going to go into them, but the way I'm going to show is that it's super easy to set up all the files that you want to edit inside gulp file.js and on config.js. Super simple. Local configuration, project configuration. NPM install, you run gulp and off you go. The amount of advantages this is going to bring is huge. Kind of features. I'm not going to go into what SAS compiling is. I'm very confident in the skill of this room. We also have auto-prefixing as a feature. We have losses, image optimization by default. We have browser syncing if we wanted to. We're lending automatically HTML, tweak, SAS, CSS, JavaScript, YAML and PHP. We're having JavaScript magnification, not the same thing as aggregation. It minifies your JavaScript. We're also doing, I think the next one is browserify and babelify for if you want to write cutting as JavaScript. We just still want to support older browsers. We have tree shaking. We have component-based multi-team compiling. I love how that sounds like. Component-based multi-team compiling. Give me a beat and I'm there. I'm going to go into this one. So it's component-based. What does it mean? Well, if you write page SAS, you're only going to generate page CSS. It makes it incredibly fast. Same thing for any component. So the Gulp setup doesn't really care about how many components you have. It's going to stay fast. And for that sense, the multi-team part, well, it also doesn't care how many teams you divide up those components over. Like you can drag out gulp file.js onto the root of your project and you're going to just link to which teams are component-based and you want to have the Gulp setup running in. Which is pretty cool, right? Component-based multi-team compiling. I dream about this stuff. Now, rebuilding Drupal cache. The Gulp setup is capable of rebuilding your cache whatever setup you have. Currently, a whatever system is ever going to be invented to support Drupal websites. How is that? Because the Gulp setup, you can, in the configuration, you can fill in the command needed for clearing your Gulp, for clearing your Drupal cache or rebuilding your Drupal cache. So for example, for Vagrant, it's a pretty old one, you could go Vagrant SSH and then ampersand ampersand and then cd to the web folder and then DrustCR, for example. So it always works, which means this is also now becoming explainable to a non-Drupal people. Because that's insane if you think about it. Like if you change an HTML.twic file, if you change the contents of an HTML.twic file, you can just sometimes have to rebuild your cache. We're not entirely sure. Like sometimes it's cached, sometimes it isn't. If you change the CSS file, that's never completely cached if we disable the right amount of caching. If we change a libraries.yaml file, well, yeah, you're gonna have to clear your cache. If you change the name of an HTML.twic file and you don't clear your cache, you're going to have a wide screen of death. Like if you know Drupal, it's very explainable why that is. But for front-end developers that don't care about Drupal, it's impossible to explain. So therefore we taught the Gulp setup how to clear your cache, which is pretty cool. For example, if you rename test.html and the testy component and you say it's new, well, you're going to get a notification that it's rebuilding your cache and if you wait four more seconds or however fast your local install is, you're going to get a new notification saying that it's rebuilt. It's pretty cool, right? Another advantage is that it's very refactor friendly. I've been doing the session now a few times, been traveling around a lot and I've met a lot of front-end developers, but a lot of front-end developers claim to be doing front-end development. A lot of back-end developers, I should say, are claiming to doing front-end development. But you're not, though. You're adding front-end development. It's almost the same. It's also as much fun. Don't get me wrong, but it's different. If you're doing front-end development on bigger projects, you kind of always have to keep refactoring. Otherwise, you're working towards a legacy project and therefore the tooling workflow is built to help you and keep refactoring. It's very refactor friendly. It's even helping you in many different ways. For example, okay, so this GIF I'm going to show you. It's video. It's even faster than the way I talk, so I'm going to pick it up one notch. If you have a component called testy, for example, and you have a nested component inside of it, testy variation, have a dist folder, we're going to duplicate testy.js. You're going to duplicate it, and you're going to see it appear in the first dist folder. Here we go. If you now drag this file into the nested component, it's going to be removed from the first dist folder, and it's going to create a new dist folder in there, and it's going to put the compiled variation of JavaScript in there. Right? Like, it's really cool. We have auto-maintained dist folder, so and it's even smart enough to know when to clear your cache in doing so. You can nest components, you can group components, you can rename components. Gulp is always going to be smart enough to know when to clear your cache. The only thing you have to get is you have to run Gulp. It's the only thing. It's pretty cool. You have loads more, but again, I had to summarize. You have a browser-syncing SAS globing, source mapping, Gulp setup that is capable of cross-component variables and mix-ins. It's also auto-cleaning up empty directories which can happen with Git sometimes, and the best feature of them all is that every feature is an option. You can literally disable every feature and it won't do anything, and I'm not sure why I'm enthusiastic about this. Now, again, no one left. This is going way better than all the previous times. So, when we have the first two layers, right, and my assumption is that you might like it because I see some smiles in the audience, that we're going to be able to create Drupal front-end components. They're going to be self-independent, and we're going to be able to make them really fast by default. Then we're going to need a platform on which we can collaborate together, because if I can drop my components from one project to another, I can also give them to a colleague of mine, for example. Let's assume I would have a job and we worked in the same agency, or we can also drag and drop them between companies, right? And that's the basis of an open-source community, and that's what I'm here to talk to you about. The open-source, we can do this within Drupal. So, why don't we set up a way that we can collaborate in an open-source manner? Now, the new platform to share, how does it work? It works very similar to how Drupal.org used to work before Drupal 8. You go to it and you download from it. So, if you go to Component.io, you're gonna have a big button where you can download the team structure and tools from there, and then you can browse the platform and you can download a set of components that would fit your project. Again, pretty cool. Everything is drag and drop, and it will just work. No, not this one, this one. The amount of advantages this platform gives? Well, a lot of them are very similar to how open-source is going to work, but in order to be able to take advantage of everyone's work, we're gonna have to make our components project agnostic. Let's say I'm contributing a component and let's say you, for example, is going to use that component. Well, my orange component is not going to work in your purple website, is it? Well, I will, but I will look hideous. So, therefore, we have to make or stuff that we contribute project agnostic. And making it project agnostic on the front end is a very interesting concept. For me, that means we're gonna strip away the color fonts and variables, because even if we don't strip away the variables in any project, we already have 15 different shades of gray. So, this would mean that, indeed, yes, we're gonna have a black and white component, but that's what you're gonna want. You're gonna want the sketchbook principle where you're gonna download a whole bunch of components. Everything is gonna be functional, responsive, and you only have to have the fonts with the cascade coming in. You're gonna define some colors within the components. You're gonna change some spacing and after you go, or you don't, and you just keep the default like you already have, depending on how much time you have for this project. Now, the platform is there to, for us, to be able to share information on components. What that means, well, if you upload the components, you're gonna get a detail page. For each component that you can find on the platform, it's gonna have a detail page. For example, this one is build upon Drupal core, status messages. The name is status messages. The building blocks is HTML and CSS. This is how it would look like if you would give it some color, for example, and a whole bunch of things, and you can download the components from there. So pretty straightforward. Now, how do we actually do this? How do we accommodate this way of working? Is if we want to collaborate on components, well, no. If we upload a zip file with your components, the platform is automatically going to give you a GitLab repository. It's pretty cool. It looks like this. Let's go. Every time each component has its own GitLab repository, which means you can inspect it, and all the tools GitLab is offering us, we're also going to be able to use. Go on. There we go. It's better. Like a Web IDE, for example, or maybe the issue queue, hopefully it's not gonna be this big for status messages. Now, this is where we start deviating from Drupal.org. You might think, oh, Metru's making a new Drupal.org. Oh, no. It's a bit more complex than that. Like I already said that people, as front-end developers, rather give up their jobs than give up their opinion, right? And I believe an opinion is a strength of a front-end developer. Not something you should try to generalize. If you look at Drupal.org, let's say the Views module, let's assume it's not inside Drupal Core already, then it's demotivated for me to fork the Views module, change one little thing and contribute it back as an entire new module. That would be ridiculous, right? Let me collaborate together. But in Component, that's different. Let's say, for example, I've built a project. Nah, I'm not gonna use my phone anymore. There is a lag. Okay. Let's say I built a project called Material Cookie Compliance. And that component is built on top of the EU Cookie Compliance module, right? It's a very popular module in Europe these days, completely voluntarily. We have a detailed page on this, but I've teamed it following Google Material Design. I'm not here to try to convince you that my opinion of Google Material Design as a design language is good because I know it's an opinion. And because I know it's an opinion, you can fork this and make a new variation of this. Maybe you want to make smooth cookies. Oh, my mouse is still here. Maybe you want to make smooth cookies. Why not? Go for it. I mean, you're gonna strip away the Google Material Design things from it. And we can collaborate on whatever opinion you would like most. And you can make as many opinions as you would like, which it will end up, and now this is still in development, all the rest is still there already. If you go to the project page of this EU Cookie Compliance module, then you could now decide which opinion you would like that module to look like. Right? It would be really cool. It also fixes a lot of things where Drupal backend developers are kind of stuck and not being able to update their front-end code. That's a different story. The platform also accommodates collections. For example, form item collections is a collection of components. Very straightforward. There's just a bunch of components that you can download in one go. And usually after my session I get this question like, oh Matthew, are you already completely building an webpack or are you completely switched over to post-CSS? How about React View, less anatomic design? Oh, Matthew, are you already, everything is already built on top of view, right? Whatever question you have, the answer is yes. Yes, indeed. But for now, it's stuck inside your head. And I would love to know what you come up with and how. Because it's community-based enhancements. So whatever you would like this thing to evolve into, I'm there to listen. And it kind of sums up now, and this is the end of my presentation, that I'm finally being a proud Drupal front-end developer again. If you think about when is the last time you updated your NPM packages? Successfully. What's the latest version of your Node.js that you're using? It's usually embarrassing. Like, I didn't know for a very long time until I made this girl set up. Because we're all working into our own silos of our companies. And we're trying to get this best set up for our own company. Yet everyone is doing the exact same thing. And we're all doing it on Drupal teaming. So why on earth are we not working together on this? Right? We all love Drupal for its open source collaboration, yet the collaboration seems to stop as soon as anyone mentions front-end. And that's what makes me very proud to put front-end developer. Or think about the last time you had to run DrushCR manually. Now, the platform offers lots more nesting, naming conventions, extending conventions for PHP. Documentations on the four PHP functions you could use as a front developer. And we also have version control of components. And now this is the third to last slide. I'm really proud of this because you know the layers, every time like there's a different color. Right? And now, really proud of this one. Okay. So I'm going to show you a GIF now. There's going to be a green background. Like, it's going to be a browser where I'm going to show a local development of a fresh install of Drupal 8. I'm going to go to the registration page. And it's going to look like shit. Because if you base it on top of Classy, there's just no teaming inside of it. And it's just basically, by default, looks like shit. And then from there, we're going to evolve to how we could use the platform to make that better. So this, for example, is a default registration page. This is, scroll down, the output of Drupal set message. If you inspect that to see where it's coming from, well, it's coming from status messages. So there's a very high chance that someone already made this component status messages. So if you go to the platform, white background, the platform, and you don't want this component, then, well, it would potentially work. Right? So you download the component, you download that tar, you unzip it, and you drag it on to your components. I should have made that a little bit bigger. Go on, please. I'm gonna try to, should I try to refresh this? Go on. This is the crown jewel. One left. No. Wait. And I'm going to hotspot it. Hotspot. Okay. So no one goes on this hotspot, right? I only have four gigabytes and I'm nearly broke. So where is it? Here we go. Data is temporary. Can all guess the password? It's poetic. Let's go. Yes. Here we go. So we download it to the status messages component, right? We drag it over. Very good at that. And we get a notification that Drupal is clearing our cache, which is pretty cool, right? So you wait until the Drupal has cleared its cache. You refresh the page and now have a look at this. This is the output of Drupal set message. It's black and white. I know, but it's functional. It's responsive. You could ship this if you're not against the emojis. Which is again an opinion. Now, if you go lower on this page and you view inspect the next thing on this page that doesn't look good, well, that menu of login, creating your account, register, we all already teamed that before, right? We already know how that every teamer has to do that. So it's called menu local tasks in Drupal. And would we have a component? Well, yes. Well, I know that this would happen because I made this video. All right, it's my presentation. So you go to the detail page of this component. You see it's responsive. You see it's functional, too. So you download it. You put it in, you unzip it. You open up your finder again. You drag it to your components. Yes, you have to manually drag it. But guess what? It's the only manual thing you have to do instead of teaming it completely by yourself. You get a new notification that it's rebuilding. You wait until it's rebuilt. You refresh and now have a look at this. I know what it's going to look like, but you don't. I know already. There we go. And you can ship this. It works and it looks good. And it's a certain opinion that you're going to download. And it's functional, too. So if you make it responsive and you click it open, it's functional because the JavaScript in the series is attached to that one component. It makes a lot of sense. Now, I'm going to skip through. I'm now going to show you how we can download the entire form items component. I'm 49 minutes in. So I'm going to go, number two is leaving. No. Fine. If you download an entire collection and you drag it onto your project, again, the same thing will happen. We use all three layers. You refresh. Go on. You refresh. And it's themed and it's working and you can ship this. And I find this amazing. Now, this is the last slide. I want to close down by saying my name is still I'm still a freelancer without a job and a group of frontend if anyone knows anyone. And I had the absolute pleasure and the absolute privilege of being one of the organizers of Frontend United. And I say this now because it's very relevant. Frontend United is capable in the last four years, in the last year of organizing 15 events in one year. I didn't do all of that. The only thing Frontend United was able of doing is combining the energy of all the volunteers involved. So Frontend United is the sum of everyone involved. Componi is the exact same thing. And currently, that sum of people involved is one. And I would love, well, now it's already a bit more but that's kind of how I prepared these slides. I would love for people to get involved. So if you think, if you're nodding like, yeah, some things made sense. If there's any bone in your body that thinks, I might get behind this. Don't just nod. Join me. Tell your colleagues if you like it. If you don't like it, make it better first. That's open source. And then tell your colleagues. Invite me for presentations. I do workshops. I even do birthday parties if you ask me. Nice enough. But get involved however you want to. And please do reach out or ask questions using slido.com with the hashtag frontend. The next frontend United is going to be in Minsk the 1st and 2nd of May. That's in Belarus and Europe. Well, Europe. Yeah, in Europe. But it's also going to be in 15 different locations around the globe. Possibly also in Hobart. Who knows. So do pay attention to that. Thank you very much.