 Thank you. Thank you. Am I turned on? Oh, that's awkward. I'm not a native English speaker, so bear with me here. So we're going to talk about modular and reusable front-end code with HTML5, SAS, and CoffeeScript. And just as what Jonathan did, I kind of fucked with the title, because you could do this with plain CSS and plain JavaScript. Well, the thing is, I have this Bob Ross thing. I just like the man. So this talk is about Bob Ross. Submitting a talk about Bob Ross does not get you accepted into Ruby conferences. So I just threw in some bus words, and here we are. So we're going to talk about... So I hope you guys are ready. So we're going to talk about the joy of front-end, the journey with Bob Ross, and yours truly. Bob Ross, the hashtag. If you want to tweet during my talk, the official hashtag is Metas Ruby plus Bob Ross. I did this talk at Jeruku in Amsterdam, a little more people. We've got this actually to be a trending topic on Twitter. Hey, let's do it again. For those of you who don't remember Bob Ross, that's Bob. Bob was his white guy sporting an afro, and the only one in history to actually pull that off. He had this show on PBS where he made a painting in 30 minutes. And Bob is the inventor of modular painting. Bob had modules, had a tree, a crooked house, some clouds, and he would combine all those modules to create a new painting. So using this standard set of modules, his own bootstrap basically, he created different paintings. That's what we want to do, right? We want this blank canvas, have a bunch of modules, like bootstrap, but not have it look like bootstrap, and go edit. Just have reusable components. So as developers, we love to start with a blank canvas. You just start a new project, and everything is, like, immaculately clean. This time you're going to do it right. You just do it right the first time. Nothing can go wrong. Yeah, you know what's going to happen, right? So for a few weeks, you'll go at it like Bob Ross riding a unicorn through the sky of rainbows. I'm proving a point here. Everything exists on the internet. I just took a lucky shot, went to Google.com, entered Bob Ross unicorn rainbow. And there it is. So you go at it for a few weeks, and you take a step back, and relax, and look at your code, and you're expecting to see this immaculate Bob Ross painting. But instead, you're greeted by something that looks more like a dead rat, like besides a puddle of cat vomit. And this is an excellent time to grab a drink, and I'll just leave this on for a bit. This is so gross. So what went wrong here? This dog has some front end, or basically revolves around front end, so bear with me. Your head is heading, and you want it to be black. That's all fun and games. They want it to be blue and italic sometimes, when it's in some container with ID main or sidebar. Sure, that works. Oh, wait, for the Twitter widget, you want it to be red. So just add this, and add an importance to make sure it actually turns red because of the specificity. Oh, wait, for tweets in the sidebar, it needs to be green. So you do this, and it works. Oh, except once. You just add this class name to the H1, and wow, that worked. This is how you create code looking like dead rats next to puddles of cat vomit. As Bob would say, oh, you'd be in Agony City by now. No, I'm not making this up. You can go to BobRossQuotes.com. Yes, and there was a lot of Bob wisdom there. A little about me. As Target said, well, he didn't say I'm bolding, but I am. I'm this bolding guy from Amsterdam. I'm a front end architect. I used to be a front end developer, but it basically had the glass ceiling of what he could charge per hour. So I started calling myself architect, and I just kept upping the price. Oh, you know what I'm talking about. Good for you. I'm co-founder of ADB, Ruby Consultancy in Amsterdam, and SliceCrafts. We offer a PSD to a Hamilsass compass and coffee script service as the only ones in the world. I have no idea why our friends in India have not jumped into this yet. Don't tell them. I'm writing a book about this subject, so here's a shameless book plug. You can pre-sign up for it at Reuters.io slash book, but that's enough about me. A web page is a collection of modules. I don't believe in web pages as being a web page. Pages don't exist. You have elements, you want to reuse these modules. They're not tied to a page. It's just a collection of reusable stuff. To illustrate, let's look at our website. You may have heard of those. So let's pass through Herseygate. The gate Bob Ross must have passed so many times when he joined the Air Force at age 18 and moved from Florida to Alaska to Ilson Air Force Base. Yes, it is informative. This is their website, their current website. I'm pretty sure you didn't have a website back then. This is constructed entirely out of tables. So yes, dear American friends, that's where your tax money goes to. Looks awful. Doesn't matter. This is the page. These are the modules. Again, I used Bootstrap before. You want to enroll your own Bootstrap. You want to have these elements. You want to be able to use them any way you want. It's not like you don't want to have an element on your home page. Yank it out, put it somewhere else, and have it not work because it's dependent on some inheritance or whatever. You want to have these truly reusable modules. So there's a few elements to that. First of that, modular HTML5. This is what we used to do in HTML4. We used to have an H1. Then you had a diff, which you gave semantic meaning by adding some ID or a class name. And there you had an H2 because you only wanted to use an H1 once. Had a margin goal with an H3 in there because you just kept going for H1 to H6. That's not reusable. Luckily, we have HTML5 now, which allows us to use multiple H1s, start every sectioning element with a new H1, which makes it actually reusable and adds new elements for a better semantic value. So an aside is an aside instead of a diff with ID aside. You have an article in there and, again, an H1. Things most of you probably know by now, but just going through the basics. So sectioning elements are great, but don't go replace all your diffs. Go to HTML5doctor.com, read about the new sectioning elements that are out there, and use them appropriately. Now, all these sections, as I stated earlier, can start with an H1. That makes them great for reusability because you can have this partial with an article and start with an H1. You can use it anywhere on the page. It doesn't matter. It's a new sectioning element. It can start with an H1. To make these new HTML5 elements work in IE, use Modernizer, which is great anyway, or some HTML5 Chef, and it will work in ancient browsers as well. Are there any SEO experts here? Yeah. Oh, I can't afford you. A few months back at a conference, someone actually raised his hand. Oh, the guy still hates me. So screw SEO experts. SEO experts just always tell me you're using too many H1s. I was like, OK, how many should I use? Well, you're using too many. Well, yeah, OK. So should I use like 1, or 5, or 10, or yes, somewhere around 10? They have no idea what they're talking about. It's bullshit. Google has been pretty vocal about it since 2009 that they don't care about multiple H1s as long as it makes sense and not your entire page is in a single H1. So just do this. At some point, someone will walk up to you with a report made by some SEO expert to tell you you're doing it wrong. What's about to say, be nice, but just tell them to fuck up, basically. Use those H1s because you can do anything you want to do. This is your world. Bob Ross. Look at that. I'll just take some more water while you tweet about this or something. This is awesome. Admit it. So modular CSS. You have your HTML5 now, and it looks like crap. It's black and white. And you need some styling there. So how do I handle modular CSS? First, you need to start with finding a proper designer. A designer who gets, who understands, that you want to reuse these things. So you don't want them to design three different pages. Use elements or modules. They're almost the same, but not exactly. If you want to reuse, you need some uniformity. Now, what I like to do is print out my designs. Just print them all out on paper, put them on a wall, put them on a table. Look at the first one. Look at the second one. Take a Sharpie and cross out any module that's already on the first page. So in the end, you end up with a collection of what's supposed to be unique modules. So yeah, I'm one of those guys that likes killing trees. So it's a double-edged sword there. If you're against killing trees, you can just kill kittens or something. Or you look on your screen. Look on your screen. So determine those common elements and throw out your current code. Recently, I added another slide, because people were like, yeah, I can't throw out my code. I've been working on that for like five years. So yeah, the guy had a point, basically. So at some point, you need to refactor it. If you want to switch from what you're doing right now to a modular approach, start by giving modules a new class name. So you know there are going to be clashes between your current code and your new code. Find similar modules. That makes sense. I give them the same new class name. And request some leeway to normalize. If you work on your own product, that's fine. Sometimes you have to go through committee or to a designer and tell them, well, these two modules on various pages look almost alike. I'll just turn them into one thing, have them look the same everywhere, because that's way easier for maintenance and reusability in the future. Designers won't always like that. Yeah, handle that however you want. Again, as a yo experts, I'll tell them to fuck off. Now, clean code goes in clean files. Make sure that your new code, or even if you're reusing code, pull it out, put it into a new file so you know that in the end, your old files, your old CSS files are completely empty. You can throw them away, and everything that is in these new files is totally clean. So when writing code, I give each module its own scope. I start class names with mod dash, so I know it's a module. But you look at HTML, and you see mod dash somewhere. You know that from that point on, to where that element closes, you know it's a single module. Use generic class names. If you're showing the latest articles somewhere, you don't want to call a module news, because in the future, you may show some old articles there, and the class name doesn't make any sense at all. And use shallow selectors. The biggest issue you can have in writing CSS is a specificity that's too high. So if your selector is too long, it becomes really specific, and it will override other selectors and get into this inheritance nightmare. So what does it look like? In this case, for instance, there is a section which will hold articles. So it has the class name mod dash articles. There's an h1. Yay, h1s. Latest news. And in there, there are articles which just use the HTML5 article element. That's HTML. At the bottom is the CSS. This is SAS. I love SAS. I hate SCSS. The only difference is the syntax. I think it's fuggly to make my eyes bleed, so I use this. What do you think about that, Hanson? I'll just, OK, I like you. Just a little less now. That's it. I'm kidding. No, no, no. So I start each file with, in this case, dot mod dash articles. And the rest of the file is indented. So we know that everything in that file is scoped inside the articles module. So in this case, we give this section a gray background, and the article gets blue text. Pretty straightforward. Sometimes you want to nest modules. You have a module that you use somewhere else in your application, and it needs to look slightly different. In this case, you have an aside. You have those articles in there as well. And you want the whole section to be more narrow. You have a width of 50%. If you do it like this, it's going to cause your headaches. If you just make that selector longer, in this case, use mod dash articles inside the aside. Because if you want to use this somewhere else, you need to add a second selector. You have to replace aside. That goes real bad real soon. So what I like to do is just add a second class name. So the first one describes the module, or the name of the module, and the second class name. It's about the exception. So in this case, you use mod articles. In combination with narrow, you get the same module only at a width of 50%. I like this. I also have generic modules, like buttons. You use them throughout your application. You will use them inside other modules. So for those, I use super shadow selectors to not introduce, well, to use the lowest specificity possible. You don't want to limit them to specific elements. A button clash, you may want to use an actual button. You may want to use it on a link. Anything a user can click on, which has to look like a button. And for variations, again, I use a second class name. So it may look like this. A button has white text, a red background, and there's a variation, which has a blue background. People will now say, you're doing it wrong. Using blue as a class name isn't semantic. That's correct. But if the only difference between the two is the color, that's the best I can do. I've seen people use red as a class name, and red as a class name. I've seen people use submit as a second class name, because it was only different for the submit button. Then later on, they wanted to apply the style somewhere else, and they gave some random button the class name submit. I think that's even worse, because now your non-submit button has the class submit, and that confuses me. So this works for me. Well, this is pretty straightforward, I guess. So you can just use this module, the button module, inside the articles module, for instance. Sometimes you want to extend and override. This button looks the same everywhere, except for in a specific module. In that case, I just do it like this. So I override this specific, this generic module inside a more specific module. Now media queries, if you're not familiar with those, media queries allow you to apply certain styling based on min-width, max-width, min-height, max-height of your browser viewport, so you can change styling for mobile, for instance, or do mobile-first development. They belong to a module, so keep them in the same scope. Now, that's impossible with CSS, but in comes the power of SAS. You can nest the media query inside your module, and SAS will just handle that. So here's a SAS on top. At the bottom, it's resulting CSS. So in your SAS, it's all nice and tidy, tied together. And SAS will handle it for you. Now, identifying modules is hard. People just say, well, I have no modules here. This whole page is a module. Most likely it isn't. It will take some time to get used to defining those modules and assembling them out. So that's the hardest part of this method. If you can do this, you can do anything. Thanks, Bob. Time for more water. Just want to point you at how we use the putty knife here and the fendite ground for the tree. Well, JavaScript, we've had structure, styling, so now it's time for behavior. Modular JS, a JavaScript module, is tied closely to your CSS module. So if I have an articles module in this case, I also have an articles JavaScript module, which both are about the same piece of code. I use class names for styling and IDs for JavaScript and testing exclusively. I never use IDs in my CSS. I never use classes in my JavaScript. So at the bottom is how I would reference this using jQuery. I don't, and I'm going to explain it right now. I think using IDs in CSS is evil. So it's time for some controversy. I have had experiences where someone changed some IDs to fix a test, to fix some JavaScript, and the styling broke because you have excellent testing for your HTML structure, your behavior. But styling is largely untested. If something breaks there by changing an ID and there's just a small icon missing, people tend not to notice. And it's real, real hard to detect that using automated testing. So that's why I use class names for styling and IDs for JavaScript. And I use data attributes to fix the rest. So what I do, in this case, for instance, there's a list of three items. On top is Bob. Bob is Steve's dad, and Linda is Steve's mom. Steve is, obviously in that case, the son of Bob and Linda. And I use a data attribute for anything that's not unique, in this case, gender. Custom data attribute on UNHML5, data-sex equals male or female. Usually, I choose data-gender here, but it didn't fit the line. And I like saying the word sex during talks, hence sex. I'm an idiot, I know. Not about the sex thing, but about doing it like this. I wrote a blog post about this a while ago. And usually, you get, like, between 12 to 15 visitors a day. After the blog post, someone put this on Hacker News, and it spiked to 3,500 visitors on the first day. The guy who told me I was an idiot was being nice. Yeah, it was pretty, I cried, basically. No, he didn't. I had a test case, and they said your test case is wrong. It uses just a tiny bit of HTML. This isn't representative. So just last week, especially for you guys, I created a new test on jsperf.com. That's perfect on F, and not with VE, because that would be weird. So I took the cnn.com source. I added the gender attribute and class names to 751 elements in there. Half of them had male SFLU, half of them female. And I believe that would be a pretty solid test case. cnn.com has a pretty large HTML dorm tree. So that works for me. And I just wanted to count the number of operations per second. So at the bottom are two lines of jQuery I want to run on that HTML. The first one uses class names to find elements, so a combination of the class names gender and male to have a key value pair to find on the meals. And the bottom one uses a data attribute. And the results are pretty OK. I'm OK with a trade-off. Chrome does 970 of these operations per second using class names and just 922 when using the data attributes. That's a 4.9% difference. 2.9, 11.1 on Android, 6.9 on iOS. That's pretty OK to me. Of course, at the bottom, IE9. I also tested it in IE6, 7, and 8. The chart that JS Perth outputted couldn't even display results for IE6 and IE7 because it was so terribly slow. IE obviously is the odd one here. It's slow anyway, and it's even slower when using data attributes. So if you're going to use this on a huge dump tree, and 111 operation per second isn't enough, you may not want to use this. But then again, I think this works. To me, it's worth a trade-off. 111 operation per second is still a lot if you take an account that it has to do this calculation on a huge data set. The URL on top is URL for the test case. If you want to run it on your own computer, please do. The more results you get, the better. If you do it like this, people might look at you a bit funny. But that's OK. I'm used to it, and you'll get used to it too. Now, we have structure, styling, and behavior. But the code needs to go somewhere. It needs to be in a file structure that actually encourages reusability. So what I do, I use one SAS file per module. I use a single CoffeeScript file per module. I use one Partial per module or not. That would be totally awesome. But then you get in, I'm talking Rails here, you get I.O. and things like that to care about. So I usually only create separate files for SAS and CoffeeScript. And one thing that people always run into, this progress isn't always right. I'll get back to that later. So my file structure may look like this. There's an application that CSS that SAS which imports all the rest. There are base styles for the grid reset, whatever. There's generic styling for text, forms, buttons, things that are reused in other modules. And there's the rest of those modules. Some application that CSS that SAS may look like this. It will first import Compass and a Compass reset, which I like to reset my things. It imports everything in base and generic and modules. Using it, doing it in this order, I'm sure that all my base files are loaded first, then generic and the modules. The order within them doesn't matter, but modules will build upon generic modules, so hence this order. JavaScript basically the same. There's buttons, JavaScript file in this case, an article JavaScript file, an application.js, and this uses Sprockets to require all those files. I don't use Sprockets for SAS because I want to be able to reuse a variable. I set in my variable to CSS.SAS. I want to reuse that in some other module. If we use Sprockets, that's not going to work and using SAS they can all access each other. So if you do it like this, your code looks like that. Well, as Bob used to say, the little clock on the wall says we're just about out of time, but I do think we have a few minutes for questions or remarks, so people want to tell me I'm doing it wrong. So bring it. Yeah. Yeah, so the question is, we have all this stuff organizing your files, but how do you keep track of what's already been built so developer has a style guide to work with basically. I haven't seen anything that's real good out there. I'm currently starting to work on something that will ideally put all those modules or the HTML for them on a single page, write code that runs through the CSS, renders that page, takes screenshots of each module and documents that in some PDF or whatever. I don't know anything that's out there right now, but there will be. I'm working on something that will dynamically create a style guide if you adhere to certain standards for this module structure. Anyone else? All of you. All of you, Bob. And no French fries, but Dutch fries, obviously. If that's all, I've got awesome Bob Roth stickers. If you want one, find me in one of the breaks or at the tasting. Sure. Thanks for listening. Jim, Jen, congratulations on your anniversary. Thank you. Michael, congratulations on your 25th birthday. Yeah, so you don't have to applaud him. Thank you. All right, thank you.