 All right, I think I'm gonna get started. Can you guys hear me all right? Is this too loud, too quiet? Good, all right, cool. So thank you guys very much for coming to the session. This is my first time at a DrupalCon and also first time in LA and I'm having a blast so far, so good stuff. So I realize that there are some code examples in here and if you guys are having trouble seeing, especially the folks in the back, I have a link up here. It's dc15.jacranus.com, j-a-k-e-r-a-i-n-i-s if you want to follow along. So, quick show of hands. Who here is a back end developer? All right, cool. What about a front end developer? All right, cool. And then who here is not a developer? All right, a couple guys, cool. Everyone's welcome. So we're gonna be talking about a number of cool techniques. It's a little bit more technical, a little bit more of a technical focus but I think it will give everyone a good insight as to some of the struggles and the decisions that we need to be making when we architect large scale Drupal sites. So just quick introduction. My name is Jake Rainis. I'm from Boston, Massachusetts. That's my cat, Beretta. She's a hairless sphinx. And I've been coding since I was in sixth grade. I started dabbling in HTML back when I was bored in my social studies class and I built websites and Angel Fire and GeoCities. If you guys remember those. So yeah, good times, right? So those sure were the days. But fast forward. Currently a senior UI developer and a team manager at Genuine Interactive. We are a full service digital agency digital agency based out of Boston. But we have offices all across the country. We work in all sorts of platforms but of course one of our favorite to work in is Drupal. So through a lot of trial and error we've learned a lot about what it means to write good code for Drupal and some of the struggles that we go through on the front end and that's gonna be largely what I'm talking about today. And as a result it also helps us work harmoniously with the backend which is always important. So I think we all know that the secret to good web development is to write code that doesn't suck but how do we actually do that? Today we're gonna focus on three goals that allow us to do that. The first is gonna be to figure out how we're gonna write our code logically in an organized way that allows us to scale and have portable code. We're gonna wanna figure out how to write our code semantically so it's understandable to our fellow team members as well as ourselves down the line when we need to revisit these sites and figure out what the heck we were doing when we were working on it. And then also we want our code to be dry which is an acronym for don't repeat yourself. We wanna write our code once and we wanna do it efficiently. We want it to be bloat free. So what we'll actually cover before we get into good practices we'll talk about the importance of abstraction, talk about the philosophy of why it's important to break up our code for reuse. And then we'll talk about CSS patterns which will allow us to architect our code in an organized way. We'll explore block element modifier syntax or BEM syntax as some of you guys might know it which is a way to write semantic classes. And then we'll also get into SAS a little bit. And even if you're not super familiar with SAS or if you use less or something this will be a good jump off. So before we get into all the good practices let's talk about life without them really quickly. So let's pretend we're kicking off a massive project and we have that common criteria that we all know and love. So we have an aggressive timeline and a tight budget. We have set very high client expectations and our client's happiness is very important to us in our business so we're gonna need to figure out how to please them. And then there are also a lot of unique templates. Our designs are very high fidelity. Our design team has taken great care to create this experience that we're gonna need to bring to life. And so likewise we're gonna need to take a step back and figure out how we're gonna bring this code to life and do those codes or do those designs justice. And then as usual the team is gonna have various degrees of experience. I will have some developers who are gonna know how to take direction and we'll have some, or they're gonna, you know, they'll need a little bit more direction. We'll also have developers who are going to know how to take the reins. But regardless we're gonna need to figure out how to have our team work effectively together. And the last piece of criteria it's also responsive but I didn't need to tell you that cause all sites are nowadays. So given the current scenario, one of the first problems you might run into if you don't have a plan in place is where do you actually start? I know for our team a lot of our projects start with static templates. So I'm gonna be writing markup. I may say, all right, I'm gonna start on the homepage, you start on the inner page or I'm gonna work on this component, you work on that component. But unfortunately forcing this approach just doesn't work. We're dividing and conquering but dividing and conquering isn't quite enough. And if you divide and conquer without a solid plan in place you're already gonna set yourself up for a big headache. I love that give. So without a plan, team members straight from the get go you're gonna be dividing their responsibilities. They're gonna be working in their own isolated bubble and this is never good, right? Because when they're isolated there's no real sense of organization. If you're not using a partial, if you're not breaking out your code into different files, if you're working in one style sheet you're gonna be screwed. So you should never do that. But developers are gonna be building a piece from top to bottom. So I may be working on one layout, someone's working on another layout. There's gonna be one piece that I'm building that perhaps that other developer could use or vice versa and we're not gonna know about that because we're working separately. We'll be forced to come up with our own naming conventions, our own organizational patterns and it will just quickly become a mess. Worst part, no concept of a bigger picture. The code and the code's authors are isolated. So that's not to say that we can't get to launch that way. We can build a website this way. It has been done. I know that I've done it in the past. You gotta start somewhere. But when you get to launch, unfortunately, that's just not really the end of the project. We all think of it as the end of a project, but it's really just the very first milestone. So websites never really go away. We're stuck with what we wrote. And I'll be surprised if any developer in here doesn't have at least one of those websites that you're stuck with years down the line performing the monotonous maintenance tasks and whatnot. I know we have a lot of those. I think every big company does. And one of the problems that comes up here is when you have a big team and you have new developers coming on, you have new websites launching, you're gonna need, or rather, what is the likelihood that the same developer that built that website is going to be working on that website for its entire life cycle? For us, that's never the case. Our team grows, the amount of websites we do grow. And then the websites that we launch eventually go into a maintenance retainer of sort. So we're gonna need to bring a new developer on at some point. And when a new developer comes on, this is where things get worse, because here's what happens. We have the developer set up and explore the file structure. They have to try to figure things out, figure out what's going on, and this takes time. And unfortunately, time is money. And then once they get the project set up, they're gonna realize that there's no real system or plan in place. So they're gonna start to do it their own way. And as more developers come onto this project and go off of this project, there's gonna be this really clear lack of ownership and responsibility. And that's unfortunate, but it's the reality of things, because when someone is gonna come on to a project for maintenance, they're gonna say, all right, I wanna get in and out of this as quickly as possible. I have a lot to do today, and this is not my project. I'm not responsible for this code. I'm just responsible for this one little piece, this task that I'm gonna do today. And then as new fixes or features get added on, old stuff breaks, it's like a Jenga Tower, spaghetti code, things are strung together, and it really just becomes a mess, and it's no fun for anyone to work on. So at this point of the presentation, I wanted to kind of shift the mood and bring up something a little bit more positive, so I figured this be a good place to drop a quote in, something motivational or maybe a little stereotypical philosophical quote about setting goals. I got on Google and I found this one by this guy named Charles DeLint, who is actually just a Canadian young adult fantasy fiction writer, not super applicable to web development, but it resonated with me. So the role leading to a goal does not separate you from the destination, it is essentially just a part of it. And if you think about that in the context of web development, it actually really is applicable to what we do. Because when we set out to develop something, we generally have an end goal in mind, and this end goal is usually launch. We dream of it being awesome, we think of all the hard things that we need to do to get there, we work hard to get there, and then we can rejoice in our victory, right? But if that hard work isn't good, then we don't actually achieve our goal. We've been short-sighted, we haven't actually thought about what is gonna happen with that website after it launches. So if we're not actually traveling that road to Charles DeLint's destination the right way, then we're actually failing. So we need to figure out how to do it the right way. And that brings us to our first goal. So our code must be logically organized in a way that allows us to scale and reuse. But how do we actually write this code to reuse? So what is reuse? I've said it like 50 times now. What does it mean in web development? To me, it means finding common patterns and reusing them. So I chose the media object as a really prime example of this. And if you guys haven't heard of the media object or are not sure what it is, I promise you that you actually do know what it is. If you're a developer, you've probably coded one. If you're a designer, you've designed one. Or if you've ever logged in and updated a CMS, you've probably authored one. It's essentially just a generic reuse content item. It generally consists of an image with corresponding content. You'll find it in one or two columns. Facebook is actually a really great example of a media object because it really is just a bunch of media objects. So post. This is my post. This is a media object that is gonna appear on your timeline. It's gonna have an image with corresponding text, which in itself actually is a media object. Below that, I have my friends commenting. Those little comment blocks are media objects. They have an image with corresponding text. Below that, I can leave a comment. You can leave a comment. And it's an image with a corresponding action. Top left, that's my picture with a corresponding text. And then if you actually look at a timeline advertisement, this is completely different content. It's being brought to you for a different reason, but it's essentially the exact same markup. It's in an image with corresponding text. It's slightly different, but it's essentially just the same markup being reused. And then on the right side of the timeline where you have all those irrelevant ads from the thing you looked at once on Amazon, this is the ab roller that I looked at once when I went to grab this screenshot to work on my beach body. But again, this is just corresponding text with an image, right? So it's really everywhere. It's certainly not something that's specific to Facebook. And in the Drupal sites that we build, we often find these media objects in views or these blocks that house resource content, or resource content, blog posts, just archives content. And these different media blocks throughout a website can house unique content and they can have different aesthetic treatments, but the HTML can be the same. And if we abstract them to allow for all those different contexts, then we can essentially just write something once and reuse it everywhere, which is a lot more efficient. So that's reusability, but how do we actually architect this code so that we're not just dumping in one place? How are we gonna do it in a way that's still accounting for all the different aesthetic treatments and the variations and the themes? And then how are we also gonna do it in a way that makes sense to our team members? We're gonna use a robust pattern-based system. So in the past five years, there's been a lot of innovation as to how to write CSS for large-scale websites. You might have heard of Nicole Sullivan's Object Oriented CSS or Jonathan Snook's SMACS, just Scalable Modular Architecture for CSS. These are both great methodologies. Today I'm gonna be talking about atomic design and a little bit more depth, but it's certainly not because that it's better than these. These are essentially just the, they're just different ways of getting to the same goal. And so if this is something you're not familiar with then I would definitely recommend checking these methodologies out. But getting into atomic design, which is a system for designing pieces and not pages, we'll talk about a little bit more what that means. But I just wanna talk about the creator real fast. Who here knows who Brad Frost is? All right, cool, good amount. So for those who don't know, real quick, he's a really forward-thinking thought leader in the front-end community. He's contributed tons of rich content. He's currently hosting or presenting that is at an event apart in Boston, back in my hometown right now. But he's influenced, oh no. Sorry about that. I think it's coming back. Ah, sorry guys, I must have hit something. Lost my notes too. Ultimate fail. I'm gonna try not to touch my computer anymore. Searching for inspiration and parallels. I kept coming back to chemistry, the thought that all matter, whether solid, liquid, gas, simple, complex, et cetera, is comprised of atoms, and those atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all the matter in our universe, which is pretty deep. And so this explains the name and outlines some of the patterns that you'd be using in atomic design. Your styles would be broken down into these five parts which you would theoretically organize methodically into SAS partials. So starting from the ground up, these are the very smallest bits, these are atoms, and these are the smallest building blocks that are gonna make up your website. So by themselves, they're not gonna have much context. They're gonna be sprinkled throughout, and they shouldn't have much context because they should be agnostic to their parent components. They're likely gonna, they're gonna comprise of things like the things listed here, not limited to that certainly. But so we have this page design that one of our awesome clients let us use for this demonstration. And we take a look at this design and we say, all right, how are we gonna actually break this apart if we're gonna do it atomically? So the key here is bits. Again, these are the smallest things. We're breaking things down into smaller pieces. We're isolating typography in single elements that can be reused elsewhere regardless of their context. So little things like the logo or the individual links or stylistic treatments. In taking our inner page design, we see a lot of those same bits being reused. So if that context is always gonna change, then we'll wanna code them once and reuse them globally so that they're portable. And then it's also important to write our code in a way that's gonna be agnostic to its parent context or container. And that's really just the key to abstraction. So those are atoms. If you climb up to the next building block, our atoms would form together to form a molecule. And again, a standalone atom by itself isn't super useful, but when you put them together, you actually see how nicely this approach works. So you can take your inputs, your labels, and your buttons and create forms with them. You can put your nav links together, unite it to create a navigation system. So here, we separated those forms, labels, and text input in the top right corner. And now we're able to unite them together into like a global site search that lives in our header. So again, these little pieces are becoming something a little bit more tangible. And then our other inner page example, we have a sub navigation link style. And these navigation link styles can have like an inactive, a hover state, an active state, but we can add context by positioning them together and giving them a background color. And so then again, our atoms will unite to create another example of this different media object. So by now, you're probably starting to see the kind of bigger picture here. An atomic design, we're just putting our smaller building blocks together. So our atoms and molecules will join together to form organisms. And these are gonna represent the bigger regions of your page. So going back to our design, this is where we were with molecules. We're gonna form organisms. We've merged together our molecules into a header and a content organism. And then with our inner page design, we're also doing the same. We have a header, we have a sub nav, we have our content section. So it's worth noting that once you get to this point, you've really actually broken things down enough to be portable and reusable everywhere. So as you probably could have guessed, the groups of organisms will come together to form templates. And templates are the structural layout of your page. You're not actually gonna be writing a ton of code here. This is probably where you'd put something like your grid system or just the styles that are gonna position these regions together to form your actual page design. So then the last piece, pages, which are really similar to templates, but not to be confused, they're meant to be variations of these layouts. So what would your website look like if you were logged in versus logged out? Is your header gonna have different components in it if you're logged in? What does a site search look like if it has 10 pages of results in warrants pagination? What does it look like if it has just two results and doesn't warrant any pagination? And what does it look like if it doesn't have any results at all? So it's worth mocking up these variances to account for unexpected behavior. A lot of times our design team is not gonna think of these more unique scenarios. And sometimes we don't think about them in development either until it really becomes a problem. So it's definitely just worth thinking about these things as early on as possible. And it's also worth noting at this point pattern lab, patternlab.io is the website, which is created by Brad Frost again, who is the creator of atomic design and also a developer named Dave Olson. And patternlab is not meant to be confused as a framework. It's a set of tools that are meant to help you construct your website in an atomic manner. So I actually put together a screencast today because I was not sure if I'd have wifi in here. And this is just a screencast of me clicking through a demo of patternlab. So along the top left navigation, you have your little pieces starting with atoms and working your way up the chain. You can look at these elements just by themselves. You can look at an individual button. You can look at something that has a button in it once it becomes a molecule. And this makes a really, really great living style guide. We've done this for clients before and they really enjoy it. It's kind of a newer tool, but it really helps us think. So again, pages, this is our regular homepage. This is what it would look like with an emergency alert on it. So again, accounting for those variations. It's responsible. It has a small, medium, and large setting. You can also set an explicit setting. And it also has a disco mode, which in real time will make your page dance for you. So you can actually see a breakdown in real time. And you know once you start, especially I'm sure front-end developers can relate, once you actually start making responsive sites, every responsive site you go to, you want to check to see if it's responsive. So if atomic design is something that you're excited about, then I would definitely check out Pattern Lab. Very cool tool. So I really like atomic design. I think it's really cool. I hope you guys have a good understanding of it too. What's nice is that it really encourages good organization that helps with our scalability goal here. And it doesn't impose strict guidelines. It encourages good practices, but you don't actually need to follow these guidelines if you don't want to. At Genuine, we don't like to impose too many guidelines either, but at the same time, again, we have these developers, this big team of developers with different projects. These developers are coming on and off these projects. And so there needs to be some degree of standard so that we're not wasting a lot of time learning how each other code. So atomic design was a really good step in this direction for us, but when we introduced it to the team, a lot of questions came up. Things like, where should I define my variables? Where should I put my mix-ins? Or let's say I want to use a third-party script plugin for a carousel. Where do I put this vendor CSS if it comes with one? And then a question we all asked a lot, including probably mostly myself, is this a molecule or an atom, or is this a nucleus? But the problem is that there is no nucleus in atomic design. The scientific terminology wasn't super intuitive. And though I appreciate the terminology, I was never super fond of the metaphor. I didn't really do that great in chemistry. And so I always found myself double-checking. So it was these frequently asked questions that kind of led us to evolve the way we were using atomic at Genuine. So this is a quick peek into what our common project style structure might look like. So we have our screen.css, which is compiled from screen.scss. Screen.scss is essentially just a bunch of imports for our various partials. And then we have these six folders, which you'll notice are numbered from the very smallest building blocks to the biggest. And you'll also notice that we've done away with the scientific terminology. So our atoms become pieces, molecules become components, and organisms become regions. And then finally you'll also notice that we have these two extra folders, utility and core. And so what these are to us. Utility is where we keep what we call the intangible bits. This is where we would put that, the mix and code or our font declarations, our variables, if we have vendor.css, we'd put that here too. And this is code that you're gonna use, but we call it intangible just because it's there, it's in the background, but you're not spending a lot of time interacting with it. You're just using what it's providing you. And then with core, this is where we keep our raw HTML styles. So if you were to strip all of the classes out of your website, what would it look like? How is the typography treated? We would generally break these aparts into partials as we see fit. Things like forms, lists and tables, will generally warrant their own partial. But there's no rules here. It's just really to style that raw HTML, because we find that if we can get that stuff out of the way early on, we spend less time accounting for different variations down the line. So yeah, that's how we do it. I really love how easy and intuitive it is. It counts for all the different situations that we've been in. It works well for our team. Atomic design may not work well for your team. Perhaps another system does. But the most important thing to keep in mind is that it's not the end-all answer. There's a lot of different ways to do this, to do organization, to scale your website. The most important part is that you just have a system that is gonna work for you. So if you have a system that works for you, then we've accomplished our first goal, which is to organize our code in a way that allows us to scale and reuse. So let's move on to our second goal here and explore how we can use BEM syntax to write code for an unfamiliar developer. So again, BEM syntax, BEM is a acronym for block element modifier. It was created by yandex.com, which is a Russian search engine company. And it's essentially just a method of writing classes that are semantic that makes sense. So this is what those classes would look like. We have a block, and our block is essentially just gonna encapsulate children, child elements. We have an element, which is divided from our block with two underscores. And then we have a modifier, which is divided from a block or an element with two dashes. So by itself here, that doesn't make a whole lot of sense. Let's take a look at a real world example. So here we have a login form. This is just a common login form. Our login class on the form element is our block. We have child elements, we have two labels, two inputs, and a submit button. And when we look at this, we can see that, all right, this class has two underscores in it. So we know that label and input are our child elements of this login block. We can also add a modifier, and we do on line six, where we have login input error. And so let's say we have a gray border around our login inputs, but then we have this front end validation that happens to catch when a user forgets to enter their password and appends this login input error class, and then makes our input have a red border. So we know when we look at this exactly what's going on, we can see that we have an input that's in an error state, we know that it's in an error state because there's two dashes, and then we also know that it belongs to the login block because there's two underscores. You can also modify a block, it doesn't have to be just on an element. So here we've put the entire form into an error state instead of just the input. So we have login error, or login dash dash error on the first page. I'm sorry, first line. So it looks a little bit weird at first, and when I've talked about this methodology with people, the first question they always ask is what's up with all the underscores and dashes? And it definitely, it looks like it kind of convolutes your code, but it really does serve a semantic purpose. First being that there are lots of classes out there that have single dashes and single underscores in them. So we know when we're looking at one with a double underscore, a double dash, that it's a BEM syntax. And we also can see exactly what is going on. That's really the beauty of this. So we can see what state something's in, what it's doing, what it belongs to, what it is. And so I think you'll get used to it. If you really give it a shot, I really hated it at first. I recall using the word DOM vomit when I first saw BEM syntax code. It looked convoluted, but now I kind of see it as something that's really organized. And when you go back from working in BEM syntax to something with a lot of arbitrary classes, you'll definitely appreciate what BEM syntax does for you. So yeah, quick and easy, that's BEM syntax in a nutshell. It's really just a useful convention to write classes that make sense. We've also been using it a lot at Genuine. It's really helped unite our developers to have a standard amongst our projects. So quick show of hands again, who here uses SAS? All right, cool, a good bunch of people. Who here doesn't use SAS? All right, cool, that's fine too. So the ins and outs of SAS are a little bit beyond the scope of this presentation, but it will also serve as a good jump off. For those that don't know what SAS is, it's a CSS preprocessor. And what that means is it's essentially just a way of writing CSS in a slightly different syntax that is gonna compile down to CSS. And while I do that, it's a shorthand. It allows us to write less code. And it also affords us some dynamic leverage, which we'll get into. If you don't use SAS, it's never too late to start. You should definitely give it a shot. It's really awesome. So in the interest of our third goal, which is writing our dry code in an efficient manner, we're gonna talk about the BEM syntax capabilities that SAS actually gives us right out of the box. And then we're gonna talk about how powerful it is, which will involve a lot of the good that it can do, but also some of the pitfalls that you can get into if you're not using SAS in a responsible way. So SAS has built-in BEM support. You don't need SAS to write BEM syntax, but it really makes it easier. If you're doing it in plain CSS, it's gonna require a lot more writing. So the way you write BEM in SAS is by nesting. And we're gonna talk about nesting a little bit more in a minute as a means to define scope. But here we're nesting these selectors in a way that's not gonna create a chaining bloat, which we'll also talk about. Our rule here says our login underscore underscore input class has a border of gray. And then also that ampersand is gonna append the dash dash error. So if we have login input error, it's gonna get a red border. Now that's a little bit different than if we were to do it without BEM syntax. So here we have a rule that is essentially achieving the same goal, but we're actually writing more SAS and it's actually giving us a little bit more output. Because what we're doing is we're saying if we have the login input class, make it gray. If we have a login input that has a child, I'm sorry, it has a sibling class of login input error, then give it a red border. So you'll see down below, we have login input dot login input error. I'm gonna flash back real quick to the previous screen and you'll see that that class is actually shorter. Not a huge deal in this context. We're only really saving a couple of characters, but if you're writing a really large scale website and you have thousands of these all over the place, then you're gonna end up with a much longer style sheet than you need. So one of the best parts of SAS is this ability to nest declarations as a means to define scope, but it's also one of the most dangerous. And if you don't do it carefully, then you can get an exponential output. Your code can multiply in a very unfavorable way. And if you've ever heard the word selector inception, that's what that means. So for example, here's some HTML, pretty standard block of HTML. We have this wrapper, we have some other HTML that's not pictured here. We have this sidebar region that has a user block and then it has our login form from a previous example. Now with SAS, we have the ability to nest to our heart's content, but just because we can, doesn't mean we should. So here we have this nesting that's five layers deep and someone who didn't know any better may say, oh well I'll just have this mirror my HTML and then that way it'll be really easy for the developer who works on this project next to know what's going on. Which may be true in some cases, but it's actually not. If you have a really long style sheet with a bunch of nesting, it's really hard to figure out where you are. But to drive the point home when you actually do that nesting and you compile, this is what it looks like. It starts to look like a pyramid. So with all the nesting, look at how insanely long some of these selectors get and that's not good because we don't need to do that. So it's important to note that SAS efficiency isn't necessarily about how many declarations you have or how long the declarations are. It's just about avoiding exponential output, but exponential output can result in these long declarations. So the key is to check what you compile. I found this absurd block of code in a vendor plugin somewhere. And I thought it was ridiculous. I was going through my compile CSS and I was like, geez, I can accomplish this with one line. And I'm sure that no one ever does this maliciously to just, you know, to bloat your code. No one wants to do that. But the thing is when you're working with a preprocessor, you're never actually working in your compiled code because you're writing code that gets compiled. So it's really important to know your compiler. Go through that code and see if there's any of those inefficiencies in there that you can strip down and simplify because if you're being repetitive, there's always a better way of doing something. So keep that CSS as small as possible. And it's also worth noting that SAS doesn't create bad code. A bad coder does. So it's not a solution to your bad CSS practices. It's really just a powerful tool. It can be a really dangerous tool. And I'm gonna talk about, I did talk about, I'm gonna continue to talk about some of the bad things that SAS can do, but I'm not bad-mouthing SAS. SAS is an incredibly powerful language and it's just really important that you know how to use it the right way. So let's take a look at another way we can kind of use it more efficiently at extends. At extends are a directive that allow your class to piggyback off of other classes or other styles. So here we have this generic error class. We have a login input error class and we're saying we wanna use those exact same styles. What the at extend directive does is it tells our preprocessor to lump this code together into one declaration with a comma delineated list and then outputs those styles once. So another example, let's take a look at a media object. We have this media block. It has a nested H2, a nested paragraph. And then we're having this media alternative class at extend it. Maybe that class is gonna get its own style somewhere down the line. But you know, just another common situation. So when that compiles, as we expect, we get these, we get three blocks. Our preprocessor knows that it's gonna chain these two selectors together and give it the applicable styles. But let's assume that we may have other siblings next to these media objects. Let's say they're stacked on top of each other. And so we add this rule, it's a sibling rule, and it says, all right, for every media object that is next to a media object, give that subsequent media object a margin top of 20 pixels. So again, a pretty common situation. We're just adding margin to let things breathe a little bit. But when we compile that, look what happens. We get this long, ugly declaration. So again, no one ever would have thought that to, no one ever would have done that on purpose. But it's just, it's important to think about when you're mixing at extends and sibling selectors, things can get messy in an unexpected way. And then there's also the confusion of when to use mix-ins versus when you're using placeholders. You could achieve essentially the same thing with both a mix-in and a placeholder, but they actually are very different beasts. So when you're using a mix-in, you're not using at extend. You're using the at and clue directive. And when you use the at and clue directive, you're explicitly duplicating something. You're copying and pasting something. Whereas when you're using a placeholder, you're gonna be using the at extend, which we took a look at is the preprocessor knows that it's gonna create a new declaration from these styles. So let's take a look at an actual example. So here we have a mix-in. We get a lot of designs that will have gradients. And so the developer may think, all right, I'm just gonna create a mix-in so I don't have to write all this background gradient code over and over again. So they create this background gradient mix-in and then they're gonna apply it to styles with the at include background gradient. Now, when this compiles, we get the expected output. Everything works, but you'll notice that this code is just copied and pasted. And so we're repeating ourselves and we don't wanna do that. So we know that there's probably a better way to do this. And that's where a placeholder comes in. So here is the same example that we're trying to accomplish here. We have a background gradient. The syntax is a little bit different. It's prefixed with a percent sign and that tells our preprocessor that this is indeed a placeholder. And then instead of saying at include our mix-in, we're saying at extend percent background gradient, which is extending our placeholder mix-in. And then when this outputs, again our preprocessor knows to take these common styles, create a new block, a new declaration that is gonna chain our selectors together and give them all the same styles. And then it will also leave the unique styles on those classes alone to have their own individual classes. So cool. We've achieved half the output using a placeholder. We know that at includes duplicate and at extends will create this one new rule. So why use a mix-in at all? And the answer to that is because mix-ins can have a dynamic output and this is explicitly what you should use mix-ins for. So we had this background gradient and it was the same background gradient that we were gonna be using all over the place. So we should have used a placeholder. That was the way to do it. But what if we wanted our gradient to have a different output? Say we had a design that had different color gradients that were going in different directions. That's where a mix-in would come in handy. So going back to one more example, this is what a mix-in gradient that had a dynamic quality to it would look like. And you'll see it's starting to look like a function. So it takes arguments. So we have color one, which is what our gradient is gonna start at. We have color two, which is the color that our gradient is gonna grade eight to. And then we have this optional direction as a third argument. We know it's optional because it has a colon prefixed with top. So we know that if we don't pass in a third argument, then it's just gonna default to top. So when we call it below, we're saying at include gradient and then we can pass it, I'm passing it explicit colors here, but you can pass it a hex value too. So this is gonna create a white to red gradient and it's gonna take the direction of top. And then another element is gonna take a completely different set of arguments. And so when we compile our code, we're seeing that we're actually getting this completely different output. Again, that at include is copying and pasting code, but it's not copying and pasting the same code. We're getting completely unique output. So that's what mixins are for. And the rule of thumb is that these mixins should accept dynamic values and they should return a dynamic output based on those arguments that you pass to it. But if you just need to reuse this same code over and over again, then you should use a placeholder. So this was a tough thing for me to grasp initially. Learning CSS itself isn't a super hard thing to do. Learning how to write CSS that is a little bit more large scale and organizing it, that can get difficult. But then when you throw in like a preprocessor that has all these different ways that you can write CSS, it really can become a headache. So just drill the difference into your head if you don't already know the difference between add extending and add including. And that will help you figure out when to use a placeholder or a mixin. And so that's just kind of scratching the surface of SAS. We don't have time to go further, but SAS can do a lot of really, really awesome things. These are some of the more powerful ones that we use on a day to day basis that I wanted to share with you guys. So we've accomplished our goals. We've explored proven systems that help encourage scalability. We won't be banging our heads on our keyboards a couple of years down the line when we need to perform maintenance on that website from hell because there will be an organized system in place. And then we've also learned how to write code that is gonna make sense to our fellow colleagues as well as ourselves down the line if we're gonna have to pick up old code that we wrote once upon a time. And then our code is no longer bloated. We know what our preprocessor is doing. We've scratched the surface of SAS and we've learned a lot about a great starting point for how we can start to architect our styles with SAS. So if you're doing these things or you're planning to do them in the future, you should definitely be really proud of yourself. You're a responsible and methodical front end developer. Buy yourself a beer, pat yourself on the back. And so the front end is hard. It's getting more and more complex by the day. It's been really interesting being here at Drupal talking about headless sites that was something that I had never thought I'd see but the front end's only gonna get harder. And it's important to stay up with these new things on the horizon but it's also even more important never to get too comfortable with what you're using today. But if we demonstrate this good practice, things will be easier as this complex frontier evolves because the web's never gonna be a static place but if we're responsible, then we'll be able to grow with it in a much easier way. So thank you guys. And then also I'd like to thank our awesome clients, MITRE and Interlinks who I believe are also here at DrupalCon. They let us use their websites as a demonstration today. We're very grateful for that. And yeah, thank you guys. I hope you learned something and I'll be happy to answer any questions if anyone has any. Great questions. So we figured there's so many class names, right? Why not just add more and make longer ones? No, but so with Drupal and the classes that it gives you, it's definitely difficult. There isn't a way right now to get Drupal to output classes in this way. The way that we do it in the company that I work for will often take time to strip out a lot of the unnecessary classes or we'll just work with them there. My opinion is that there shouldn't really be a machine doing this for you unless that machine is doing it really right. I think a lot of this requires some planning on the front end team. You wanna be able to do it in a way that makes sense for a large scale project and not just one little portion of a website. So we do that all manually. And then as far as analyzing the compiled code, there aren't any tools that I'm aware of. I don't think there is really the need for tools either. I think a lot of what I do is I scroll through that CSS and I just look for big blocks. Things that visually stick out to you as you're moving through that code because it's generally that's where those giant selector chains are gonna go or a really, really long set of rules. You'll be able to pick it out pretty easily. And if you use Sublime Text, Sublime Text has a little mini map. You can sometimes even see it on the mini map. Other IDEs may have that as well, so yeah. So I would say that it would probably work with our backend team to figure out a way that it was gonna allow us to add classes for wrappers on the front end that was gonna be used in one specific area instead of half-hazardly adding them to somewhere that is gonna be duplicated everywhere. A lot of our views, if a view is doing the same thing in a bunch of different places on the website and it's always looking the same, then we can use those classes. But if it's gonna look different or serve different content than chances are it's gonna have different classes. So that is generally enough for us to target what we need to do to accomplish our goal on the front end. Does that answer the question? No. So you can't assume that you can add classes to them because let's say that you don't have all the right to have that kind of access to the stuff. And so you have to use that are all, maybe they close from the top. And another view is close from the left. And so, So you're stuck with that code. Right, and so the ultimate question is what would you do with these views, see how this file is based on the file structure of the region? Because I can't tell you in a region you have components. I don't know that if it's a component, but then if it's not a component, then you have 100 views, 100 files, a lot of views. So what would you do to put that in the file structure? Gotcha, okay. So in regards to the lack of control to the markup, the BEM syntax is an ideal, or being able to add our own classes is obviously ideal. Where it can't be done, then it just can't be done. I mean, it's not always gonna be a perfect ideal situation. It's a helpful pattern when you can do it. Unfortunately, in a situation like that, you may just be stuck with the markup that you have to work with. As far as where that organization would go into your code, I would say that it would probably either go somewhere between the components in the regions later, like you said, I would prefer to break things down. Like if there was gonna be, let's say we have a view with a couple different media objects in it, not all those styles are gonna live in any one of those folders. We may have typography being handled differently, like a general layout that is gonna space these things apart being handled differently. That may happen in the region section. And then for like a little individual piece of that view that is gonna be repeated, we would probably put that in the components folder. It really differs from design to design, and the way that we're gonna break things up is generally kind of a strategy that is gonna be subjective to every website. Versus the general, how do you approach it through the process? Like is there any tool kind of like the part of it that lets you see that the line of things is not necessarily the one that you can see is just kind of what you do yourself? So you mean like if you're inspecting the website and the browser to see how it goes back to? So there are, there's a tool that you can use with SAS or Compass, which is a mix and library built on top of SAS that allows you to use what you call source maps. And so that is a reference in this compiled CSS that references a map file that will tell your browser when you're inspecting this compiled code that when you inspect a style, that style is then mapping back to whatever partial that is responsible for defining that attribute. It takes a little bit of setup. It's probably not something you would ever do on a website that you're not working on yourself. But and then also just if you're compiling your CSS in a way that is ultra compressed into just one ugly block of code, then obviously that's not usable. But there are also other different formats in which you can compile your SAS too. So you can have one that outputs your CSS and before every line it will say this line is from this file on this line. So you're looking at this compiled CSS but that CSS has a reference back in an actual comment to where that partial is. Sure, thank you. Yeah, please do. Okay, that was a context module you said? To give it that, to get the parent, right? Cool. John, expert, help group who does this. He doesn't have to say the word on what I have. It does have a chance to raise a question.