 Okay. Can you guys actually hear me in the back? Yeah. We've got about two minutes till we kick off. You want to follow along. You're welcome to. The slides will also be available after the presentation. I put them in the comments on the Drupalcon site if you just want to go there and click instead of typing all that in. And I don't promise it looks good on a phone. I didn't do a responsive burst. Oh, sure. You're going to have to. Sorry. We're doing some fancy recordings today. So we have one minute left but can I get a show of hands of who in here is a back end developer and who considers themselves predominantly a front end developer? Oh, awesome. Hi, guys. Anybody here from business, marketing, project management? Good. Glad to see you here. Please know what we do. It's important. We're in the right session setting up a front end development environment for Drupal 8. I'm Kristen Bradham. I'm also known through the Drupal community as K2, like the mountain, yes, or the character in the new Rogue One movie, K2SO. He's going to come up later in the presentation. Why am I called K2? I'm K2 because I work very closely with another developer named Kristen and we got confused on day one. So my name is Kristen Bradham but I'm known through the Drupal community as K2. If you would like to follow along, the slides are available on GitHub. This is a reveal JS presentation so you can look at it on your web browser. They're also, I put them in the comments on the Drupal page. We are getting standing room only in the back. So those of you who maybe have a seat next to you, if you could scooch in a little bit, I would really, yeah, raise your hand. There are seats available, like I see a whole row right down the middle here. That's not an IOC. Sorry, we only have middles left. But if you would like to come forward and sit down, there are more spaces. I'm happy to see all you faces here. This is your first session. Who's first Drupal con? Anybody? Right on. Yes. Yes. We have a lot of fun here and we need you here and we love Drupal community and hopefully by the end of my talk I can also inspire you to come up and try to present next year, present at your local Drupal user group or get involved in some way. My first Drupal camp was about four years ago and I never thought I'd be standing up here but here I am. So we're going to get at it. Called hook 42. You're going to see us around here. We like to contribute by giving talks. So we're giving, I think, four or five talks here at Drupal con this year. We've been doing Drupal websites for about five years. We specialize in SEO, multilingual, migrations, big old Drupal projects and yes, hook 42, we like Douglas Adams. That's where the name comes from. 42 is the answer to everything. Life, the universe and everything. Thank you. About me I kind of said before, my name is K2. Everybody knows me as K2. Little children call me K2. That's my name. Everywhere that I am in the Drupal verse. I am a site builder slash friend and developer slash I do everything and anything. We're a small company so if they need some help I come out of the woodwork and help. I've been doing web stuff forever. My talk today is going to be a lot about command line tools and as I like to joke with some of my younger colleagues, I remember when the command line was the computer. So I've been doing computer stuff since I was eight and that was a lot of years ago. And I don't say anymore because I just don't have to. But I've been doing Drupal for almost five years. I'm a couple months shy but once I found Drupal I really like this space. I really love the community. I love the support. I love the group. I love the people that I've met through this type of work. I have three kids and two dogs. If you want to talk to me later I would love to talk to you about my kids and my dogs. If you have dogs I will talk to you all day. I will probably remember your dog's name and will not remember your name. So why did I pick this subject? So boring, right? Hey, from an environment for a Drupal 8. So boring yet all of us start here. We all have to do this. We have to get them in order. We have to get our environment in line before we can do any developing. So just to be very clear about what this talk is about, I don't do any development. I just set you up to do development in this talk. The front end has more command line tools now than the back end does. And this has been a major shift that we've seen in the last three to four years in front end development. The front end development has taken off. We now have all sorts of different ops tools and we are working more and more on the command line. We have gone from front end being your graphic designer, your just CSS, I just know CSS and HTML to really being full of programmers who know a heck of a lot about JavaScript and need to organize ourselves because of it. So we need a checklist. Like I have every time I set up a new environment, I need a checklist because each client of mine sometimes we're on Auklius, sometimes we're on Pantheon, sometimes we're somewhere else. It seems like every single time I try to set up my environment, I need to go through the checklist and make sure I am setting up everything correctly. So this talk is as much for me as it is for you. I made myself a checklist. So the first thing we're going to do, there's four major parts to the talk. We're going to talk about general environment setup, Drupal 8 setup. Then we're going to stretch and yes, I am going to make you stand up. So be ready for that. I'm giving you fair warning. Then we're going to do front end dev ops, which is your gulp and things like that. Then we're going to talk about one part of front end that's very debatable right now and that's theme structures and how we're structuring our folders, our files, our selector names, all that. That's where I'll get some people questioning me at the end on what I think is best and what you think is best. So general environment setup. I'm going to go through this part pretty quick. But here's my checklist for what do I have in my environment. I need to make sure I have my good editor, my hosting setup, my map set up, install Drupal, dev modules, permissions, bash out and get. So editors, this is pretty straightforward. Most of you probably have an editor that you prefer. I say if you like your editor, stay with your editor. I've moved to PHP storm because for Drupal, I'm working in JavaScript, I'm working in twig, I'm working in PHP and PHP storm supports all of that. But code and code kit, if you're straight front end, they have some serious advantages and I do recommend that you take a look at that. But more important than which editor is that you set up your editor for Drupal coding standards. A lot of you raise your hand that this is your first Drupal con. Drupal coding standards are very, very important. And what that means is what your white space looks like, what your syntax looks like and how you format it. And you can set up your editor so it does it for you. For example, I am going to save you about three hours of my time right now by saying .yaml files require two or multiple of two spaces to work, not a tab. If you mess this up, you will have a white screen of death and it will take you three hours of Googling to figure out. Or at least it did me my first time. So it's very, very important. Now it's not just what it looks like, but especially now that we're working with YAML files, get your spacing right or you will crash your site. Hosting. This is just my list of things that I get together for hosting. Find your SSH keys and figure out how they do SSH keys. Why this is so difficult? I don't know, but this always seems to take me forever. And then find out what hosting-specific tools you're going to be using. There are boos here for all of these people, Pantheon, Calibox, Acquia Dev desktop. They all have their own tools. They all have their own workflows. They have all kinds of wonderful things for you. So I suggest I've worked with all of these. And they do change how your environment is set up. I debated with myself on whether or not I wanted to go through each one of these. But honestly, Pantheon is going to do a much better job of presenting Pantheon's product than I am. But just know that this is going to be something that you'll have to set up and learn the workflow of if you're working on a big project with a number of developers. Mampwamp, I really only, if you're running your own local environment, you need to set your memory limit very, very high. And the reason for this is for front-end developers, when we turn on twig debugging, it's going to crash if it is not high enough. Twig debugging takes a lot of memory. So just please, before you even try to start developing, you're going to save yourself a lot of time if you go and set your memory limit high. Other modules that I go on and I install locally, just for myself, and you can get ignore these if you don't want to push them up, are devl, devl, devl, devlkin, stage file proxy, which allows you to pull images from a live website rather than having to have the files on your local. For some of my clients, the files are, you know, hundreds and hundreds of gigabytes. So it's not realistic for me to have files on my computer. You might want to turn on a style guide so you can see what you're developing really quick. And then admin toolbar is just something I always turn on. So now we've kind of set up Drupal and just every single time, again, this is just on my checklist. We're going through the checklist now. This stuff is super boring. You've probably done it once or twice, but here you go. Remember to do this. You got to change your file permissions. Pro tip. I am huge, again, on the command line. And a lot of front-end developers are afraid of things like this, but I'm going to talk a little bit about bash aliases. A bash alias is just you get to make a little tiny clip, like CDP, and it runs a whole long command for you. Then you don't have to remember it. Later on, you don't have to write it down in documentation. It's already in your aliases file, okay? So when I type CDP into my bash shell, it runs this and changes my file permissions for me. So another permissions that you need to make sure that you gather is, and this is again every new client that I get, you need to log into the site, make sure that you have permission as an admin so that you can edit and do things that you need to do on the site, and that you are not user one. Who here drush Ulys into their client site as user one? Yeah. We do it. We all do it. Don't do that anymore. The reason that I say this is if you have your own user, things are tracked, things are logged, they can't come back and say you did things when you didn't. If you're just drush Ulys in as user one, it becomes really hard to track who's doing what. I'm going to come back to bash RC. If you're a front-end developer and you don't know what your bash RC is, this is your slide, this is your homework. Go home and find out what your bash RC is. It's just a little tiny file and in this file you can make yourself all the shortcuts in the world. Suddenly the command line will be your friend again. And this is where my, I remember when the computer was the command line. These are pretty straightforward things. They've been around for years. There's lots of documentation. Please go check out your bash RC. So you can see here, my bash RC has aliases just to change directories. That's the first one. Go to my ht docs directory. A second alias actually goes into Pantheon, downloads a database and puts it into a file. So I don't have to go to Pantheon and click download the database and then go and put it into the database. When I want to get a database, it's actually two aliases for me. So these are really powerful little tools if you aren't using for the front-end. Please go look at these up, see what other people are doing. The last thing I have here is a little bash script that the one is a parameter. So when I type in sget, then it's going to search my get branch for all the get branches for whatever my search, whatever I type in after that. So you can write little tiny snippets of code really fast. And this just anything, when we talk about, these are your personal front-end dev tools that you know that you have to do. And you have to go and look at these commands over and over again. Put them in here and then you won't have to search for them and you won't have to type this much. Okay. I debated whether to even put this on here, but it's important that you put get in and more important that you're in your get ignore file. You're ignoring your node modules. We'll talk about why you get a bunch of node modules, but you don't want to check all that stuff in. So you do need to create a get ignore file and ignore your front-end files that you do not want to check in for other developers. That's very important. Okay. So that was just our general, like, you could use all of that for any site that you're developing. Those weren't Drupal. Some of them were Drupal specific, but here's some more specific to Drupal. Things that we have to go into change. We pulled down our local environment. We pulled down our code. Now we need to go and change our settings.php, our services.yaml in order to debug Drupal. I'm going to talk a little bit about yaml files. You need to make sure your address is up and running, and you might want to use Drupal console. So, who here has edited their settings.php file directly? Yeah. Okay. So that's all the back-end developers and some of the front-end developers. You really should be making a settings.local.php. Again, then you can put whatever you want in there. You're not going to step on anybody else's toes. So the settings.php is for generated when you set up Drupal and everyone shares it. You can turn on settings.local, so it'll just point to that. You can put your own settings in there. And then you put your local database. And more importantly for us front-end people, you can disable CSS and JSS aggregation there. So you don't have to go into the GUI and keep turning it off if that's what you need to do. And then when you pull, it's not going to turn that off with other people's config, either, because now with Drupal 8, we're passing config around as well, right? So it's important that you do this here. Services.yaml, it works kind of the same way. You can make a services.local.yaml, but make sure you put that in your getignore file. And you want, you can go through your services, tip, find, grab, this twig debug. You'll just make, you can make just a services.yaml that has just this little code in it. And you'll turn twig debug on, okay? Services.local.yaml. And that way, again, you're not editing the shared file, the services.yaml that everybody is using. You're just doing it for yourself. Then in your twig files, once you've done this, again, this is, I'm giving you guys a lot of homework. I'm not going through step-by-step how to do everything. I figure you can Google just as well as I can, right? So a lot of these are like, okay, make sure you do this and if you need more help, go Google it. But in your twig files, you'll be able to put these two, once you've turned all these things on, you'll be able to put these two commands into your twig files to get more information about what's available in your twig files, okay? Remember, no development yet. We're just, we're just turning on our development tools. Okay.yaml files are something new in Drupal 8 and who here remembers how many spaces for .yaml files? Two. Two spaces. Two spaces. Two spaces. No tabs. Two spaces. Or you will break your site and yeah, I was so frustrated when I figured this out. I was like, you have to be kidding me. I put in an extra space and like, I buoyed the whole site. So this is, but most important are your theme.info.yaml is gonna have your regions. And now we have .yaml files that we can pass around things like break points, because now we don't have a GUI for break points. It has to be in a YAML file. And it's most commonly used for images and pictures, but most friend and people are gonna know what their theme.breakpoints.yaml is. Theme.libraries.yaml is another really big shift that's happened in Drupal 8. That's really fantastic, okay? You can load libraries. Now you're not loading jQuery globally. You're gonna just have this little .yaml file. You can load jQuery that. There you can load any other CSS, JavaScript, source, anything you want in this little .yaml file. And here's an example of that. So for the global library, it looks like this. If you want to create a library just for a specific page and load it there, you can do it here, but get really, really interested in libraries, your libraries.yaml file, because there's a lot of power there. And if you need jQuery, this is where you turn it on. So finally, again, Drupal 8 specific Drush. We're now setting up Drush with Composer. We're doing lots of other things with Composer. So you do need to learn Composer and how to install things with Composer. So Drush is a nice intro step into that. Composer is becoming more and more of a part of Drupal 8 installs. And there's also different ways to use multiple versions of Drush. If you look on the Hook 42 website, we have an article by Jeff about that. Drupal console. I was really Drupal console resistant. I'm command line, but I'm like, really? Another one. But Drupal console has some really great things for us themeers like GT, generate a theme. So if right there, you just generate your little theme file and all your .yaml files, and it just makes a little folder for you, and this just made me extremely happy. So go learn Drupal console. It is worth the time. Okay. So this is where I'm going to make you stand up because we got halfway through. Everybody stand up and stretch. And if you didn't want to, Cassian says you have to. If anyone he gets that joke. Okay. Who thinks I'm talking too fast? No one. Okay. That was my, the last time I gave this feature, they're like, you did not take a breath. So, oh good. So everybody stretched out. This is K2SO. I love K2SO. He is snarky. Just love. He's just me. This is, if you want to see my avatar, that's it. All right. So now, probably, this is the part that you guys all came for. Okay. So we got through the checklist of all the Drupal 8 stuff. We got through all the like, okay, we did our bash aliases and we're setting our PHP and our server stuff. Like all that super boring stuff. Now we get into what is really fun for the front end people. Okay. So we get into the front end DevOps. And this is, this is again, exploded in the last few years. Maybe two and a half years, three years ago, we were all like, grunt, grunt is out. And now grunt is over. Okay. Grunt's gone. I am going to talk about grunt because you might inherit grunt because themes do stand around for more than two years, amazingly enough. But this is, this is the ever-changing landscape. And I actually had a lot of requests from back end developers for this part because they would ask me questions like, what is Node.js? So some of this for you front end developers is going to be, you know, stuff you already know and you can correct me later when I make mistakes. But for the back end developers, there's some, some definite information you'll need here. So when I'm setting up my front end dev environment, I'm going to set up Node.js, NPM, Gulp, version control, SAS, SAS tools. Why, and a lot of what we're going to talk about is task runners, okay? So when we talk about front end, what, whoops, hi K2. When we talk about front end dev ops, we are going to talk a lot about task runners, which is Gulp, grunt, things that do things for us, kind of like aliases, but on speed. So why a task runner? Why do we need a task runner? First of all, because we all love this thing called SAS, right? SAS is a fantastic innovation in what we're doing with CSS that makes it more available to make larger and larger sites with, you know, crazy things we should have had in CSS earlier on, like, and I'm thinking, I can't even think of the right word, but, you know, dollar sign, somebody help me. Yeah, variables, thank you. Sorry, you get in front of, there's probably 150 people in here, and I get a little, get a little loopy. So SAS, because of all those variables, it requires compiling and watching. Compiling is an old computer thing, right? Like, we don't compile on the web, but SAS requires compiling and watching. Now, this is where you get into, you want the better front-end developers, and the better front-end developers are the JavaScript developers, and the JavaScript developers like to lint, concat, and uglify everything. This is very different than, again, other things that we have on the web, but we want to do this, and we want to do it right now, and we like our goal for doing that. There's also some very big advantages to time live reload, for example, if you change your CSS, it just reloads your browser for you so you don't have to go over and click reload, reload, reload each time you make a small change, okay? A task runner is going to do that for you. A KSS style guide, this is a, an alternative to things like pattern lab that comes out, it requires a task runner, regression testing you can do with a task runner, so it's, et cetera, et cetera, and so forth. Each front-end developer has this list of repetitive tasks that we want to do, and so we need a task runner, okay? Before we can have a task runner, we have to install this thing called NodeJS. What is NodeJS? And I get asked this by more back-end developers who don't do JavaScript but do PHP, right? This is a huge framework. NodeJS is huge. It's not just for front-end. Whole applications are written in NodeJS, okay? NodeJS is a whole other way to write with applications, or actually applications for all kinds of things, I shouldn't say what. But for us, for us front-end, Drupal developers, we just install it because we want to install Node packages with it. So people are writing these little applications in NodeJS, we want to install those applications to do our, our busy tasks for us. So that's what NodeJS is. It's a huge framework. We install it so that we can use Node packages with the NPM. Some of the more advanced front-end developers are, of course, going to go and write their own Node packages. But that's, we're not, we're talking Drupal Sphere here right now. This is, this is what we do it for. NPM stands for Node Package Manager. So we just want these little applications to pull in so that we can run all these repetitive tasks that we want in the background. And it's a large repository of online NodeJS projects. There's thousands and thousands and thousands, probably hundreds and thousands of these. And we use these to automate our front-end processes. They're installed as part of NodeJS. So we install NodeJS so we can use Node Package Manager and run the nodes. NPM engulf. So we've installed NodeJS, we've installed, we've said, okay, as part of NodeJS, I now have Node Package Manager. And now I'm going to use Gulp, which is the actual task runner. And it helps us automate tasks like watching SAS, which we talked about before, linting files, concatenating files, all those little things that JavaScript developers like to do to make things really, really small. Smallness is a thing in JavaScript. There's a whole community of people that are like, I wrote an entire application in 15 characters. You know, this is like, we like this. We like tiny, tiny, tiny. And we can add to our Gulp abilities by installing NPM Gulp packages. You can also use NPM as your task runner. And this is becoming more common. I'm not going to talk about that now, because it's more common, but it's also a little bit more complicated, because the advantage of Gulp is that it's easy to read, front end developers can do it really fast. The NPM is a little bit more installed. So to install Gulp, here, I just put this up here, because you see, now I've installed Node, now all I have to type is NPM install dash dash, save, dead, Gulp, and then run NPM install and I'll have Gulp on my machine and it's ready to go. And I can start using all these fancy little tools. And all of them are the same way, right? Install Gulp sass, install cat, and Lynn, Aglify, all these things, all those things I said before, there's all these little NPM packages that we install. Because we're installing these little applications from somewhere else, it's important that we have version controlling. Because when you're working on a great big team, one person might have one version of Node.js, another has another version of Node.js, another has a version of sass, another has a, and the outcome of your compiling is going to be different. So we need version control for which application we're using of all these millions and thousands of NPM applications. Because the guys who are working on them and the women are updating it all the time. So you need this so that different developers are using the same versions of NPM and Gulp tests per project. So on my machine I might be using sass 3.0 over here and sass 2.0 over here and node this over here and NPM that over there. So you need to have some version control so that when you go into the project, you're using the right version of all these little things. And so the same machine might have two versions of Node.js or plugins and it uses the right one at the right time. And some types of version control or shrink wrap, bower, at the end of this presentation I have a link to a great article. Again, Jeff at hook 42 wrote that goes into how to really do this right. But I could give a 50 minute talk on this. But just know that you need to do this if you're working on a large team. You need to have version control. If it's just you, you can have your own task runner and be all cowboy and that's fine. But if you're on a large team, which most of us are these days, you need that. So what can Gulp do? We've talked a little bit about this, but SAS, lint.js, yes, lint, which cleans up your code for you, can cat, Aglify, which makes it really, really small. The JavaScript developer is like really, really small. Live reload, which is going to reload our browser so that we're not, oh, I changed red. Reload. I changed a padding. No, it's just you change a padding and it's going to work over here and just reload it for you. That's such a time saver. It can run Drush tasks. It can clear the cache for you. This is like, wow, Drupal and Culp all work together. And it does any repetitive tasks, browser sync, libraries. It can load libraries. If you don't want to load the library through the Drupal 8 for some reason, you can load libraries. Gulp does all kinds of things. So here's an example of a Gulp file. At the top, we just require the little Gulp tasks that we want. And then we give it some different, and I'm, okay, everybody, what do we give it? We give it, not variables, and this is parameters. Thank you. And then we're going to make a little function that when we type Gulp watch in this case, the first word is the function we're going to say, it's going to run those things for us. Grunt. So I mentioned grunt. Grunt is over. Like, we're not doing grunt anymore. That's so over. That's so three years ago. But you might inherit a project that has grunt on it, and it's almost exactly the same thing. You'll see that the syntax difference using a little bit of a different thing, but it's doing the same thing. You're loading them, and then you're watching, and anybody's a programmer can read these pretty easily and follow along. Ruby and SAS is another way. So Compass, Ruby was another way. You might inherit a project that has that, and so you'll have to install Ruby in order to use their SAS, and then there's a thing for that, for version managing again, called Ruby Version Manager. I mentioned it just because you might run into these things, okay? These are all the different ways that we've done it over the last few years. Gulp pretty much is one now, so if you're starting from scratch, use Gulp, but you might run into these other things. SAS versus less. SAS and less, so who here has done a less project? Has anybody in here done a less project? Who's done a less project in the last six months? Yeah, so it's fewer, okay? So less, again, less has its place, but they're both CSS preprocessors. I've talked a lot about SAS, because SAS really is the direction that we're going. And why do we even use these? And again, this part is for you back-end developers, like, who are like, what is SAS and why? Front-end developers, just five minutes here. We have cleaner code with reusable pieces and variables, which we just didn't have before. It saves us time. It's easier to maintain later on. It's often very annoying for back-end developers because they have to also learn how to use all these task runners and compile things the way that we are doing, okay? So front-end developers have some mercy on your back-end developers, because they don't necessarily see this list the way we do, but suddenly, wow, we can have calculations in logic! It's magic! And we're more organized and easier to set up. So SAS or less, who prefers SAS? Who prefers less? Okay, you're wrong. Unless less is your thing. I seriously, like, I'm totally gonna, but if you're starting a new project now, it's SAS, okay? Please use SAS, okay? Unless less is your thing, and seriously, if it's your thing, it's your thing, and I'm not gonna come check your code. So now we've talked about just task runners. We've just talked about Node.js and NPM and all these little gulp tasks that we can do, but there's also tools just for SAS, right? Like, you don't necessarily have to use gulp to use these tools, although I suggest that you do. And so we have things like Compass, which sort of lets you have more robust CSS. Bourbon, Susie is a, Bourbon and Susie are grids. Breakpoint, which, again, works with your SAS tools to give you reusable breakpoints. Modular Scale is a topography thing, and Tippie is a topography thing, but these are all the things that frontend people, we're starting to use more and more, and this list is gonna be like the grunt, okay? This list changes. I didn't even bother to go through all of this too much. Take a picture, use these right now. They're gonna change in three months what everybody's using because we're going fast on the frontend and we're changing things up and the way things get used changes. Like, I prefer Susie right now, but three months from now it might be something else. So that was the end of the third part, which is kind of your SAS, your NPM, your Node.js, that sort of set of the world. But now we're, those of us who are working on very, very large projects, are starting to talk about how we organize our CSS, okay, our SAS, because this is becoming more and more important. How do I find things? How do I change things? So this is actually where I spend a lot of my time thinking and working right now. And the checklist for this section is how are my twig files set up? Where are my twig files? What's my component file structure? What are some SAS, what SAS structure am I going to use or am I going to combine them or am I gonna use a different one? Are we gonna use Pattern Lab and Atomic Design? That's another one. So are we gonna do JavaScript and decoupled Drupal? Where's my REST API, okay? So this is the kind of the new thing that we're all talking about and I know you friend-enders are just sitting there going, I have my way that I like to do it and I wanna talk about it because this is where the real interesting stuff's going on right now. So twig file structure in Drupal 8, okay? Classy is set up and nicely organized. So thank you Martin for that. Yay! So when you go into Core and you see Classy, this is your theme structure. But as you'll notice, this theme structure is really very Drupal-y, okay? It's a very Drupal theme structure. So if you have to go in and find your twig templates, it's really Drupal-y, right? Field, dataset, form, layout, this is very Drupal-centric. But where we're going on the front end is more of a component file structure, okay? And we're gonna talk about Pattern Lab and Atomic Design in just a second. But sometime twigs files are in components. So we're gonna look at Zen for D8. This is where things are going. Because instead of organizing them by file type, like we had before with the Classy, right, where we have all the content in one and the fields in one and the views in one, that's very Drupal-y, right? That's not a component-based structure. We wanna have components. So what's a component? For example, in Zen, the footer is a component. And you see, this is a very different file structure. In the footer, we have the JSON, the SAS, and the twig all together in one folder. Before, we used to have all the SAS in one folder, all the twig in one folder, all the JavaScript in one folder. They were kind of away from each other. But now we're starting to group things together based on their functionality and their component. Why do this? Because if you need to change something in the footer, you're probably gonna need to change the JavaScript and the twig file and the SAS. It's revolutionary. We can find them all in one place. We don't have to go around and find the three things and their name's something different. Cause naming gets, naming's hard, okay? So this is where things are going. And thank you to Tom who's working on the Zen theme for showing us the way. So within this, okay, so now we know we want things kind of componentized, right? Okay, so that's one idea. But we also just have all these selectors and they're all over the place. And SAS is getting bigger and bigger, so we're trying to get organized. So we have three main types of SAS structures that are predominant today. There are other ones and we're gonna, I would love to hear if you have a new way of doing it. This is, I love talking about this stuff, so. So we have SMACs, which organizes folders and directors generally. We're gonna look at what SMACs is. BEM, block element modifier, which is generally how you name your classes. I say generally because I already showed you a file structure and these have different folder structures. So you might be taking and borrowing from all of these different things and not. Some people are like, all SMACs, SMACs, SMACs. Some people use SMACs and BEMs. Some people use SMACs and BEMs at OS, of object-oriented CSS. So there's, these are three main ways of thinking about it, but you don't have to use just one. So a SMACs example is this. SMACs, as you see, it defines things as like layout, then colors and classes, and it has a very specific naming structure. Block element modifier, a lot of people like this because it's a little bit easier to remember. The block is the nav, the element is the list, or the link, and the modifier is active or not active. So it's a pretty, it's a much more human-readable kind of way to do things. Object-oriented CSS, as you see here, is the idea that we are separating layout and so the first three, like button, box, and widget, all have layouts, widths, heights, and then skin defines the look and the feel of something. So in object-oriented CSS, we get many, many classes that all, that you add many different classes to one element in the DOM to do that. So these are the three big, and I really encourage you to go out and look at, all of these have websites, all of them have different ways of doing things, and you're gonna start seeing these more and more in themes as you go on. There's also a big push right now for Pattern Lab and Atomic Design. Has anybody in here done a Pattern Lab site yet? Okay, we have a couple, yeah. Pattern Lab is, it was worth mentioning on its own because it's an application, I call it application, in quotes, okay, that creates a very nifty style guy, and it's based on Atomic Design. And this, again, like I was saying, removing two component-based things. Here's where we get even more component-based. So in Atomic Design, you start even smaller, so you have things over here like little buttons, and then, which are atoms, and then the buttons all go together to make a bar, which is a molecule, and then the bar goes together to make a full thing, which is an organism, and then it makes kind of a template and then a page. So you're going from this really small thing to this big thing. It's, again, a shift in how we're organizing, how we're thinking, how we're developing, and the front end is no longer your JavaScript's all here, your CSS is all here, we're going more into each little component being something that we can modify on its own. Also, Pattern Lab gives you this style guide, which is pretty awesome if you worked with it. You can set your styles in here, and I'll show you the HTML and the twig in order to have the styles, and everything is clicky clicky and easy for your client, and your client goes, ooh, and you didn't do anything, right? So, well, you had to get Pattern Lab to work with Drupal, which was its own feat, but this is a wow factor, and this is something I think we're going to see coming up more in the front end. We're less on the theme-based, and more on the, we're going to start plugging in our own little applications that help us organize and modify where we're going. So, JavaScript and decoupled Drupal, these live outside of your theme, okay? If you've ever worked with decoupled Drupal, it's important to note this is nowhere in your theme. These are their own things, they have their own file structures. If you're using React, Angular, Ember, does anybody see a pattern here? Ember, do you? Yeah. These, again, I don't go over any one of these. React is the winner right now. I can guarantee you three months from now, there is going to be a completely new decoupled front end awesomeness that we haven't even heard of yet, right? JavaScript developers are just going crazy with this right now. But if you are doing a decoupled theme, these are going to live outside of your theme, like you might put it in a theme folder, but it needs to have its own structure, and this really isn't part of your theme. If you run into a site where you inherit one of these, it's not your theme, it's its own thing, okay? So this is where I quote myself, which is controversial, but this is where I said, we're talking about these things and I get in arguments with other front end developers all the time about them or smacks or pattern lab or, but more important than all of that. More important than which one you choose is that you tell me which one you chose in the readme file, okay? You may not own this theme forever. You may not own this Drupal site forever. If you could just please put in a readme that says, you know, I kind of used BEM, but seriously, I kind of use smacks, and then the client really wanted me to use fruit terms so everything's rutabaga and orange, and that gives your next developer some help, okay? Think about who else is gonna inherit this because I've inherited a lot of crazy things. Other things that you want in your dev environment, if you're gonna take a picture of one, take a picture of this one, Slack, there's a Drupal twig where you can go and talk to people like me and say, why the heck isn't my twig working? It's a Slack channel that anybody can join, okay? Come hang out with us on Slack, all right? I also use Xcode for an iPhone simulator. I cannot tell you how awesome it is. Just it's worth downloading Xcode for an iPhone simulator. You can run all the sauce labs of whatever you want, but being able to go in and poke at it right there while you're developing is great. Browser plugins like Live Reload, yes, you still need Photoshop and Illustrator. Those of you who use open source, they're nice too, but if you can get your boss to pay for Photoshop and Illustrator, get it. Ticketing systems like Jira and Zoho, yes, as a friend and developer, you are gonna need to learn to use those. And then bookmarks. Again, my aliases and my bookmarks are always the things that people are like, you're so fast. So, so cool. So, that's it for setting up a friend in DevOps. Please join us for Contribution Sprints, even if you haven't before. It's really easy to get involved with Drupal. If you would like to comment on this at all, this is, these are the surveys. And so long, thanks for all the fish, you guys. There's a microphone if you wanna ask questions. Hi. Hi. I just wanna commend you. That was actually a really great overview getting in depth of all the different components. Oh, thank you. That kinda laid out a Drupal 8 theme. And I also wanted to invite anybody that wanted to take it maybe a little bit deeper. We were having a bop tomorrow at one o'clock. It's called Drupal Theaning Patterns. Oh, cool. And so please join us just to discuss this kind of topic. It's great. Thank you. Hi. Hello, hi. I'm a back-end developer, long-time back-end developer. But I have some experience with Ferdin. Way back in the day, I was focused on cross-browser design and all that stuff. So, I understand a lot about what you're talking about. Great talk, by the way. My question is, what is your preference for the different CSS structures? What is your preference right now? Oh, I'm definitely, like, if you're gonna do one thing, do components. Start thinking in component structures and pattern lab and atomic design. Not necessarily using pattern lab and atomic design, but start thinking in that way, yeah. What is your opinion on using the Xcode simulator for the iPhone versus using the Safari plugin that allows for you to debug directly in the iPhone? That's a great question. The Xcode simulator simulates a little bit better touch and your touch, your swipes and things like that. The Safari one does a great job for like a first pass, but I have a client who is very, very specific about iPhone products in general and the iPhone simulator is like having an iPhone and whereas the Firefox one is pretty darn close, but there's a difference. Well, no, in Safari you can plug your iPhone into your computer and you can debug. Oh, yeah, go ahead and do that if you have the ability to do that. Yes, yes, the idea, for me, I just, I can't be bothered. So the Xcode is right on my screen. Yeah, an Xcode is right on my screen, thank you. I also don't have an iPhone. Hi, great presentation, thank you very much. So I hope you didn't think you would get away with it, right? Less versus Sass. Oh, I knew it, I knew it, yeah. I am one of those less guys. Yeah. And I would like you to convince me to go to Sass, which I do, but less than less. So could you give me two pros for Sass and two cons for less? Yeah, they're kind of the same thing though. The Sass community is bigger and people are developing tools for it, is the number one reason to go Sass. Less, I think less is equitable to Sass in a lot of ways, but Sass has more tools and more plug-ins because there are more people using it. So I don't, for a smaller site, less is fantastic. I actually really enjoy less, I think it's a good thing, but it's going to continue to fall behind because there aren't the same number of developers making tools for it. So it's not that I think Sass versus less is inherently better, it's just that that's what the community has decided. Yeah. Yeah, I saw that Bootstrap 4 is now moving to Sass. Yeah. They still provide less, but now it's written in Sass, so. Yeah, and they've kind of come to the same conclusion that they can get more developers to help them create things like Sussy and breakpoints and the other things that we want to plug into these, into Sass or into our pre-processor, we don't want to fall behind in the tools that we're developing. And less, you know, they're just, it's kind of like grunt. They were the same, but now people just have chosen Sass. So, yeah. Thank you. Yeah, thank you. Hi. Hello, my question was basically just about when you organize in your Sass files and you say you're using something like Bourbon. Yeah. Some of the companies I've worked with, when they have their Sass files, what they'll do is they'll set up their breakpoints in one file, then their desktop files in one file. Can you talk about what's the better format to organize your breakpoint, to organize your files out in different types or have it like one big file that you would use for all your breakpoints and everything else in it? Does that make sense? Yeah, so when I develop, and this is pretty common now, you put the breakpoints per selector. So you don't put all of your, you don't put all of your, let's say your large, or your desktop CSS together, because when we're developing, again, we're going more towards components, right? So, if you think about what you're doing like, let's say we wanna modify a button, right? We wanna know what that button looks like at every stage. We don't necessarily wanna know what the whole thing looks like at this stage or that stage, where as developers, we really are looking at 90% of the time at a button, right? So that's why you put your break, you make a global breakpoints, you reference those breakpoints per selector. And that, it does add a little bit more CSS. Yeah, and that was the, because that's the thing I was having with my team. I was telling them that I'm kind of new to the team and they're used to doing it a certain way and explain to them to saying, well, look, if you're looking at a button, you have just different buttons in maybe mobile style or maybe in a desktop format. So if you use something like Bourbon where you can just bring in your mobile breakpoints and do it all one there, the file size will be bigger. But even though the file size is bigger, it makes it easier to maintain the code overall. Because now your developers don't have to go back in three or four different files and look for those. All they have to do is look at that one button and it's there. So I just wanted to talk about that. And that's a design pattern that's again, probably like you said, they're used to doing it that way because again, three years ago, we didn't know which way was the best way, right? So they chose one. And I actually have a site that I had to yank some stuff out. Yeah, and I've done that, exactly, yeah. And that's a pain, so I'm super sorry. But... Yes, it is. Yeah, but yeah, that's, you're absolutely right that the direction that we're going now is component-based. And show them pattern lab and atomic design because that's where the community is going. Okay, thank you. Yeah? Yeah. Actually, that's a good segue into my question. So how are you hooking up pattern lab with Drupal? Oh yeah, there's some work that goes into it. I personally, I'm not working on this at my company right now, but we are implementing it for UCSF. It should come out in a couple of months and you can go into that. That will be open source. You can go in and see how they did it, okay? Cool, thank you. Yeah, you're welcome. So I'm wondering, you talk a lot about how fast this is moving. I mean, just the trends and everything. How do you keep track of it? Like how, I'm like, I'm a director. I'm not a front-end developer. I need to know whether my team is going in the right direction or just I wanna keep in touch with the trends. How can I do that? What's the best sources out there? Well, this is again, not popular amongst front-end people, but I'm gonna say it's just a theme. So whatever they are comfortable in and whatever your team has ability in is what you should choose. So I would question them, like is that the best thing really? But ultimately they're gonna decide what they feel comfortable with. You're gonna be faster and more organized because of it. If you start pushing them into adopting something, that here's the nice side. If you push them into adopting something, that something's gonna be gone in three months too, right? So whatever they're comfortable with, and then when you go to redo your site two or three years later, you're gonna start over from scratch anyway. There's something new anyway. Okay, got it, thanks. Hi there. This actually piggybacks off of that question, but an informal poll to the room. If you guys are using a grid system, is it Singularity? Is it Susie? Is it Bourbon? What are you guys using right now? Oh, I forgot about Singularity. Yes, I saw that in there. I'm just assuming, Susie's definitely taking the lead, but Singularity's very popular. I looked at Bourbon. I'm like, oh, I don't think anybody's using it. Oh well, maybe nobody'll notice. I put that on there. So Susie, if you have to choose. Okay, fair enough. But I don't know, ask everybody. I was gonna say, what does the room say, if you guys are? Do you guys have a, who's for Susie? Anybody? I tried to find your slides online. I couldn't, so. Oh, you put it. Okay, yeah. I'll put it back up. Yeah, thank you. You probably spelled Kristin wrong, because it's got a good sign. No, could be based, no, I don't know. I found your site. There you go. Oh, thank you. They're also on the website, on the session in the comments. I put a link to it in the comments. Oh, okay, thank you. Appreciate it. You're welcome.