 presentation so I'm just going to get rolling into it. I'm going to be speaking about the state of front-end architecture in the year 2015 and start talking about some of the trends and tools and workflows. At a very high level just introduce a number of these concepts. My name is Aiden Foster. I'm a front-end architect and my company is Foster Interactive. We're a web development shop that works with, actually with other web development shops of fair amounts, small and medium enterprise, different kinds of businesses where we help implement websites that have fairly, you know, websites that need to be built that need to be maintained and taken care of in the long run. So we need a sustainable manageable website that works in all kinds of platforms. I'm the vice president of the Toronto Drupal user group which organizes the Toronto monthly meetups and help organize this conference. We're the website sponsors so we put together the Drupal North org website and I also run and founded a meetup for SAS which is the CSS pre-processing language. So again a meetup that meets up every month or two to talk about SAS. So I've got a quote from Carl Sagan. You have to know the past to understand the present. I kind of love the 80s ridiculous turtleneck image and really that's important to understand that what we do with our front-end architecture now is a direct result of sort of the history of what's been happening in web design. So we kind of start in the pre-mobile era back when we used computers and the internet was attached to a cable that was attached to a piece of furniture and that was our experience. I used to remember people's phone numbers. I used to have to print or write down directions before we went to certain places and that's sort of the history of where we started when mobile sort of kicked in. But now we move into 2007 and it called us the early mobile age and that clearly began with the iPhone 1 when it came out 320 by 480 screen. The iPhone is significant not because it was the first web-enabled browser but it was the first one that could deal with desktop oriented websites really well on a small screen. So this really began that era of the mobile web. In 2008 then Android came out in the G1 in North America was released as the HTC Dream. In 2010 the iPad 1 came out followed quickly by the iPhone 4 which is significant because it's the first ultra resolution screen device that at least I was aware of followed by the Samsung Note 1 which began this trend in phablets and like you know when that came out my buddy at a Samsung I was like that's a crazy you know that's a crazy device why do you want a phone like that turns out pretty much all phones are like that now so it's really difficult to predict how these trends are going to go and then we move into 2012 Windows 8 came out along with the Windows Microsoft Surface and all these crazy laptops with touchscreen different sizes all over the place that was followed in the same year in 2012 by the Xbox getting a software update which gave it a web browser around the same time all kinds of TVs and smart TVs and all that started becoming really popular and then we move into 2013 Google Glass came out one day after it came out the term glass hole was released upon the internet and so and then we move into 2014 Android Wear so you get a fan you know you get your smart enabled watch which for some crazy reason has a web browser app you can install so yes you can use a one-inch web browser screen on your wrist but maybe just like the phablets maybe that has some use I just not aware of yet in a few years I'll have a web browser on my watch 2015 Google Glass is abandoned by Google but they promised something new will come out so it's a form factor that at least I want to think about and then Apple Watch came out which doesn't have a web browser on it yet but you need to attack it so really what we're looking at here is that we now face in this landscape of all these devices a number of challenges that our pre-mobile ancestors did not face device formats is a challenge we've got to deal with screen sizes display densities user interface inputs and a wide range of of html support on those devices we need to worry about performance so first of all these signals are coming potentially over randomish crappy Wi-Fi networks or 3g networks that kind of thing and then there's a second sort of big challenge that comes with with performance which is figuring out the problem of how do we get a big high quality picture on a high quality device and a small optimized picture on a small screen device this also introduces the problem of testing right so we need to figure out you know we need to decide how many devices we intend on supporting and then we need to install all the browsers that those devices themselves support and then we need to figure out how many screens we're going to worry about so all the screen sizes we end up with this incredible complexity and diversity of the number of vices we need to address planning and design is really hard so you know we got to figure out how to take all the content from our website and cram it into a little phone and we need to think about new design processes that that have evolved in this case and as a result of all of these other problems we now have way more complex code we need like way more lines of front-end code to render a website because it needs to deal with more cases and be more flexible so let's take a look back at what the solutions were in the past as soon as the iPhone came out dedicated mobile websites came out and they were called the iPhone version of your website in 2008 when the Android was released the first thing it did was it said it lied to the user agent which is how detected you had an iPhone and set you to the the iPhone version of the website and so it lied about its user agent so that when you bought an Android you would still get that that iPhone version of the website in 2010 the retina version of the iPhone came out and it also lied about its screen size because it's got this nice high resolution display but you wouldn't want this crappy little thin stripe of a website on your on your retina iPhone so it lied about its resolution and then the iPad one came out and we were doing all the signature detecting and I don't know initially when it came out I'd load up websites on the iPhone and it would load up the sorry on my first iPad it would load up the iPhone version of it so it be this thin little website on your nice tall screen so that's an example of user agent detection gone bad that problem was fixed pretty quickly 2011 all these phablets come out right and they're just all lying about their screen sizes and resolutions some of them are pretending to be iPhone some of them aren't and so this is this to deal with this problem this system w o w r u r f l is this database that is like a master list of every mobile device that's ever been released times the number of browsers they could support and all the rest of that and they compiled this database and then it outlines all the capabilities of every possible device in there so kind of reminds me like who else has a list of all the children in the world's who what they're capable of so this is it's basically like it's like Santa Claus and it's got this big long list of every device that exists and some are naughty and some are nice and so really it also doesn't help when all the devices kind of pretend to be other devices as well so the use of dedicated mobile in 2008 actually was a pretty good solution you know there's three phone formats we need to worry about plus desktop performance well on the mobile one we give it 320 pixel wide picture so it loads pretty quick testing it by the four things and test it planning and design well okay it's double right so you design the desktop and then you design the phone version and then code complexity well it's exactly double right you've got two websites to build and maintain not so much in 2015 right we got all this stuff to build and there's no way you're building a TV a phone a phablet a tablet a small tablet you know and everything in between so it's really just not practical anymore as an approach so I'll call this the early mobile dark ages of dedicated mobile which takes us out to 2011 and then in 2011 the miracle of the Boston Globe was released upon us so this is the first big commercially viable responsive website that came out it was mission critical to their business it was high volume subscription based website and it even came with its own guidebook on how to implement it so Ethan Mercott's responsive design so this is really the beginning of a new change and how we approach front-end development and it really really ushers in what I'm calling I guess the responsive mobile era so following up into that the year 2013 was declared the year of responsive design by Mashable in 2014 it's an interesting development the aoda ontarians with disabilities act kicked in for websites for any company with fifth or any organization with 50 or more people in it and you now need to comply with the wcga to level a standards for accessibility at the beginning of 2014 and it just happens to be that using a mobile first responsive website approach it's much much more conducive for making a good accessible website than it is to fragment across your websites across a number of platforms later in 2014 Shopify reported that 50 percent of all their traffic was on mobile devices and then in 2016 Google mobile get-in right Google changed their algorithm so that if you search Google on your mobile phone it basically filters out any websites that don't work well on mobile phones so by 2015 we have to support mobile there's really two competing strategies dedicated mobile and responsive dedicated mobile is no longer practical so we are now clearly in the responsive era so now we look at responsive design you when it first came out in the year 2012 and we're faced with all the same problems but it really solves only one right it only solved the display format problem because we still have the issue especially with like classic responsive design where we send a high resolution picture to all the different variations of the screen and it squishes and it flows and it fits but it's still a performance issue because you don't want that high res image on your small screen testing is still a nightmare we've got a million devices and how exactly we're going to test them all planning and design it's even worse than the times two case because now we have to come up with like basically entire new methods of thinking about how we design stuff and the code is super complex and there's no simple shortcuts we can use to make that easier so i'm going to talk a little about how some of these solutions have have evolved that aren't responsive design and this is really what we're building in our in our front-end sort of development stack to improve this before i go into too much detail on that i'm just going to talk a little bit about performance and so why performance is important this is from google's breaking the thousand millisecond time-to-glass mobile barrier and so what this is is they've done an analysis of user race analysis and how people perceive websites based off of how quickly they load so if you load a website and it takes 0.01 seconds to load your perception is that it occurs instantly if it takes one second to load the people's experiences they are freely moving around the website if it takes four seconds to load we're now at the threshold where you press you press a button four seconds later your mind will start to begin to wander and that takes 10 seconds we're basically unable to focus on the task so if you if you if you make if your website you click it and it takes 10 seconds for that next page to load people tend to basically forget what they were looking for and you've got a very very high chance of just closing it off you know check your email go do something else because you're probably going to forget what you're doing or go and use a different website so we need to make sure that our websites while many people would argue you know and google's arguing you should be at one second for it to load time we there's a general consensus that four seconds is a pretty critical threshold that we should all remain under while the importance of how fast websites work has become more obvious based off of things like google's analysis we look at the look at the data of what's happened and so this is from when the boston globe came out till last year and this is the average page load size for a website when they're loaded and we can see that it's gone from roughly one megabyte to roughly two megabytes over this period of time so while it's become obvious that it needs to be super it's super obvious that it needs to be a very fast website the size of it has doubled and the speed of our internet has certainly not doubled in that period of time so what's actually happening is is websites are becoming slower even though we know it's important for them to be quick so what are some of the strategies that have evolved to do this and the first i'm going to talk about is the use of a performance budget so this isn't code this isn't this isn't anything other than a workflow process really and it starts off with at the beginning of a project where you're going to do some measurements and you're going to compare you should you should do some load test times on your competitors websites just to get a baseline and see where folks are at then your team collectively that means designers stakeholders developers business managers everyone needs to get on board with this concept and pick a target and you're saying we're drawing a line in sand if all your competitors take 10 seconds to load you're laughing right because if you get to four seconds then people are going to leave their website and come over to yours because they're because the experience is so bad so you pick a target and it's going to be four seconds or less i actually tend to pick four seconds because it's pretty hard to get websites down to four seconds sometimes so then we go through development and cycles of testing and so as you build and iterate on prototypes of your website you remember to test it and it's part of your release cycle and your release management to build and test build and test and if you increase if your test show you are greater than your target you have to redesign something before you push that stuff into code and so that could be redesigned as in you know a common thing is we've got a big masthead on the homepage marketing says uh that's got to be a slideshow so that we can present four of our business sectors instead of one and so you load those in and if that all loads on the page load you're finding a long slow load time you know that's a that's a debate of either maybe there's a code solution so you load one graphic and then lazy load the less the rest secretly behind the scenes or maybe it's a design problem we say actually no we're not gonna we're not gonna put in that feature and then once they pass the test it's time to deploy a couple other tools have come out to help with performance so the automated testing tools so webpagespeedtest.org is one of them and so this is a tool that i would be using for that testing phase where you can just put your site up on a server and it goes and it pings it from a number of different locations on different browsers different platforms and it creates an average of that so you can see where you're at you know 2.25 seconds okay cool we're under our four second limit another very useful tool is the the page speed insights from google and this is just like so i just fired in Drupal North into there and you know there's we've got a 64 percent score because there's all kinds of other optimizations that are possible um it reports sort of false uh false reports sometimes but it's still a very good tool and a quick and easy way to make a checklist to make sure that you didn't accidentally do something that that you can really just improve very easily another of the developments that has been very helpful in the front end world for improving performance relates to images and so one of the main problems is we've got all these different screen sizes and they have different display densities so what is ever since sort of ie8 dropped off the board it's been feasible to use scale scalar vector graphics in your website and so scale vector graphics basically it's just a it's a different format of file that's really good for icons and logos it's not like it's it's not good for like photographic looking things but for for more graphic designary kind of components and what's good about them is they will scale to any resolution and render very clearly at all different sizes and shapes so Drupal 8 has um has scalar vector graphic support sort of built into it they kind of expect you to upload your logo in scalar vector graphic um but the other thing that scalar vector graphic gives us that nothing else does that's really cool is one major optimization advantage is that you can control the color of the graphics that show up in your website with your css code and so what that allows us to do is you know in the past say we have a button with an icon and you hover over the button and the icon color changes you stuff to upload two pictures one of each color of that graphic now we can upload a single svg and it can make these two derivative variants of it simply with css code so that's a that's a significant optimization and it's convenient too right like say you change the color palette a little bit in your website halfway through it you're just controlling that with your css which is awesome the next thing that's really cool and definitely unique about svgs is responsive artwork so this is an example of a logo where if you've got like a large amount of space on your screen it shows up this highly detailed version of the logo and as our responsive website squishes in size so say on the mobile version of that different qualities of the artwork different amounts of information are presented so when it's large it's detailed when it's small it's a very simple uh a simple symbol and none of the wordmark stuff appears which is pretty neat this is in my opinion better than um an alternative approach which is to convert all your symbols into icons because you can do multiple color uh multiple color artwork with svg and you can't do that with icons and you simply do not have this this option with typography to the best of my knowledge another major element so again the the the biggest performance problem has always been pictures how do we get the big picture on the big screen and small picture on the small screen uh the responsive images community group was formed in 2012 it is a bunch of clever folks who are both on the vendor browser side of things uh clever developers and and and sort of stakeholders who are trying to figure out how to make images work well on mobile websites and they came up with this new html element called picture and what the picture is is it's a new tag and basically you load you you make like six derivative images let's say hypothetically of a single picture you upload them to your server and then it just by using this tag in its simplest format just knows which image to load for your screen so that's that's amazing it's supported in chrome now sorry and this format came out in 2012 2014 so it took him two years to sort out and debate this issue and now browsers so firefox and chrome both support it the other browsers it fails gracefully so it turns back into a plain old regular image with a small javascript shim you can actually get it to work on pretty much all the modern browsers so this is an awesome format and it deals with a second problem that wasn't even really really addressed in in the and simply by getting the small picture on the small screen you can see this image of the dog here on the desktop and he's in front of like the white house or something there i'm not really sure but um and then we see the dog on the small display and it let's just assume for for for the purpose of this uh demo that the subject matter of this image we want to emphasize is the dog and not that he's in front of the white house if you just scaled this image down to 320 pixels wide that dog would be tiny and basically invisible to see so we can do art direction where we crop different shapes and sizes of images to put different emphasis on that component so that we can art direct this image so in the context of say there's a blog post about a dog or whatever uh you would see the dog up and close on the small phone but on a desktop experience you get a nice big uh you'd still understand the context of that situation what is also really cool is Drupal 8 comes with responsive image and picture support out of the box by default so now this is relatively simple to do uh right in yeah right right out of the box which is great because we do a lot of work to get this going right in Drupal 7 okay so i'm going to switch over to kind of cody stuff a little bit just to talk about what's been necessary uh to help us build our websites uh we're building them with sass which is a css preprocessor uh basically css as a language was always written to be super easy to read and because of that it's missing many of the cool functions that i would expect from every other programming language in existence and so sass gives us uh basic math functions and and sort of things that we kind of depend on in other languages and you know the complexity of the requirements of css dramatically increased over time but the language itself did not really evolve all that much but really the main thing that i just want to point out about sass that allows us to do things better is we can break up our like crazy gigantic chunks of code into small bite-sized pieces and in sass that's called a partial and so our coders can like work on and multiple people can work on one project at once and i can work on this thing and then someone else can work on that thing at the same time and then basically because all that gets compiled out into sort of machine friendly styles it's been very efficient for helping us work collaboratively on large more complex front-end developments i'm going to change gears back into what's happening in design and so early on in 2012 possibly even a little earlier the concept of using style tiles as a design deliverable early in the project was pioneered by samantha warren and so what this is is you've got four four example style tiles here and this is not user interface design this is simply a sketch to present a feeling and emotion it's a tool to talk about color and style and and these designery kind of components completely independently of user interface design and so this idea of of of separating out user interface from the feeling sort of evolved in this idea we kind of ran with it in the design circles as as as the process of figuring out how to design responsive websites evolved so it became kind of clear that that that component of how we design websites is we're no longer designing like a page anymore it's not like a page in a book because there's all these different flexible flowy screen sizes we're more like designing a system of design to talk about how the various components and brand elements and user interface components all work together as a greater whole and then then by by thinking about it in this way we can we can keep it more consistent across our devices and so the best technology that existed before this is a brand style guide so like brand books for big brands it says how to use the logo how to use fonts how to do banners those kinds of things so it's it's we're now the design has kind of shifted from being more less like page design and more like building a brand guide and so early on in early on in responsive era as well component-based designs kind of manifest themselves as these kitchen sink frameworks so twitter bootstrap and zerb foundation both give you these awesome packages of things where you can download a million widgets and components and then use them in your website really easily i'm not a huge fan of them because one consequence of that especially early on was you get these huge slow payloads because you're loading all this code for buttons that you actually never use in your website and the second thing is they all they kind of tend to look a little like each other the performance issue has been mitigated to a degree since the early days because they they switch these projects so that they use sass so that you can include only the pieces you you need but the still that same principle of like you you're making a ton of assumptions about how the design is going to be implemented your website when you download one of these frameworks so that kind of evolved into another another idea which is the idea of making a roll your own bootstrap and this was kind of so basically for your website you custom build out a custom version of it just for yourself and that was pioneered by what is now manifested as pattern lab by brad frost and this is the concept of atomic design and it's really an interesting it's an interesting way of thinking about how the relationship of user interface elements should be working in design so he talks about atoms and those that might be like a text input field and then atoms built up it so say it's a text input field and a button and then we've got molecules where we start taking atoms and put them together so you could imagine an input field next to a button with a magnifying glass icon on it is now kind of a search input and then we take that search input and say put it next to a navigation bar and now we've got the header for our website so that's an organism and then you might have the header for your website and the footer for your website coming together and that becomes a template of which those templates are manifested across your pages so i don't use these this pattern specifically but we do something analogous and i think even if you're being introduced to sort of component-based design it's very useful to take a look at pattern lab and see how they break things down because it's well thought out and interesting and i guess so from a coder's point of view this is awesome right it sort of defines how we break up break up and divide all of our our different design components but designers i found they have a really hard time with this because if you ask a designer like okay design the text field and then design the button and then put the two elements together after designers don't like designing little bits and putting them together they want to sort of get a feel for it as a whole so we kind of merge the two ideas and this is what's part of our workflow so when we get a comp so this is a website we just launched a couple days ago um and but we received a comp of this website early on and so we basically identified the chunks of it that are the components so we've got the main menu component the mass head component and the actions component and we call it actions it's just our internal naming convention because we're trying to get people to do something right like click on this and go and buy stuff or maybe it prompts you to call or whatever so those are the those those are the separate components that we we've identified in this particular layout they're actually more but you know whatever and now let me spin back to our cso to the advantage of sass hat sass allows us to break up our files into individual pieces so what we have actually done is now taking our user interface component and the file the the actual code that controls how that thing appears is in one file and each each component gets its own separate file so what we're kind of doing is we're taking how we think about design components and how we structure our code and sort of using both analogies to to mirror each other which allows coders and developers to kind of collaborate in a more effective way another side effect of using this kind of structure with these components that are in separate partials on their own is that it's very efficient for reusing a piece so we're using an action in a different place of the website so we've got this on the homepage we could use it somewhere else in a very efficient and simple way so this idea right this is an evolution of how things are how things are changing in our front end workflow experience but we've got another advantage we can do so we've got our sass partials that that generate our our our site's website but we actually now use a separate program called hologram there's a presentation coming up tomorrow on kss which is an alternative way of generating style guides so really literally from the same files we put some text comments in the top and those text comments define what the html of the components are are are defined as and we generate two outputs from the same source files one is our live website the second is a full style guide website that's generated from the same code it works in html we we can test it on our individual browsers our individual components uh you know give it to our clients to approve what these pieces look like while we are building things so we can debate about font rendering and that kind of stuff in a context that's real and relevant to the project rather than by debating about why the font doesn't look like the photoshop comp after the fact so this is an example from the the intercare website i was showing before on the right here here's the nav for our finished or evolving style guide right as you work through the project it started with like two or three things at the beginning and as we work through it we started adding more and more components as more and more pieces of the website get mapped out and it's responsive right so i just stretched the browser in this example and you can see how an action component on the mobile phone and maybe this is a smallish tablet kind of size the layout actually changes so this is a really useful tool to show how variations work on real devices and in addition to that we we started expanding out these components as well so they have variations in design of these particular components so we've got our vertical oriented action component which looks pretty much the same at larger sizes regardless of the component but there's a horizontal variant when it gets small the image goes to the left if you see on the preview example when it's small the image stays stacked so these are just variations of the component and it's very efficient to do this because we have this manifest of all the pieces in our toolbox our own custom bootstrap so to speak that we can we we have automatically documented from our project and sometimes we're coding and we work on this first and it because it's easier to map out and plan this stuff out in the style guide itself and sometimes it's easier to do the code in Drupal first and then we just sort of export the html and copy it over into our into our style guide examples so we take this idea yet another step further so we take this output the automated style guide that comes out of our website and we do what's called automated visual regression testing so this is another tool that we add into the mix and what it does is it runs a test and the test already what it what it what it will do is you tell it to look at in our case we test our style guides we tell it to look at that action component and what it does is it takes a couple screen grabs of the action component at a couple different browser widths and it saves them so let's pretend I ran this test in the past and I run this test you know net right now so it goes and it takes all these screen grabs of the of the new of the website when I run the test it compares them to the ones that has saved in its like backlog of screenshots and these two images are exactly the same so reports and it says yes this test has passed if we were working on the action component and say we changed something right so we changed the font size of something so let's say this was our pre-saved component and notice that the title has gone all caps there and we run the test again it's gonna it's gonna detect a difference and it's gonna you can see it actually shows you so it shows you that this pink stuff is what's different between the two layouts of the website and it identifies this so this would be a test that fails so as we work through our project one of the things we can do is like as we build components out we build automated CSS visual regression tests on them so that it will before before we we we can easily compare to see if I'm working on the action component and I'm changing a bunch of things and I press save I'll run the tests and make sure that there's one fail on action component but if some other component somewhere else say I changed the title on this and it accidentally changed you know it's supposed to only change it on the home page and it changes it somewhere else a different test will trigger and I'll see there's two fail tests or maybe even more so this is a good sanity check to help reduce the testing requirements because it's so many devices so many different things that we need to test on that anything we could do to automate some of that and it's really tricky to catch CSS regression errors sometimes because it could be like it never shows up until you rotate your phone right and so this kind of thing is a is an amazing tool for assisting with that and speaking of testing so this is the craziest setup I have used so far there are tools called browser sync there's another one called ghost lab but browser sync is open source that's the one I like to use and basically what it is is you plug into your main development computer and then you get all these other devices on the wi-fi and you probably want to run them off of cables because you're going to drain the batteries of everything really quick and you spin up the the browser sync server or the run the ghost lab app and as I'm saving and working on my code and browsing around on the sort of controller computer all these devices follow along so as I scroll up and down through them they all scroll up and down as I browse pages they all browse around so at least for manual testing which still needs to be done the automated stuff only helps catch some errors you've got you know a billion screens going and you can at least sort of see everything simultaneously you see over here I'm running windows 8 in a vm you know and a couple different browsers all at once so this is a bit this is the most of it I tried to see how many you could connect before it would start of it flood the network and this this worked pretty well uh realistically though while I'm coding I will have two you know like a phone and a tablet of different os's and formats while I'm working and literally as I save it refreshes the main screen I'm looking at and it refreshes these two devices so that at least you can catch more problems literally while you're working and you get a better like idea of what you're actually coding and it's delivered more in the platforms that it's actually going to be received in so one of the other things that is part of this larger puzzle that is important to take into consideration is how your team names their css in the past we just like do random stuff and name it like front page you know promo thing and that is makes it really tricky to maintain your projects over time because what we're trying to do is make these separate components the second components are both user interface components and their files so there's a number of different competing uh almost language like you know patterns for how you should name your css one is object-oriented css one is smacks one is bem um it in my opinion it doesn't really matter which one you pick so much so long as you get your entire team to sign up for one and sort of commit to it and actually there are now drupal coding standards for how css should be designed so given uh I would say if you're not using any the automatic default is to take a look at the drupal coding standards which are an interesting combination of both bem and smacks um definitely and so modules even contrib modules are now expected to generate their css to these standards but drupal's had coding standards for a long time but this is a relatively new thing that we've got coding standards for css and I add a tool into the mix to enforce my coding standards so this tool is called scss lint and what it does is it's like a strict parent that makes sure that I format my css exactly according to the rules one space too many no that's not good enough too many you know even the naming conventions whether it matches the bem standard or not it can detect this and what's great is that you can completely configure what the rules are right so if you take you know it's more it's more about like collaboration and team uh team oriented development on the front end these days and so if everyone on your team spaces the css components or the sass components exactly the same puts the selectors in exactly the same order so our our linter is that annoying that it's like no you got to put the display stuff first and then the color stuff and then the typography stuff it's kind of like it's kind of annoying and makes me cry a lot because I have to like do all the syntax stuff because it's technically valid right it will render and work no matter what but if our entire team does it exactly the same way and it's consistent across the project and this standard might slowly evolve but it's pretty pretty consistent over time it is so much faster to understand and pick up someone else's code or god forbid your own code from a year ago when you have a linter nagging at you constantly about what is right and not right about your code and if you're in a rush for a hot fix who cares push it up if the linter fails and go and fix it later so it doesn't stop you from getting your work done and so the output of this would look something like this uh you know you're supposed to put a zero on the front of point seven five or you know there's one or two spaces that should be added into the mix so i've got this crazy set of tools right it's like this huge selection of stuff that has been added into our front end development workflow in essence to write css which we used to write with a text editor by hand but to assist all of those problems that have been coming up so what do we do about it we automate all the things and so how do we do that there are two competing major platforms one is called gulp js the other is called grunt js these are systems you install on your local machine and they're task managers and so what these can do is talk to all the other tools that i've been outlining um they're both grunt js is a little bit older so it's kind of got a more mature set of tools that have evolved for it gulp js is newer so it's actually more modern performant and customizable so i we we used to use grunt js and now we switched to gulp js but they're both great tools and so this task automation example is for when i'm coding so i spin up i run this task watcher and what happens is the computer sits there and waits until i press save on some file and as soon as i press save sas fires up and compiles the css then it fires up and compiles the html and the css for the style guide then it takes all my connected browsers and refreshes them and then it sends it over to the lint nagger and reports on all the syntax errors that i'm that i'm working on so basically you know press save does all these actions automatically every time i press save if i've got a syntax error it is so much easier to catch them while you write them than it is to go and fix them all later so it will mag it will display and i'm able to see all my stuff on different browsers as it goes through so this is an example of a second sort of task that we've got set up generally and it's a pre-deploy check right so i've been working on something um looks good to me on my local browser and now i want to get ready to commit this code to a staging server for actual real qa so i run the production build compiles the css does the style guide lints the sas and now we add in a few extra tasks right we take all the images that are in the theme and we use a lossless image compressor we take all the svg graphics that are in the theme we both we copy them and compress them and then do a second step which actually takes multiple different graphics combines them together into one large file which has performance benefits and then outputs that to the site um then after that so we now have compiled css but it does a second pass on it and it looks through my css and it sees any tags that were in there that um that have you need to have vendor prefixes for for older browsers and it goes ahead and it adds those in and then it runs my css regression test to make sure that this change you know i i look through the list of passes and fails there should be if i change one thing there should be one fail and a whole bunch of passes and so that's a double check before we go into into live production and so that and and i haven't got it working yet but you can actually i've seen a lot of people do well not a lot i've seen that it's possible to do you can do an automated performance test on this build as well so that thing can then as a next step go and query google and run it through the the optimizer or or other tools similar to that and you can make sure your load time is before under four seconds so you don't actually push up loaded code once all these things pass then i'm ready to push that commit up to the qa server so admittedly it's not easy to set up all of these tools uh there are a lot of pieces of the puzzle that come into place here but it has some very very significant benefits your team's velocity will increase you will have fewer bugs make it into your qa server so that's fewer bugs to fix and fewer bugs to find it's all it's difficult to push up code that isn't optimized because you you're automating the compression of images and those kinds of things so that you don't accidentally upload an image that should be compressed more and once i think the most valuable is that once you get these somewhat complicated dev stack set up you can recycle them relatively easily between your projects and so you know once you pay your upfront cost of figuring this thing out it's not too bad to transfer it to newer and newer projects so i'll leave you with one word of advice take it in baby steps uh yes i've started my daughter early on on this stuff um whatever you're doing now just add one thing into the mix so if you're not using sass that's definitely the first thing you should add into the mix if you're not doing living style guides i'd say that that's probably the second thing to add into the mix but just you know take it slow add one item into your into your process once you become comfortable with it now it's time to add in a second item and slowly over time you'll end up building a more and more complicated stack and more and more stuff will get automated and you can you know spend more time thinking about what you want to do with code what you want to do in design and less things and less of the mundane tasks that that that we don't really we don't want to focus on i don't want to worry about compressing images anymore so thank you very much and if you have any questions let me know