 I'm gonna start. Yeah. Okay. I think it's time. Does anyone want a team time? There's some in the front. So if you come sit in the front, you will get a team time from Sally. So I do recommend coming in the front. At least one person. Okay. So I'm going to be presenting today about the next steps on modernizing Drupal team system. I have some ideas and thoughts. These are just proposals at this point. So any feedback is very much appreciated. And yeah, I hope you are excited about to see what is going to happen next. So my name is Lauria Skola. I'm a senior software engineer currently based in Bangkok, working for Acrea in the Drupal Acceleration team. And I'm also a front-end framework manager and a team system maintainer. So as we all know, Drupal has shipped with some great improvements to the front-end development. Some of these changes are where features such as Twick, library system, stable team, which provides back-first compatibility so that your team's don't break in the minor releases. A classy team, which is based on stable for sensible defaults in markup. Basically, as the name suggests, it provides classes. And a lot more. So a few years ago, my dad's company needed a new website because their old website was launched probably like seven years ago at that point. And it looked pretty dated. Basically, their website had two iterations in the last 18 years. And there's no reason to believe that this would accelerate because the website is just not key to their business. Let me turn off my notifications. Yeah. So I was building a website to my dad. And now the clicker doesn't work. So here's a few screenshots. How this used to look like. I used a wayback machine to take some screenshots. So the screenshots on the left is from 2001. This is how it looked like on the first iteration. And the one on the right looks like how it looked like in 2011. This was probably built in more like 2009, 2010, but the most recent screenshot with this one from 2011, there was like a six-year break for some reason for them archiving this website. So this was the oldest version of the second iteration that I could find. And it was actually built by me. But yeah, as you can see, it looks pretty dated. So I wanted to help him build this website, given that I have some knowledge about building websites. So I took Triple 8 and built a site using all of the new Triple 8 capabilities. Since the site was a small brochure type website, teaming was actually one of the most time-consuming tasks on that project. So I built a custom team on top of Classy. A lot of the markups were now in template, so it was possible to create the markup we needed. And it was quite easy, at least till a certain point. I also built a small component system by using trick includes to reuse some of the template files. Everything went well and the project is now finished. However, what I realized was that Triple 9 is planned to be released the next summer. And I had to make some plans on how are we going to continue running the site on Triple 9. Luckily, we have a lot of tooling that allows you to check what needs to be changed before the next major release. However, one of the things that I realized we had planned to be doing at the next major release was to rip out stable and replace with a new version of stable. And it could be a bit hard for us to actually test if there's anything that broke on the site. Because if the changes could be pretty subtle or they could be specific to certain browsers, you don't really know what kind of changes could it cause, because it's just like some minor markup changes that are coming as a result. But luckily, some of these plans were adjusted later on on the process. That was just the original plan that we had. Triple 8 is using this continuous upgrade pad. And we had to kind of do a little bit of work trying to adjust our team system to work with this. This is actually pretty good because this gives developers time to adjust their code before the old behavior gets completely removed. But it's pretty interesting in the front end, because basically any kind of change, as I said, could consist of BC break. How can we actually make changes to our markup and this continuous upgrade pad? So I have a small exercise here where we could try to figure out together of how could we break this markup. So I have on the top, I have a template and CSS that is in class. So I'm setting a very basic span with the class and some styles to that. However, that has been overridden by the child team. They just changed the span to diff for some reason. And that's all. Does anyone have any ideas how we could change the CSS so that it would break in this combination? Basically, anything that would just cause the render in a way we didn't expect when we made the change. So it works with the set of markup and the CSS that we have in class, but not with the one that we have in the active team. So I have some boxes if anyone wants to give a try. Okay. Yes, change the CSS to break it. So it works with class, but it doesn't work with the... You can talk to the box. It's a mic. Can we get the box turned on? Okay. So you can put span.elements and then when you pass to the diff. Yes. That would definitely break the CSS. Awesome. Does anyone have any other ideas how we could break this? Okay. Content has a horrible giant render array hidden in it and we don't actually know what's in there. Yeah. That's a separate problem. It's a thing as well. Okay. I'm going to give an example. What if we change the background color to yellow? It's a little bit more subtle because of the span. It's actually display in line by default. So what we want to do is we want to use kind of a highlight for this specific word here, but since this team changed it into a diff, which makes it a display block, which means that it behaves in a very different way. And the background is not a highlight anymore. It's a background of a block type of a diff. So yeah. It starts to get more subtle. It's obviously not as broken, but it behaves in a very different way as we might have expected with the markup that we have in class. Let's take just another example. Instead of overriding the template, what is happening is that the sub theme is now extending the CSS with some new CSS. So we have the color hot pink, which we set in class and then we set a background color yellow in that sub theme. Does anyone have any ideas how we could change the template or the CSS to break this? No one has any thoughts? No one wants to give a try? Change the element that was in class from a span to something else? Yeah, that would be a breaking change. Definitely. Yes. What else? Again, things could be more subtle. So what if we changed the color to yellow? It would work with the white background, right? But we didn't know what happened in the sub teams. They changed the background to yellow. So now there's a conflict. Maybe it's not always the exact same color. Maybe it could be just something between and it doesn't work well anymore. Maybe they changed the background into gray and it didn't work well with the yellow. What if we started just going a little bit more crazier and we started refactoring our CSS classes? That would obviously break the output as well. So yeah, as you can see, predicting the outcome of front end change is really hard. The root cause for this problem is the fact that we have this kind of strange shared ownership of markup and CSS. So we have different extensions that can have a partial ownership of rendering some output on the page. So basically this problem has caused us to make very little progress because we want to avoid making changes as much as possible. This is obviously good for stability, but it's not very good for the progress because it can't really make that many improvements. So let's see what we decided to do with stable in the continuous upgrade pad. Drupal 9 will essentially ship with both Drupal 8 stable and Drupal 9 stable. Drupal 8 stable will be likely deprecated in Drupal 9 and removed in Drupal 10. We are still figuring out the specific mechanics, how this will all work, but we assume that Drupal 8 stable will continue to exist in Contrip. There will be some way to run the Drupal 8 stable even after it has been removed and deprecated in Drupal Core. I don't know exactly what are the mechanics, but there has to be a way to be able to do that in the future. We've also changed the base team property to be required configuration in Drupal 9 because we have multiple versions of stable team in Drupal 9, so we can assume stable as the default value anymore. So how about classy? This is basically just how this is solved in the scope of stable. Stable can do innovation in modules and ship new versions in every major release, which kind of works because it doesn't really have that many opinions. So most of the sites are using classy, just like the site that I built for my dad. And classy depends on stable. How are we going to continue supporting classy in Drupal 9? So prior to Drupal 9, all markup changes were done in between major releases. But from Drupal 8 onwards, we are providing this continuous upgrade path, which means that all backwards compatibility break changes must be done in a way where we deprecate the old template. We have to move it to the next major version, which means that there's a warning in between. But it can be a bit overkill for us to deprecate the old template just because we wanted to change the markup in one small part of that template. We would end up with a lot of templates. Also, classy will have to continue extending Drupal 8 stable for backwards compatibility. We don't know if classy is compatible with Drupal 9 stable. And we don't really have specific mechanics to figure out if they are compatible. We don't know what kind of things could break. So classy doesn't really have a design. So it's even harder for us to judge if it's broken or not. It's very much on the meta level if it's broken or not. So one of the ideas to combat this is to ship those classes, the classy that ship as a base team right now, using a different mechanic. And one of the ideas was to use a starter kit. So instead of providing a base team, we would provide a command that creates you a new team with a certain starting point. Essentially, the markup render on the site would remain the same. But it would be just about how it is structured in our teams. The good thing about this is that the starter kit could be changed between minor releases. Since it's just a starting point, you're not really relying on a future changes that could happen for that team. The pros of this approach would be that it's going to be way easier for core developers to maintain this because they can make changes pretty much freely. Because we don't really have to care about the consequences of it changing someone's production site. It would also provide some positive change for teamers because it would essentially move most templates in CSS into a single team rather than having to find them from different projects on different folders. This would be much easier for someone who is new and doesn't necessarily understand the team system that well. They wouldn't have to figure out which of the different templates that we have is being loaded because they could just take a look at the one project and everything would be inside there. However, one of the biggest cons of this approach is the potential maintenance burden to site owners because it essentially means that we move the maintenance burden of maintaining those templates to site owners or team maintainers because they would have to have a copy of every template in CSS file. The positive though is that we look into how many security releases there was in the Drupal 8 release cycle that changed templates and we couldn't find any. So that's at least encouraging, which means that at least there wouldn't have been security issues that could have affected those templates that someone was running in their teams. This also only solves the problem in the scope of core, which is kind of unfortunate because it's actually running into the same problem. So let's take a look at the different kind of variations of overrides. This is kind of already what I was demonstrating earlier. So one of the variations is that the template is overridden without overriding the respective CSS files and this is actually risky because of the CSS files could be changed in future and it might not be compatible with your templates. Also, the CSS files could be overridden or extended without actually overriding the templates that are related and this is also risky because of who knows how the templates are going to be changed in the future, your CSS might not be compatible with that. But if you actually overriding, if you took ownership of both templates and CSS files, you wouldn't have any risk because none of the changes that are happening in core would intrigle down into your personal team and you would have to wall ownership of that part. So this made me wondering, could we actually prevent partial overrides? What if we bundle CSS and templates together? So one of the ideas which is kind of competing to the starter kit but not necessarily there's some overlap between them, we could actually do both of them. They are not necessarily overlapping in that sense. But if you just did this change, it could be enough for us. There's still reasons to do the starter kit idea even if you did this. But basically if you would load CSS and non-functional JavaScript in templates, it would mean that once you override a template, you would have to take ownership of the CSS and JavaScript that is related to that template when you override it. This would come with the benefit that you don't necessarily have to take ownership of all of the templates and all of the markup that Drupal ships with. But you would take ownership of all of the templates and CSS that you want to customize in your team, which is great. This also solves the markup back first compatibility problems for contract, which the starter kit idea doesn't really do. So this is going into the weeds just to give an idea how this could work. I wanted to show you trick front matter, which is a syntax that is used by Jekyll. Drupal Core is actually already using this in an experimental module, help you to use this for loading related CSS and JavaScript files. And as you can probably guess, if you override this template, it would also override all of the configuration and you would have to re-specify that when it would be pointing to your own team. And if you don't copy the styles of CSS, it would be an empty file, it would be 404. So you have to also copy the CSS file and then you have the ownership of everything that is related to this template. This could even potentially help us get as rid of stable in future, which could even further simplify our team system architecture. So the conclusions that we can make as a result of this is that Drupal 9 will ship with two versions of stable team. We don't know yet if the Drupal 8 stable team will be deprecated or not, but it will be deprecated at some point in the future. So Drupal 9 will continue the ship with Classy and it will continue to exist in future. So if you're using Classy, you don't have to panic right now. It's going to be somewhere, so you can continue to run your teams that you've built. And I think we should continue wedding the idea of converting Classy into your starter kit, as well as bundling the CSS and markup. Because these could potentially come with radical improvements to the cost of maintenance. So we can do some questions. We have a box here. And if you want, you can have a TimTum after you've asked the question. So there's a hand over there. I'm going to try to troll this one, but it's pretty far. Oh, no, I actually don't really see. Hey, I don't see that well because I'm blinded by the lights. I'm making some excuses, but OK. Thanks, Larry. That's very interesting. Is there any consideration for the last item you're showing where if we go with this approach and you copy a template file, you must copy the CSS file to go along with it and the JavaScript file. But perhaps you're using, say, a pattern lab or storybook or something. And now you've got your CSS in one place and a CSS file that you don't need besides your template file. If you understand me. So I see that you're asking it from a point of your component library. And was there any consideration given to that? Yes. So I think this would work well with component libraries because essentially it would allow them to include the loading of the CSS and JavaScript inside the component itself because it would be in the template and the template would be containing the contextual information about that component. And in future, if the component library needs other type of contextual information, it could be provided using the front-matter syntax. It should be extensible. But it hasn't been a main driver to this, to be honest. But I think it could aid the effort of making Drupal more component friendly. Larry, great talk. Is there a reason why, for example, front matter was being used and not something like Webpack, which can do very similar things? It's because it's not in the template. It's in a different file or? So the front matter for this specific purpose is it's not something that has been decided. It was just an example and it happens to exist in Drupal core and it works very well for the example of help topics. And for that reason, because it's being used by help topics, it's something that would be very easy for us to use as well. But we are open to suggestions of using any other means of providing this contextual information. Yeah, Tim Thames? Mark, could you pass the box? So the front matter stuff looks a lot like the dependent libraries syntax. But what I see in projects is most often and not everything is compiled to one CSS file and there's no declaration of dependencies in between the components because of the building process of the CSS files. So given that it's a pretty big use case in actual projects, isn't it too much of a hurdle to get people to change how they build stuff? Like will this see the value in that? I'm not sure I understood the question. Could you repeat that maybe? Yeah, so doing that is the proper way of well it's one good way of doing it to be explicit about what your template used. But what we see is that nobody does it for CSS files. Yeah. So why are people going to do it now? Oh, I see. Well, it would be mainly because of then you would explicitly have to, we would always have to explicitly override the CSS that belongs to that markup and then you wouldn't have this shared ownership between different extensions. And we were actually looking into the specific mechanics of looking for this information. It could be using the library system behind the scenes so they would become libraries internally and basically the libraries API could be used on top of them. We could use the template name for generating the library name for that. And it would be similar to what we have now but it's a lot of people just use the global library for all of their CSS files and it's different from that. And it would definitely force people to change in that regard. And yeah, it's something we probably have to take into account. It's at least something that could slow down people from implementing this. Do we have any other questions? I think we are pretty much out of time anyway. So if you don't have any questions, feel free to reach out to me later. I'm happy to talk about this privately. Thank you.