 Welcome. Good morning. Everybody had their coffee, I hope. So my name is John Albin Wilkins. I have been doing web development since before there was a back-end. It was just front-end. It was HTML stuff back in 1993 when I got started. The Paleolithic era of web development. I want to start out by thanking the Drupal Association and ImageX. I live in Taiwan and I wouldn't be here today if I didn't get sponsorships from both of these great organizations. Drupal Association flew me over here. ImageX has put me up. And I've been doing some work for ImageX, actually started my first Drupal 8 project finally just like a month ago and started porting Zen to Drupal 8 thanks to ImageX. So thank you very much. Today we're going to talk about six easy pieces for the new front-end development. I assume everybody read this session description. I always like to try to push myself when I write session descriptions because it's months in advance. I didn't quite get all six easy pieces finished. So this is more like four easy pieces, two actually quite hard pieces that I didn't finish. And one crazy new idea about Drupal and Drupal is for the new front-end development. So I guess that's good news and bad news. Besides that, I didn't start to slice until this morning at like 3 o'clock in the morning. I got a little distracted. I released a new version of KSS Node, a new version of Zen 7.x 6.0 is also out now. And that means that we're actually pretty much going to be doing mostly live demos today. So that's actually the good part. So let's jump straight into this. Where are we going? Front-end development has been like really crazy, like all the different things that can happen. And I want to thank the Drupal Association again. This is actually the stock photo that came with the slide deck. But it's a perfect metaphor for my opening slide here. It sort of goes off to the edge of the deck or the edge of the dock there and where we headed. There's so many different things, right? You have NPM, you have Gulp, you have Grunt, you have regression testing, you have performance budgets, all of these different things. It's really hard to figure out where you're going. And that's what I wanted to talk about today, right? Give you strategies for figuring that out. And also give you some sort of hints for maybe what the next steps that you want to take as you learn about this sort of brave new frontier. What's the path that you want to take so you don't run into dragons and crazy mermaids that look like upside-down fish? I don't know what that is. So I think everybody here, you've been doing front-end development. Like is anybody completely new to front-end development in here? Yeah, yeah. So like we've been new front-end development for a while, right? And if you haven't started doing some of the new stuff, I mean we all have been in the old selector hell land, which is where I certainly have been for a very long time. And we still learned a lot of stuff while we were there actually, right? So I just wanted to like go through that super quick and remind that we have learned actually quite a bit and we're not starting from scratch. Those lessons that we learned there are super, super important, right? So I want to talk about the five pillars of front-end development. These are sort of like the five most important things that I think really inform us of how we build our front-ends today, right? And they start off with three that we've learned some way back in the beginning. So you have lots of enhancements where you're providing an experience to every single person, right? And if a browser or a particular user has additional capabilities, you extend and give those extra capabilities to those extra things instead of like providing broken versions of it to everybody else. Only the people who are able to see those extra bits or capable of doing those extra things get those things, right? So like mobile first responsive design is a perfect example of progressive enhancement, right? You only have the one column display that goes to mobile devices and multi-column spread across the page for larger devices, right? And these are priority order, really. But progressive enhancement also implies accessibility, right? This is really critical. Accessibility is not talking about trying to remove barriers, right? You should be providing access to everybody. It's all about the access that you provide to people. And those progressive enhancement things, those default ways, should be accessible, right? The extra things that you add that you give to additional things should not be barriers. You need to make sure that the extra things you provide are not barriers and that they are also fully accessible, right? And then front end performance, right? We need the things to be fast as possible because you start downloading, you know, 100k images over and over again. You're just really slow and people don't use the site, right? These are the most critical things in front end development. And I want to add two more on to the end here. Reusable components, right? I started talking about this a few dribble cons ago. And being able to create a design and have that be completely reusable in various places on your site is the sort of first thing that you should be doing when you're learning the new stuff in front end development, right? And it's so important that I wanted to put it on my five pillars here. And then finally, automation. Now this one's going to get, like, more riled up because he's not a big fan of automations and driving him crazy recently. But I think that it's super critical because one through four there, that's a lot of stuff, right? We're responsible for a lot of things right now. And the only way we can do them correctly and not break stuff all the time is to start doing automation, right? So you have an automated task that, like, does all the stuff for you so that it's done correctly every single time. It's really critical if you have, like, a CSS bug on production. Like, ah, oh my God. Right? Running an automation script that builds all this CSS, does aggregation of JS, does all that stuff for you correctly when your brain is freaking out because of the bug on your homepage, that's why you need automation. So five pillars in front end development. This is something that I've been thinking about this spring and I just wanted to put it out there to remind us this is what we're talking about, right? So the first three things are things we've been doing traditionally for years and years and years, decades even. And then the second two are the new stuff. So how do you go about learning all these things? How do you go about deciding what's the next thing? Honestly, I think it's sort of important that you find your own path, right? Don't have somebody dictate to you what's the first, second, third, fifth thing that you have to do next, right? Finding your own path is critical. I love this picture, by the way. This is awesome. Like waves crashing everywhere, the storms going on. She's like, yeah, I got this. Find your own path, okay? And while you're learning new things, what are some strategies for going about and collecting those new skills? First off, steal, right? Go find somebody else who's done the thing that you're interested in and take from them and then iterate over it because it might not be exactly the way you want to do it. So feel free to, you know, change it slightly, try it out that way, change it again. Going over this is fine. And then in testing. Testing is going to be something that's going to become more and more critical just across the board, right? So make sure you test it. Make sure, you know, colleagues test the stuff. You can find that, oh, it worked great. My machine doesn't quite work on the actual production side or something. Test these things. I'm going to then share, right? I mean, it's easier to steal if everybody else is sharing. So please be considerate and share your stuff at the end of this process so that I can steal from you. Okay. So now we're going to get into, you know, my four pieces and two that aren't actually done and the other crazy thing. And I told you to find your own path that really this really should be the first thing. The second third, you can decide what you want to do but the first one should be the component. I've given an entire presentation to just this and in fact there's a URL down here at the bottom here that is an example of a component. But a component is basically it's a single thing which contains HTML, in Drupal's case it's a Twig file, some CSS, if you like SAS I do, a SAS file, and some JavaScript. And it encapsulates an entire chunk of design and that chunk of design is in the CSS and it applies to the HTML that's in the component as well and if it has some sort of JavaScript requirements that JavaScript is all together, you know, put it in a folder, collect it, like that's the component. And it's completely repeatable so you should be able to use it in multiple places on your side no matter whether it's a node in one thing or some sort of other entity in another Drupal-y bit of the site. They should be repeatable. You should be able to use them no matter how it's built. And instead of having the god-awful high specificity selectors with really long Drupal selectors, we're replacing that CSS specificity with very specific class names. So the specificity is quite low because it's a single class name but the name of the class is quite specific so it's not going to, it's going to be self-contained and not bleed into anything else because you're not going to accidentally add that same class to something else. And nestable, right? So a lot of times these components will have other components inside them. That's what you want, right? Here's where the part of the demo comes. Jump out over to Firefox here. So this is the FlowerPower one. This is a URL. I'm going to post all of these URLs as a comment on the session page so you don't have to, like, frantically try to write down all these URLs. Some of these URLs are quite long. But here's the FlowerPower. This is a real HTML and CSS component. I'll show you here in the Inspector. You can see, oh yeah, I got it mirrored. Here. So this div is our flower component. So I added a flower class. It is a complex component so it has multiple divs, including petals and face and stems and leaves, right? So you construct these using those sort of class names that I showed and this site actually talks about, shows you all of the names of the classes that you use and how a particular component is structured. And I'm not going to go into that detail because, like I said, I did an entire presentation just on this. But yeah, here's... So this is a variation of our component. It looks like a tulip instead of our daisy. This is the desktop version of the site. You can see it's got great hover effect going on there. This is the print styles. Yeah, here's some extra HTML that this particular component has so it has a flower bed. And if you know smacks, there's a skin in the smacks as scalable and... Oh man, I forgot what that stands for, smacks. SMA, CSS. Scalable and modular architecture for CSS. There we go. Yeah, so skin is one of them. This is the at night skin. Whoa, that really doesn't show up there, does it? It looks great on my screen if you want to come around this side. So... And if you go to that URL, which is actually what we were just looking at, at the very... Beginning here is a link to that presentation. So the videos for that. And it goes into quite a bit of detail about how to actually construct a component. This is super critical. Writing your CSS using components. Drupalate using chunks of twig that are inside the components. That's the first thing you should be doing. But then everything else is whatever path you want to take. So let's talk about the twig, the sass, and the bugly. Is Morton in here? So... This name, I'm sure if you're as old as me or possibly younger you might know that there's a movie called The Good Bad and the Ugly. Fantastic Spaghetti Western. Man, highly recommended. So I have to show you a little video clip here. Not good. Can you believe I did this this morning? Oh, man. So the bugly selector. I talked about components, right? So component basically means that you have a specific class name that you need to put into your markup, right? But we use Drupal, right? And sometimes it's really hard to put the class exactly where you need it in the markup because Drupal sucks. And this is a really good example. So a lot of times, like, nodes or comments, they'll have a link inside the title, right? And getting at the actual A tag in there, it's, like, really hard. So instead, I use SAS in this bugly selector technique, right? So I honestly think that SAS is almost required to use when you're using Drupal. You can do this with plain CSS. It's a little bit trickier. But basically here, we have the ugly selector. Is that mine? Oh, no, that's your weekly updates here. I suppose that, no more reason. I have a phone down here that's transcribing everything that I say and it's beeping. I put my phone into airplane mode for that very same reason. I did a presentation two years ago, and my wife who's in Taiwan called me during the middle of the presentation. She had no idea what time it was, so I always put my phone into airplane mode. Yeah, oh, sorry. So the selector in the DOM that I can't change because it's Drupal and I can't figure out how to change it. So, like, this is the best that I could do. I was able to get a class onto, you know, the title wrapper div, or the, what is, H2, right? But I couldn't get into the link. So I write that bugly selector in the DOM that I couldn't change, and then I use SAS to extend into the class name that I wish I could have used. And so what this means is that I end up with rendered CSS that has the beautiful class name, comma, and then the fugly selector. This technique works really well because it's, you would think that you wouldn't need to do this. You could just, you know, write it by hand, but when I start writing CSS by hand and have fugly selectors all over the place, it's really hard for me to concentrate on writing the component the right way. And this makes it really easy. So I'll write the component the right way in SAS at the top of my file, and then at the very bottom, I'll just like have a bunch of fugly selectors if I need them, right? So usually when I, this is my, it's not my last resort, but I will try for like, you know, maybe like five minutes to try and figure out how to get the class in there, and then I'm like, ah, and then I'll write a fugly selector, right? So, noodling with JavaScript, toodling, toodling. So, all of the new tools for front-end development have been written in Node.js because it's JavaScript, right? I mean, we've been using JavaScript since the very beginning. Netscape 1.3 or something like that had added JavaScript, and it's very natural that once somebody created this Node.js thing that was all JavaScript, that front-end developers would flock to it and start writing their own tools instead of waiting for the damn PHP developer to get out their ass and do stuff for us, right? So, we're doing it for ourselves. We're writing it in JavaScript, and that means that we need to learn a little bit about the Node.js ecosystem in order to install these tools and use them, right? So, it's not, I don't know. It's okay. It's not popping everything up. I'll just ignore that. Or can you mute it? Can you mute the audio that's coming out and then just... You think it's my laptop that's doing it? Or I can just pull it? Okay. It might be my laptop, I suppose. Okay, so. I wrote this Quick Start guide for NPM because I didn't understand it when I first started using it, and then once I sort of felt like I had a good handle on it, I wrote this Quick Start guide. We're going to go through this real fast. So, if you want to use one of these tools, like ESLint, which is a linting tool for JavaScript that will tell you about code style bugs and that sort of stuff, you need to actually install that software and the way you install it is using NPM, which is the Node.js package manager. Here we are in the Quick Start guide. And you need to install Node.js, and I'm not going to show you that. But one of the things that I want to talk about is this concept that NPM has, which is installing things globally versus installing things locally. So, when you have Microsoft Word, when you have Microsoft Word installed on your computer, you have a global version, basically. So there's one version of Microsoft Word that's on, you missed it, Maureen, sorry. Yeah. You have one version of Microsoft Word, so the latest, I don't even know what the latest Microsoft Word is, 2014 or whatever they call it. And if you have a Microsoft Word 1.0 document somewhere in your folders, you can't open that file anymore because you have a newer version of Microsoft Word and it can't understand that really old version. So it would be nice if you installed a new version of Microsoft Word inside a folder where you're working on some new files, and then you had the old version of Microsoft installed in the directory that had all the old files. So NPM works that way by default. So if you want to use the latest and greatest ESLint and JavaScript tools on the new project, you install them and you get all the new versions. And if you have an older project, when you first installed them, you can tell NPM, okay, I'm using the latest versions a year and a half ago, and then you set it up so that it always remembers that these are the versions I'm going to be using. So you can come back to an old project and continue to use the same versions of the tools that you're using originally. This is super, super convenient and is probably the reason why Maureen has so many problems because it's not doing it right. So that's why I'm going to continue to do it right. So if you have like a completely empty directory, let's go over here. The first thing you want to do is do NPM in it. This is going to create a package.json file. Let me show you what that looks like super quick. It's just a json file that lists all the tools that you've installed. So we're going to create one. I'm just going to ask you some things. So yeah, that looks good. That looks good. Keywords. Oh, GPL, please. 2.0. Yeah, that looks good. So... There we go. And I've already actually created this file. That's why it just added a couple of things to it. But it will create this folder for you, or this file for you called package.json inside the directory where you are. And then as soon as you do that, you can start adding software. So NPM install. Like ESLint. Oops. I want to show you the right way to do it. Save, dev, ESLint. And this will tell my package.json that I want to use this ESLinting tool for my development work. And that's what the dash dash save dev means. And it will chunk away there for a while, hopefully not too long. And it will add this line in spite my dev dependencies. And what this means is that I can go and every time that I run NPM install, later, if I come back later and I don't have any of these stuff installed, like NPM install, anyone install all these things. Yeah, this is why I'm going to hit control. So where does it actually install it? So there's a node underscore modules directory that it creates when it actually starts installing stuff. And everything gets installed into this spot. The nice thing is that if, and NPM people do this all the time, they'll delete that entire directory and then just run NPM install again and it'll redownload everything. The thing that you'll want to do, and this is the bit that I think you somehow missed, is that once you've installed it on your computer and you have everything working, you want everybody else on your project to also have the exact same versions, not basically the same versions, the exact same versions. If we look at this, it says, there's a little upwardkerat.2.9.0 and basically this says, install ESLint 2.90 or higher, as long as it's not, you know, to 3.0. So less than 3.0, but 2.9.0 or higher. This can cause problems if you install 2.9.0 and your colleague actually gets 2.9.4 and something about that causes, you know, slight differences and weird bugs between the two of you developers. So the fix for that is to do what's called NPM shrinkwrap-dev. Again, this is all documented in this quick start guide. And it creates an NPM shrinkwrap.json file and while the package.json was very sort of general, like, oh, yeah, 2.9 or better, that's fine. NPM shrinkwrap is like super anal. It is like this exact version is installed and these are the dependencies and these exact version of all these dependencies are installed, it is quite long. I mean, it's really anal. Yeah, so all of this stuff was installed exactly. You can go back to your get repository and then when your colleagues go into this directory and type NPM install, they will get these exact same versions as well. This will save you so much headache. So what are some reasons? We talked about how globally versus locally and how NPM does local by default. Why would you want to do global exactly? And the reasons come down basically is I want to be able to type one of those, one of the things that I installed just like right here. The problem is is that since it's installed inside node modules, my command line doesn't know that there's a binary hiding inside node modules for me to run. So the actual thing that I would need to type is nodemodules.bin.eslint and that's just really annoying. So instead, what I recommend to do is you can install this super handy tool called NPM run. Now NPM run, you should install globally, but as soon as you do that, you can now type the NPM run command from anywhere and if I type eslint, yeah. This will be using the exact version that's inside node modules slash dot bin and I can prove it here by doing a which eslint and you see there it's actually grabbing the eslint that's installed inside node modules slash dot bin. So NPM run is fine to install globally. There's very few other things that I would install globally. Grunt and gulp both have a solution to this problem that you want to have the newest version of grunt in this project and an older version in that project but you still want to run the command grunt rather than NPM run grunt so they solve this problem. Both of them solve the problem the same way. You can do NPM install dash global grunt dash client and basically this is a wrapper that does the same thing that NPM run does. So when you install this, you can run the grunt command from anywhere and it will look for the actual local version of grunt and use that version on that project. And same thing with gulp. It's the same thing. So you install gulp client and then as soon as you do that you can run I've got gulp installed on here. You can run gulp. And it's actually using the local version that's installed here rather than the in fact if I go outside of this directory where I don't have anything installed and run gulp here it's going to be like now I couldn't find a local version. There's nothing for me to do. That I think is everything about NPM minutes. Save, save, yeah, yeah. So that's a quick intro to NPM and then we'll go back to the slides. Should we run the video one more time for new morning? No. It's good. It's worth a rewatch anyway. Okay. Oh wait. Did you get the sass in the fugly? Yes. Okay, so that's NPM. Our next piece here is style guides at the center. I've also given presentations all about style guides, centric development, the Los Angeles session last year. I talked about style guides, centric development and basically what this means is that we talked about very briefly how you write a component. Well, you have a whole bunch of those together and now you have a component library. Wouldn't it be nice if you could run that component library through some sort of tool that generates a style guide that uses the real HTML that's in your component library and the real CSS and it shows it all inside a style guide for you. Because it's using the real CSS and the real HTML is always up to date. I first used style guides in like 1996 and they were PDFs and they were wrong when they gave them to me. They were out of date immediately and eventually I started telling designers stop giving me style guides that are useless. Give me a photoshop file. The idea is great. Document your design system but keeping that documentation up to date is impossible unless you had an automated tool that creates a living style guide. So, the tool that I like to use is KSS and I'm going to give you a quick demo about that. So, KSS is two things basically. There's a specification that talks about how you write the documentation and KSS likes to keep it really simple. You write a document because usually you do most of your work inside a SAS file or a CSS file you write your documentation in that file and it's just a normal SAS comment or a normal CSS comment. So, this syntax for it is like ridiculously simple. The first line is the heading like the name of the component and then like some text that describes it for as many paragraphs as you want. If you have variations of that component, you describe the class name that you need for the variation and then space-space and then describe that variant. You can also here you can use if you have hover styling for that particular component you can specify it this way. So, I would just hover style. So, that would add, that would show the hover styling and then you just tell it where the HTML markup is. So, I'm keeping for Drupal 8, I'm keeping my markup inside a Twig file, I'm surprised. And then the last thing in the KSS comment is a style guide reference which is basically it's a hierarchy that you define however you want. So, when you're navigating through your style guide you get to decide what the sort of top level categories are and then what the subcategories are and where inside your categorization this particular component goes and I've decided that I've got a main category called components and this messages component is just being listed next to all the other components that are under this category. So, components.messages goes into the style guide this way and I can do npm run kss is the name of the command line tool shows me all the different command line options that I can use and this totally works if I typed it in it would look through the source files I point it at the sass files which have all these KSS comments in it I point it where I want the style guide to be built which just generates it. Because it's a lot of typing like all the different options I have all that saved inside a gulp file and we'll talk about test runner in a sec but I just need to run gulp and it will go through and you can see here is it did the style guide task and it parsed through that and made let's go down to messages here and to prove to you that it really did actually generate it just then oops rerun gulp so it's really easy to keep your style guide up to date actually says hide and run and and I have a watch command if I run gulp watch and this is basically the same thing that it's continuously watching all the files that I told it to and I don't even have audio plugged in this time but I guess you guys didn't hear it so that's right I can mute my computer and I can change this text and it noticed the change and started doing the build and I'll go back over here and reload it's automatically updated the style guide I really really really really like style guides and the documentation for KSS spec is I really like to live this URL first oh come on Wi-Fi well regardless I will post the URL for the spec that describes how you write KSS and I'll post it on the actual page for this session so one of the nice things about having a style guide like this is the way it completely changes the way that I do development I can build things in the style guide I don't have to wait for the back end developer to implement it in Drupal that means if I have designs or if I don't have designs I can start working with the designer and start building them with real HTML real CSS and it gets generated in the style guide and I can do that independent of the back end developer and then when the Drupal feature is actually done in Drupal somebody can go back in and wire it all up add the classes that you need make sure that the HTML is actually being output by Drupal and it doesn't even have to be the front end developer like I worked with some people before and I did all the stuff in the style guide and the back end developer came in and like oh this is the classes in this HTML I know how to do that he implemented the Drupal part and all I did was the style guide and this approach of using the style guide has really changed the way that I do development of Drupal sites and I had a bof after Drupalcon Los Angeles and people kept coming up with more and more ideas about why this stuff is so great and it's just amazing the style guide you can sort of document all of these accessibility things that you have so if you are a public institution that is more and more of them in the US are being sued because their sites aren't completely accessible you can build documentation about accessibility into your branded style guide and be like use this or else all of these things become possible because of the style guide I love style guide centric development testing process so this is the piece number 5 that I didn't finish regression testing is a great concept and I still haven't figured it out so I'm hoping somebody else figures it out actually there's going to be is there a session on that here on regression testing I know that immediately after this session there's going to be a bof right after launch on style guide there's going to be a bof and certainly people are going to be talking about that there visual regression basically means I've made a change to my CSS and it takes a screenshot of before and after and compares them and it's a wonderful tool and I wish I knew how to do it budgeting for performance there are some really cool tools that basically allow you to say I want to have a specific budget 20 kilobytes basically a particular page I can download before I've violated my budget I want to be 165 pounds and no more but I want the weight of my homepage to be 200k so that it loads in however many point seconds and you define those things and you can actually track those metrics day to day and as you make changes and sitespeed.io seems to be a really great way to do it there's open source there are non open source ways you pay programs that allow you to do this without quite so much setup that are also available and like I said those are the two bits that I didn't get done see here we got 15 more minutes so let me show you a gulp file so to go back to JavaScript tooling one more time all of my tasks when would you need to start using a task runner if you have like one thing that you're doing you don't need a task runner so if you are only using a task and it compiles your CSS and you're not doing stock guides you're not doing anything else you don't need a task runner because you're only running one command but as soon as you do two things and you have to run two commands in order to get all your changes made and up onto the production website before your boss kills you then you need a task runner and the task runner basically allows you to have one command and it does all the things that you want to do for you grunt is a great task runner gulp is also another one that's sort of up or coming I use gulp and this is how you do it so the very beginning of my gulp file.js this defines all the tasks that I want to do inside my project this is the one that comes with the the zen theme we're looking at the jupel 8 version but jupel zen 7.x 6.0 came out this morning it has a gulp file in it and all these things are set up for the starter kit for jupel 7 and it looks very similar to this some paths are different basically and it starts off by defining some options this is just a regular javascript object and it's full of the paths that are where I keep all of my different assets my sass, my css and I just sort of define this myself and then once I get past all of these options here's where the sort of task based part of my gulp file starts and requires a node.js contract to function that will load in these optional modules into your js file we're loading up gulp we're loading up some of the things we're loading up kss because of course that's the thing that generates our style guide here and then here's our first api call gulp.task this is the task method on the gulp object and it's basically defining the task the default task basically means when you type gulp and nothing else and hit enter it will run the default task and this case is defined as a list of dependencies so my default task depends on this build task which means I need to run the build task before I run the default task so there's nothing else on this line which means that our default task is basically a null task that only does the dependencies so it's going to do the build task and if we scroll down here we will see the build task and this is slightly more involved in that it has multiple dependencies we have three different dependencies so before the build task starts it will start the styles colon production the style guide and the lint task and it runs all three of those at the same time so all the dependencies get run, all those dependency tasks get started at the same time they run concurrently rather than sequentially which means that it's pretty darn fast let's see where our styles production task, let's look at that one so here is the third way that you can use, or the second way that you can use gulp.task we've defined the name of it the fact that it has a colon there is just a way that I stole is a naming convention that makes it really easy for me to sort of organize my task names so the colon there is just a convention and it has its own dependencies and then here is a JavaScript function which defines the tasks that I'm actually doing and now we'll start to see some other gulp API calls gulp.source basically that means I have a sas files variable that I created that lists all the sas files that I actually want to read and this gulp.src will read all those files and then start piping it into these pipe calls so if you're familiar with Unix pipes, this is the exact same thing not many people are though but basically it reads all the files and then it passes it along to the next thing in the pipe and the things that are in the pipe are gulp plugins so here we're using sas which uses the lib sas compiler which is written in C and it's much faster than the Ruby sas version and it passes those raw scss files onto sas which then compiles them then I pass it on to the auto prefixer gulp plugin which goes and adds bender prefixes to the beginning of all the CSS properties that I need depending on which browser I decided I wanted to support then it shows the size of all the files so for example here let's gulp styles production you can see here, so it's listing out all the files that it actually generated and the file size I really like having the file size listed there because then if I see something it's like 36 nags oops and then the last thing the last sort of API call in gulp is gulp.desk which is destination and then it basically just writes all those files into this new directory that I specified so gulp source reads files in gulp pipe pipes it onto the next plugin gulp.desk writes it to the directory you specify there's only one other and I will have taught you the entire gulp API and that is for watching the watching works just slightly different in that instead of gulp source like reads all the files and then passes it along the pipe gulp watch literally you just point it at the files instead of reading it in it just watches it and says is there any changes? and then if something happens so this is the list of files that I'm going to watch and then again we have like some dependencies right well these dependencies they don't get run before the gulp watch they get run when a file changes so if one of those files changes that gulp watch was watching it runs these other tasks and that's it you learn the entire gulp API you are able theoretically to write your own gulp file now that's one of the things that I like about gulp.js a lot is because it is very easy to learn and I would pull up the URL here but I'm sure that it won't load oh wait no I already loaded up yay so gulp.js is on github github.com gulp.js and they have a link to their API docs and I will post this link on the session description and you can see here this is the entire API docs gulp source options for gulp source gulp destination gulp task gulp watch somewhere in there is pipe but I missed it that's it those are the only things you need to learn in order to write your own gulp tasks and just to show you that I really really believe in that whole steel, iterate, test and share if you look at the bottom of my gulp file I've listed the places where I've stolen from and then of course this file comes with zen so I'm sharing it with you and I've gone through lots of iterations and testing on this so it works quite well feel free to modify it to your own needs yeah so that is the last little bit about JavaScript tooling that I wanted to talk about which means that I don't quite have time to talk about the one crazy idea about drupal 8 and drupal components I'll give you two minutes and then I'm going to have people ask questions so what's wrong with drupal 8's html.tweak files morning yeah so when you're building a component file name drupal insists that you have certain file names so no dash dash event.html.tweak is a common name that you have the problem is that file name is not a component it's a drupal thing so the file name is completely wrong the other thing is that drupal forces me to put all of my drup files inside the templates folder and because I build components where I have html and my CSS and my JavaScript all together that means I have everything inside templates so like the directory is wrong too and then once I open up the once I open up the html.tweak file it's full of these crazy variables like content.comment or content.fiel dot whatever image you drill down to these things I would never name variables like this they're really they're drupal specific they're awful so besides the file names, the directory names and the variable names they're fine right but I started to build the Zen theme in drupal 8 about 3-4 weeks ago and I've come up with a technique where you don't have to put everything inside the templates folder you can put your components in a components folder and the twig files that you write are vanilla twig files the variables that are inside those vanilla twig files are whatever you decide the variable names are so you get to write twig exactly the way you want to without worrying about drupal variables and then inside those godawful dot html.twig files which are still hiding over there in the templates folder I end up basically just calling my component twig file through like a include so I will include my component or an embed and I'll embed my component or what's the third one include embed and extend and then I can have twig blocks inside my twig files and then basically if I've got a whole bunch of drupal variables that are all shoved together I can put that inside a twig block extend and my component is written very nicely clean vanilla JavaScript and the best part is that my style guide builder kss knows how to read vanilla twig it reads the real twig files that are inside those components it builds this style guide using the same html so this style guide has css a real css it has the real twig html and drupal is consuming the same thing there's no like fancy footwork going on drupal reads that file like normal and kss reads that file like normal no fancy gulp things going on it's just reading the same file it's really nice and I'm going to have a bof on Thursday that sort of talking about this idea and asking for volunteers because I've only just sort of started this conversion over but we can talk about this idea in general and this is the thing that I'm talking about with everybody yeah so questions thank you if you have questions come up to the microphone if you're really hungry feel free to leave it's a microphone on how do you add the javascript to the style guide to use the javascript from that component so kss has options to specify which css you want to include in the style guide and also which javascript you want to include so you have to basically specify for example in my gulp file I'm writing all the options for kss to tell it how to build the style guide and I just have to specify the name of those javascript files it's a little bit manual right now I would like to automate and I have a gulp task so I should be able to automate in some way that's one of the next things I'm going to be doing actually so yeah and the thing is that each of these components in Drupal 8 basically every single component needs to have a library so that means I have this giant libraries folder for the theme and every single component has to have it at its own entry that's a problem that I'm actively working on with Wim Lears and some other people to figure out how do we automate that bit so they would have to like Morton was just complaining about oh my library's diable is so long is the mic working? I think so yeah so it's I guess more of a comment so thanks for mentioning the style guide and visual regression workflow at one unless it moved you might have gotten the room wrong I think it's in 291 but it's somewhere so if you're interested come join it's on the buff board oh it changed on the buff board I would have hoped so I copied it off of this website like an hour ago or something like that okay then maybe I'm wrong but it's somewhere I swear thanks I'm wondering about your choice to go with KSS over pattern lab can you talk a little bit about maybe the advantages you see in that yeah so when I started looking I looked at a whole bunch of tools before I picked one pattern lab was on the list KSS node was on the list you know pattern lab had the sort of quote advantage that it was written in PHP just like Drupal is one of the things that I wanted to have flexibility with though was to be able to use one style guide tool on any kind of project you know I'm sort of flexing my muscles as a front end developer and if I want to be able to have the opportunity to write an app I still want to be able to generate a style guide for it and so I wanted to have something that was slightly more independent of PHP so the advantage of basically this was Drupal 7 when I started looking at it and I knew that there was no way in hell I was going to be able to get Drupal to run through pattern lab that just seemed like a nightmare so that advantage didn't seem like a good advantage to me so I ended up picking KSS node which is a Node.js tool so it meant I volunteered to become a maintainer of it I'm the primary maintainer of that application now and it meant that I got to make my JavaScript skills even better by writing this application and yeah that's why I picked KSS node but pattern lab is a great tool there actually was a session yesterday they left on pattern lab you can watch the video on that where's all the sample markup coming from for the style guide oh the sample markup right so yeah so if we go back and look at my messages.twig file here lots of SVG I didn't have to run it through a menu or anything like that just I'll put it right in the twig file I have variables here for where the content goes right I don't have like sample content but I KSS supports this ability where you just have a simple JSON file which has the same name as the twig file and it reads these in and makes variables for each of those things specified in JSON so it's creating a heading variable and the messages variable which is an array of strings and that's how KSS node knows to load that up there are other ways that you can do this not with KSS but there are other systems that have different ways this one is like dead simple so that's the way we went Wim was just looking at this and he was like so yeah so I was just wondering about your opinion on post-CSS and is it a tool or workflow yeah post-CSS is really interesting I want to say that I think Morton would like it but I don't know I would post-CSS is basically it comes from the idea of all these preprocessors are kind of annoying we should just write CSS but like vendor prefixes and supporting all of these different things which is a primary use case of SAS we can do that in a post processor rather than a CSS preprocessor so post-CSS will go through your CSS file and do all the things that you wanted to do it has like a whole bunch of plugins so like it has a post-CSS plugin that will like strip all the white space add the vendor prefixes remove duplicate selectors it's a great tool I've been using SAS for a while so yeah right yeah and if you saw my actually auto-prefixer is one of the post-CSS filters so I'm just using it I think so but I mean like oh I'm using gulp auto-prefixer I think that if you looked at the github URL for the underlying dependency of gulp it would be under post-CSS it's under there under umbrella when you're writing JavaScript for a given component is it aware of the JavaScript Drupal object and do you write it using like Drupal behaviors in JavaScript using Drupalisms or is it more vanilla JS and is KSS aware of the Drupal objects can KSS yeah that it certainly would be nice if I could write more vanilla-ish type JavaScript and then have this be consumable outside of a Drupal environment um that's something that I'm minded to explore and I would love it if somebody else explored it and told me how to do it so I could steal from them but for right now I'm using some of those Drupally bits still like behaviors and all that stuff and you can this can be configured to load any JavaScript I literally load Drupal's JavaScript inside the KSS DeliGuide the Drupal JavaScript doesn't care what markup is actually there so the fact that it's run on a KSS DeliGuide doesn't matter to it so do you repeat all of the Drupal JavaScript dependency library dependencies to make sure that you get all the right Drupal so the thing that I just told you was true in Drupal 7 I've only been doing the Drupal 8 bits for yeah, that would be pain in the butt having to do all the dependencies like go through all the libraries to find the dependencies and then load every single dependency inside yeah you can do it manually yeah, I don't have a better answer for you right now like I said I've literally only been doing the Drupal 8 stuff for like four weeks we'll keep sharing and stealing I was going to talk about I did this stupid thing for Drupal 8 and then I put it into my theme kind of like a mega-dose and then in that module it takes the style guide and puts it into a Drupal page sorry a Drupal module or like a Node.js module so inside the theme it has a directory for the theme and one for the module because you can't do certain things and themes like make routes and so it's just I just made a route and then I used stupid PHP parsing to just bring the whole style guide into Drupal so I don't have to import Drupals.js actually in Drupal and it's in GitHub maybe I'll post a link to it even though it's stupid, it does work even though it's stupid that's fair it's a really dumb way, somebody's got a better way but at least so KSS Node the new version which is like 3.0 0.0 beta 12 or something like that has an option that you can run which is extend Drupal 8 and what that extension does is it loads some some you know how Drupal 8 has some twig extensions like attached library is a function that you can run inside Drupal twig files that's not a thing in twig it's a Drupal thing that it added to twig but the KSS Node then has this option to just sort of rewrote those like attached library don't actually need to do that inside KSS Node it just understands the syntax and then doesn't error out and then ignores it so it adds in a bunch of extensions that will cause your twig files to not die when you run it through twig.js so we could extend that idea I mean YAML is not that hard to read so maybe you could figure out how to read all the libraries and then dependencies if you don't want to be recorded I'll be up here for a little while and like I said there's a bof right after lunch we're talking about style guides and visual regression tests and then the Drupal 8 twig stuff is on Thursday thank you