 Yeah, my name is Oscar. I work for a London-based digital agency called Binary Vision. We're pretty small, but we've got to work on some big projects. And one of the things that I got to experience working on some of those projects is building style guides and driving our development process through the use of style guides. So today I'm going to talk about component and style guide driven development of WordPress themes for developers. Sorry about the spelling mistake in the thing. Right, so the first thing I want to do is just explain what components are in the context of this talk. So it's a very overloaded term. You've got web components and you've got it used in lots of different places like trendy new things like React. I'm just talking about styled elements in your templates. So the building blocks of your user interface, like blocks of markup that you use repeatedly across your website, ideally with their styles encapsulated using modular CSS naming schemes to make them easy to reuse. And a component-focused approach to design is an alternative to building lots of bespoke layouts. So instead of building bespoke layouts, we identify patterns in our designs and we encapsulate them in blocks of markup that we can reuse and compose into other more complex components. And the aim of that is to improve the development process for implementers to stop us from re-implementing the same patterns over again across the website and to give users a more consistent and predictable experience. So using the conference news page as an example, I've highlighted some possible components. So they could be simple styled elements like... You can see that the paragraphs, they're all sharing the same styles no matter where they're being rendered on the page. And then you've got sort of more complicated, composed components like the sidebar boxes in green which have got a consistent header and then variable content inside them underneath. That's what components are, really. Pretty simple. And style guides in this context are catalogs of components that you've built for your website. So it's basically documentation for the different things that you can use to build your themes and layouts. If you've worked with design agencies before, you might be thinking of something more along the lines of brand guidelines. So a document that tells you what colors to use, where to put your logo, and things like that. And these kind of things are good to include in your website style guide. But when we're building for the web, we can go a lot further than that. So a good example of the kind of style guide that I'm talking about is the gov.uk design system. So the sort of essential features of a style guide are you've got a big list of components on the left and then it gives you an example of what the component you're viewing looks like and it gives you the markup that you use to create that component in your designs. And just to go through some more examples, I was in Australia recently with my family and that's where I did a lot of work on this talk. And so while I was there, I decided to see if the Australian government had a similar thing to the gov.uk design system. And I think there's another good example that I'll talk through some of the good features of in a second after I've introduced more. And then one that you're probably very familiar with, but that doesn't call itself a style guide, is bootstrap documentation. But it fits the model of what we're talking about. So it's a list of the components on the left and then example of how they can be used in the middle column with the markup underneath that you can copy into your designs. But all of the style guides I've shown so far are the products of massive development teams and big organizations. They're not necessarily what we would build if we were creating a WordPress website. A good example of the kind of style guide that we might create is a Perch UI pattern library. Now, this was built using a tool called Fractool which came out of a Brighton-based design consultancy called ClearLeft. And it's a tool specifically designed for creating style guides. And so I've explained the core functionality there, list of components, examples of what they'll look like and the markup that you need to use them in your designs. I want to go back through the examples and quickly highlight some of the other features I think make for a good style guide. So on the Gov.uk design system, they've got an open in a new window button and that might seem like a silly thing, but it lets you open an isolated view of just how the component looks which is really, really great for setting up automated tests and things to catch regressions of your important components. I don't know if you've ever worked with companies where they try and beat you over the head with the reputation of damage stick, but setting up automated tests so you can be confident that when you make changes, something like your payment form or something like that isn't going to break in a way that disrupts users is really essential. And having something like this which gives you a clear, consistent example that you can test against is brilliant because if you're testing against a live site, the content might change, you'll get false positives, people might ignore flags saying, oh, there's something changed because they think that it's just another content change or something like that. And then another thing that the Gov.uk design system does is it doesn't just give the HTML that you can copy to create components. It also provides the components as templates so you can use the templates in your designs and rather than duplicating the markup which you will then have to update if the component markup ever changes, you just update the dependency and it will update the markup for you. And getting people to adopt using Star Guides can be quite difficult. So convenience functions like the little copy in the right there can be really essential to just getting that critical mass of usage and keeping people coming back to the tool. And on the Australian design system website, I think one of their focuses has been on creating a Star Guide that is easily navigable. Star Guides can get really big. Even on a small website, you end up with lots and lots of components and if it becomes impossible to find stuff, people will stop using it or they'll start re-implementing the same patterns that you've already got because they can't find them. And so they're really focused on having a clear and easy-to-use search and they've got all of the important metadata that you might want about that component like a history of its changes, how to install it individually and tanks to find related components prominently featured at the top of the page. And another thing I like about this is so when I say Star Guide, what I really mean is kind of documentation for your website and one of the great things about having a tool like Star Guide is that you can highlight the things that are important to you as part of your design process. So here, they've prominently highlighted or I've drawn a box around, but they've got rationale and accessibility displayed there and those are things that kind of maybe happen at the start of the design process or at the end of the design process but are kind of lost in between a lot of the time. But by having those featured there, so as people are developing, as people are checking on the progress, it's clear where there are gaps or where something is straying away from the intention. Just helps to shorten the cycle of catching errors quite a lot. And on the Bootstrap site, the way that they've tackled the problem of sort of very dense long pages and making it easy for people to navigate is they've got a table of contents in the top right. I don't want to have to scroll to the bottom of the page and then up again to try and work out what's on that page and if it's relevant to me, I can just scan the headings in the right and see instantly whether or not there's something there for me. And then another thing that they do really well is they show you all of the variations of that component in one place so you can scan them all at once. I mean, if you would split this up and this is one of the things you might have to make at different times across multiple pages, say one page for each of those variations, it'd be very hard for people to quickly work out which one was appropriate for them or what are the different options they could use. With the Perch UI pattern library, so one of the great things that they've done is a feature of Fractal but the example is inside an iframe. So if you look at the pink bar on the right, that allows you to change the width of the viewport. So you can check the responsiveness of your elements in the browser like that. And I know we've got browser developer tools but those aren't accessible to everyone. I mean, I know a lot of designers that they could do it but they just don't feel comfortable doing it and so they wouldn't do it. Whereas with that, a designer or someone who's a client or a business owner or something can come in here and they can test it themselves and see if it's meeting their expectations really easily. And then another thing that I think Fractal does really well is it promotes the idea of not just displaying your components but also displaying examples of the actual layouts that you're going to have. So layout variations, they show up when we're doing Photoshop designs but when you move to a production website, how do you know how many variations of layout there are across your website? You know, if you're working on a website that's got thousands of pages, you might have one or two people that know where those variations are but it can get hidden. And so I think perpetuating the like, stunning mockups that you do in development and keeping them as part of your development process and documented in your style guide is a really good way of just making sure that everyone is aware of an overview of what you're doing or what you're trying to do and the context of how the components are supposed to be used. So there are a lot of different things that you can include in your style guides and I think that they're great but they have a very high cost to introduce into your development process potentially and there are some foundational things that you might want to establish before you start using them. So you really need to consider carefully if you really need one. If the site is a one-off and it won't be developed any further then you might not recoup the overhead that you invest in getting it set up and you need to make sure that your clients understand the overhead that you're introducing because maybe all they want when they're agreeing to your use or development of a style guide is a page on their website which gives them some examples of the things that they can do in their editor field or something like that and you really don't want to miss-sell this otherwise as soon as you hit a stumbling point you'll just be totally demotivated and stop maintaining it and then that's a massive waste. But there are a lot of situations where over time even if the adoption is hard work and takes a lot of time and effort you can get a really good return on your investment. I think that style guides shine when you need to coordinate development between lots of people and roles or when you have over time different people working on the site. Documentation is an essential part of successful projects but often it is absent from the front-ends of our websites and if you weren't there when the thing was designed then you have to reverse engineer the interface to work out what you can do and absent from that is any context around how that was supposed to be used or any considerations that you might need to have about decisions that were made around that and the people that originally worked and it might not be available anymore and so having this documentation in the form of a style guide that is kept up to date because it's using the same CSS and JavaScript that your FEMA is using and it's an everyday part of your development process is really helpful. And I mentioned this before but style guides are also amazing for facilitating user testing. So if you've got people that are tasked with going and testing your website and making sure it works as you expect in different browsers and different devices and things like that then often the things that they have to test against are vague descriptions of how stuff should work or very out of date design mockups. When you take a Photoshop design and you transfer it into templates stuff changes and so it's not always a good idea to be testing it so otherwise you might be fielding a lot of questions that you just have to say oh that's deliberate or that was intended. So users, so testers can take the style guide as a reference and they can test the production site to make sure that everything is working how it should work or they can just test directly against the style guide because the style guide gives them the ability to get a quick overview of all of the different components on the website and how they should look and to see where there are gaps. So for example are there hover styles missing from certain things or accessibility issues like this element doesn't have any focus styles. So a lot of people that I talk to don't need to be sold on the benefits. They already know that they want to do it but where they stumble is working out how to do it. A lot of the tools for creating style guides are in different languages than people are used to. They're in Node.js primarily and if you come in from maybe a background in PHP or building WordPress themes and you're not used to things like automating the build of your static assets and things with task runners like Grunt and Gulp then it can just be very overwhelming because you have a lot of stuff to learn all at once. And there are also a lot of different options at the moment but I don't think that they are all equivalent. I've got experience using two tools for building style guides and I'm going to introduce you to those and just make some recommendations about where I would start normally in my development process. So the first one is KSS Node. A bit of an inscrutable name but KSS stands for Nile Style Sheets and it's basically just a format for documenting your CSS with structured comments. So if you've ever, you know, I don't know what the equivalent in PHP would be, PHP doc, I don't know. But basically, KSS Node uses this documentation format and some conventions to pass the information it needs for the style guide out of the comments included in your CSS. And it's quite an actively maintained project. It gets quite a lot of use in the Drupal world and it supports twig templates which means that if you want to reuse the templates between your style guide and WordPress then there is a means for you to do that which can be quite important if you're working on a big project. So here is an example of the default style guide theme for KSS Node and it's just displaying a button component. So it's listing the different variations. It's also listing the hover styles at the bottom and the markup for that component and how you use it. And the information that you need to be able to create that is included in the comment at the top of the page here. It's a bit difficult to see maybe from the back but basically it just says the title of the component, a description of the component, a reference to the markup example for the component and then it lists the variations and the place in the style guide document where this component should be located. It's very simple and clear and I think that even if you didn't know what the style guide was and you're editing this CSS you would understand that this is something that should be kept up to date with any style changes that you make which is a very helpful thing if you've got a big team and you're struggling to get people to adopt this way of working. A problem with this approach though is that because it's passing CSS comments and it's relying on certain conventions it's quite difficult to do new things. If you're working outside the conventions that KSS Node sets out then it's challenged to update things. The next tool that I'm going to talk about is Fractal which does things a little bit differently and is maybe a little bit more flexible at the cost of being or requiring a little bit more work to maintain. So like I said, Fractal is a project from a design agency and the default theme kind of reflects this. I think it looks a lot prettier out of the box so if that's a concern for you then it's definitely a front runner. It's very similar. It has a list of components on the left an example of how the component looks and then the markup at the bottom but the way that it stores its configuration for components is just in separate files. I think JavaScript, JSON or YAML files are next to the components markup. And I think it's a really good tool. I was hesitant to include it because up until recently it was not very actively developed. It had kind of died so Clear Left is a design company and I think that the people that had originally worked on building this tool had kind of had other things come up and no one had stepped up to take over the development of it. But that was recently highlighted online by some people after a few blog posts or articles were published and now there's been a surge of support and people coming forward to say that they'll help maintain it and develop it into the future. So now it's actually probably looking quite strong as a choice for creating Star Guides. If I was going to recommend one, I mean when I was getting started I started with KSS Node but I very quickly came up against the limits of that tool and so I would probably recommend if you feel confident starting with Fractal. It might be a bit more confusing but the basic use case is pretty easy to work with so I would stay sort of laser focused on that when you're getting started and not get too stuck looking at the documentation and thinking, ah, paralyzed. So once you've chosen the tool that you're going to use, you need to answer some questions. So the first question I think is where will you create it? And it might seem like a silly, you know, does it matter? But if your first thought is I'm going to spin up another repository, I'm going to stick all the configuration in there. It's a separate thing to my theme. I think that's a mistake. The best place to put it is to just create a subfolder of your theme and shovel the configuration in there. So there's a high coupling between the Star Guide and your theme and you want them both to be in sync as much as possible because if you've got documentation published that's out of date, then people are not going to use it and if they stop using it, then it's just going to compound and eventually you've invested all this time for nothing. So removing as many roadblocks as you can, keeping them located close together is important, I think. And then the next question, which is maybe slightly bigger and a bit more ambiguous is how will you manage your component markup? So there are kind of two options here. The first and default one is that markup gets duplicated across your theme and your Star Guide. So when you go to your Star Guide and you say, oh, there's a component I want to use, you just select the markup and you paste it into your theme and then maybe you end up with, you know, lots of different instances of that across your theme which is difficult to maintain because even normally having your markup spread across would be difficult to maintain, but when you've got the Star Guide as well, you might have developers who are going in and they're editing the theme directly, making changes and forgetting, maybe deliberately forgetting that they also need to update the Star Guide markup as well. And if you have a very big site, then this can just become more and more of a problem. So one way to get around that is that you define your markup once in templates, just like with the gov.uk design systems website and then your theme and your Star Guide both use these. And I think one of the really good things about this approach as well is that if you have a large team of people building a website, multiple developers, then at the start of the development process, your front-end developers can get started building static HTML. They can build your components for you, mock it up and show it to the client before anyone is engaged in doing WordPress stuff. But then when someone comes to integrate those designs into WordPress, the HTML markup and the CSS and JavaScript is already there for them to use. So you're not doing the usual development process thing of saying, well, here's all this work I did. I'll just drop it in the bin and re-implement it. You're taking the assets from your earlier steps and you're using them in the later steps to save yourself time. The problem is that this is just quite a complicated thing to do. You need to think about the API that you're using for rendering your templates, rendering your components. And like I said, because the tool that you're using to build your Star Guide is likely in a different language to the tool that you're using to build your themes, PHP and Node.js. You need to use and create your components, templates in such a way that they will survive that translation, which can be done. It just requires some more thought and is more complexity. And then the next thing is where should you host your Star Guide? So it is super important that deploying your Star Guide just happens automatically, that there is no manual step that you have to do. It just happens as part of your development process. You might be tempted because the Star Guides that these tools create are just static websites. It's static HTML and CSS and JavaScript. So you could just drop them in your web route of your site under slash Star Guide. But then there's a dependency on you having your WordPress hosting set up from the start of development and things like that. And a lot of managed WordPress hosting environments, they don't allow you to run arbitrary build steps. You know, they might automatically deploy from Git, but there isn't a way for you to hook into that and say, when you do a checkout, build the Star Guide and put it here. So the recommendation from me is that you use a service to host your static site specifically. The one that I've got experience with is Netlify. And they're cheap. They're reliable. And what they have is ways to hook into the lifecycle events of your repositories on Git. So watch for changes being pushed. And when a change is being pushed to trigger builds of static websites, which is perfect for Star Guides, and it means that hosting a Star Guide initially for a front-end developer is as simple as changing into that directory and then running Netlify deploy. And then they've got something that they can share with other people, which is great. So I've talked about what components of Star Guides are, and I've talked about what my recommendations are for the tools that you might want to use when getting started with this. But the title of the talk is component in the Star Guide-driven development. And so I just wanted to go through a kind of, you know, tacky flowchart that sort of explains how I think using Star Guides changes your development process and sort of decouples some of the steps that sometimes you end up with things being blocked. So each of the columns here is stuff that can happen in parallel. So the normal development process that I've experienced is you define your requirements, you create sort of low-fidelity mock-ups so you sketch out what something's supposed to look like just to make sure in the cheapest possible way that you are building the right thing. Then you might create more high-fidelity designs, go into Photoshop or Sketch, and someone will take the brand guidelines and they'll create nice, beautiful designs for you. And then from there, normally, because of time constraints, things like that, you jump straight into putting stuff into WordPress templates, whereas I think that there is an important place for creating static HTML prototypes. I think it's much faster to build static HTML prototypes of designs to test them and to proof them. And I think that, as I mentioned with the purchase example, if you keep those static HTML layouts that you create and persist them in your documentation, then they can be a really valuable resource for future people who want to just quickly see an overview of what have we built, what is available to build on the website. And so with StarGuy-driven development, at the same time you're doing those initial free steps, your front-end developer can be bootstrapping the StarGuy, they can bootstrap the component template system if you're going to share components, and they can start the CSS and build setup if you're using sassins, you know, other JavaScript build things. And then once you've got the designs and that initial build system set up, you can create the HTML prototypes. And while all of that's happening, sort of in parallel, and it could sort of be in parallel to everything, to be honest, the WordPress environments are being set up and the final deployment pipeline for WordPress changes is being set up, which maybe needs a little bit more in terms of like... We've worked with a lot of clients who want to host their own websites. They have an internal IT department and there is a certain overhead in terms of getting environments provisioned that we don't really want to be blocked by. And so being able to detach ourselves from needing those environments, to be able to demo to clients and to work collaboratively on the designs is really important to us. And so, yeah, working in this way is for us been really good. And so we create our static HTML prototypes and once we've got those and we've got our WordPress thing set up, we create the WordPress content model, same thing that everyone does, you know, define our custom fields, that kind of stuff and our different content types. And then we create the WordPress templates. And the key thing is, when we get to create the WordPress templates, is that if you weren't using a style guide or you weren't using templates that you were going to share between your static HTML prototypes and the WordPress templates, then you would just have to copy and paste stuff from those that HTML you created originally and then modify it into the WordPress templates which is a bit of a waste. Whereas if you are sharing the templates, then when you're creating the WordPress templates, you can just jump straight in to output them without having to think about stuff and knowing that when you make changes in the future, everything will be kept in sync. And obviously, this isn't something that would happen, a process that would happen once in the development. This is a process that might be applied to each feature that you build or something like that, except as you build more features, you don't have to do the stuff that you're doing in parallel there to get stuff started. Thank you very much for listening. I hope that's been a helpful talk. And thank you for patiently sitting through what can be quite complex and new stuff. So if you have any questions, let me know now or grab me afterwards. And I'll put the slides up online afterwards. There are a lot of notes in my presenter notes that if you're interested in this, you can look through and pull out references and stuff. Okay, thank you, Oscar. So hands up, any questions? Gentleman just there. Hi, thanks. It was superbly useful. Do you have a favorite automated visual regression testing tool that you use? The one that we use is a service that's called Ghost Inspector, just because I don't want to have to set up the tests. I don't want to use Selenium or something as a test runner or a programming library that I have to maintain. I want something that I can give to a tester and that they can define the tests and create the tests themselves and take ownership of them. And that is a paid service, but it does that. That was a great talk. And how do patterns fit in with what you've been talking about with components today? I mean, pans are basically just design pans. So when you do your designs, if you have a... Thinking in terms of design pans is like, I'm going to have a section navigation on the left that's going to conform to certain conventions. I'm going to have buttons all kind of styled similarly. So rather than having 10 different kinds of button on my website, I'm just going to have one button style so that users have a consistent experience. And yeah, pans is just, you know, looking for in your designs where stuff is similar and where they should really look the same and then turning those into components. Hey, talking about how we all love to shortcut process, you mentioned that you can have your build tool build the style guide in situ or in sync with the production site. Can you talk a little bit about how you do that with Fractal, say, like a basic component? That'd be great. Yeah, I mean, so the way that we work when we deploy our websites, I mean, we use managed WordPress hosting. So I haven't done this development process on a lot of WordPress sites, but we normally use Jenkins as our deployment runner, basically, so it gives you a web interface where you can trigger stuff. And those things that you might be triggering might be I want to deploy the theme to production. And when you trigger that job, it's just running some scripts. You know, it might be pulling in the source code from a Git repository and then copying it into a folder on a server. And so what I mean about linking the processes together is basically at the same point in time that you copied the things to be deployed, you might also run the generation. It's basically the way that you trigger a build of the style guides. It's just a command line invocation of the library and then it outputs the static HTML. So as a part of that process, you would just also trigger the build and then copy those files to somewhere you want to keep them. Yeah, cool. Anymore? So I suppose I've got a question. So how long did it take you to get comfortable with all the tools? And maybe were there any hurdles that you wanted to get over? Yeah, I think wrapping my head around what the tools are trying to do was quite hard at the start. But basically it is just you've got a list of all of your components and it's taking some templates and it's just transforming that into a static website. But for some reason at the start, when I was first looking at it, I had this really strong idea in my head that there was magic involved or it was doing something that was really unintuitive. And I think that some of the documentation for these tools because a lot of the tools aren't built by large teams, they're built by individuals and so they can be a bit poorly maintained or have their idiosyncrasies and so they can be a bit overwhelming to look at because people have explained things in a way that they understand them but it's not necessarily intuitive to others. So when you actually deploy, you have some inline comments there with your CSS. Do you deploy the comments as well? I mean, you can, yeah. I mean, we normally use a build step for our CSS which just kind of... Or we normally work in SAS and so part of our build process is compiling our CSS, compressing it. And so that kind of strips out comments and things like that. But you don't have to, I don't think there's... It might be a bit confusing to people who are looking at it but there's no real reason that you have to or you don't have to. Yeah, I was kind of more wondering, you know, like on one of those big chunky sort of sites, you know, all the inline comments could end up doubling the size of it. Yeah, it does add a massive overhead, especially one of the things I found with CSS and it was over time as we were putting more and more information into the comments, you know, you had to kind of scroll a considerable amount before you actually got to the CSS that you wanted to edit, which was not ideal, which is part of why I'd probably recommend Fractal because it keeps stuff separate. Any more questions from anyone? Oh, we've got one right here. Jost. Not Jost himself. Maybe a bit open-ended question, but with Gutenberg versus seeing the introduction of blocks. And I was wondering, do you still see a use case for... Or do you see that impacting the use case for style guides in any way? I think it probably makes it more important because you've now got another way where you can have components to things to find. And so, again, it's another place that you've got to maintain stuff. And I mean, I don't know what the documentation for Gutenberg components is like at the moment. I guess you can see an overview of all the Gutenberg components that are available, but as those grow, you still want to have a way of kind of making sure that everyone is building stuff consistently. So if people have got hundreds of Gutenberg components, but you don't really want them to go and use all of those components, them to use a limited amount of them, then one of the things you can have in your style guide is just say, how you use this pattern. You can just use this Gutenberg component that we've customized so that it outputs the HTML in the right way so that it displays this component or something like that. Anymore? Oh, oh, you forgot mine. Hunter, you mentioned overhead halfway in your talk. At the end, I would also say there's efficiency. Yeah. What kind of... Are you still talking overhead in the end of the run? I mean, I think that the more you do this, the more comfortable you get with it, the less overhead there is and the more sense it makes to use it even on small projects and things like that. It's just like, for me, one of the things I need to evaluate is other developers are going to have to work in this way. And so it needs to be really simple and easy to use. And I can see that there are a lot of projects where, you know, getting people to learn how to use all these different things. One of the things that working this way does is it kind of... It requires people to use a specific development workflow locally to a certain extent. And in my experience, people all have their own customized ways of doing things locally. And so there is a resistance to changing things that you have to think about. And you don't want to... You don't want to get halfway and then discard it because it's... Yeah. What kind of percentage of a project would you say? Are we talking 5% overhead? If you just talk about a project you did? I think it depends. So, for example, if you've never worked with automated build steps before, like your CSS and your JavaScript just come in through WordPress on queue head and, you know, then you're going to struggle because there's going to be a massive learning curve for you in terms of getting up to speed on that kind of stuff. So it depends on the team and it depends on, yeah, what kind of project you're building. So I think that one of the things about Star Guides for me is that you can get started with them early before you've got a coherent design for everything and you can sort of quickly demo stuff to clients and get them to help you build things. So there are definitely some projects where just working out what it is you're supposed to build is quite a challenge and unless people can see something in front of them then they just kind of go, I don't know or, you know, they don't communicate. And so having a tool like this where you can put something functional in front of them and they can like Twitter the knobs and things like that very quickly is very useful and then you don't have the overhead of WordPress and stuff like that which can get in the way early on. Thanks. Another question. That's all right. I'm going. I'm going. I need the exercise. Hi. Thanks for the great talk. I suppose one of the more complex parts of Star Guides and building outsides is the duplicated markup and if you really want to maintain the consistency between a style guide and the site itself you really want to have that one source of truth for the markup and with SAS and JavaScript we have dependency management. But with the markup I suppose we can start using things like partials which are then written with handlebars. Is that kind of the approach that you've gone with and then be imported into the style guide and to the site? I mean, yeah, handlebars or mustache or twig. Like I said, in terms of where you put your style guide so for me the idea is that your component markup templates just live in a folder in your theme called components and your style guide configuration lives in a folder called style guide and then you've got your WordPress templates there as well. And so in your theme all you're doing is if you say using twig or mustache or something saying pulling in the library somehow however you want and then pointing it to that folder and getting your template loader and then using that maybe for a function or something as an API. And then the actual style guide tools themselves work with those template languages already internally. Fantastic, thank you. What I took away from that is you usually mustache to work with. Any more questions? No, all good. Round of applause please. Thank you very much.