 It's all settled down, nerds. I want to get started. All right, so we're here to talk about the why and how front-end architecture feel the rhythm, feel the rhyme, get on up, it's front-end time. So who are we anyway? I'm Wester Wachaba. I'm a recent-ish addition to Lullabot. I'm a front-end developer. We have Karwin Young here, a senior front-end developer. And Sally Young, no relation that we know of, who is a senior developer at Lullabot. So like I said, we all work for Lullabot. It is an awesome place. Well, it's not really a place. I'll take it back. We do strategy design and development. And you should come work with us because we're awesome. So we have a buzzword in our talk title. So I thought I would try and define it, make sure we're all on the same page. So when I talk about front-end architecture, I'm talking about how you design, how you want to work with the front-end, and how you're going to collaborate with the people that you're working with, write your code, and then what kind of standards, libraries, and tools that you're using. So the byproduct of that looks something like coding standards, documentation, style guides, implementation guidelines, file organization, tools, building process, blah, blah, blah, blah, blah, blah, all that kind of fun stuff. So it's important to revisit these decisions throughout the project because things change, the team dynamic, how the code's working, how your build tools are working, all that kind of fun stuff. You can't always change this stuff mid-project, but it's important to have the conversation and figure out if you can address anything as it comes up and make sure that your team is liking the development experience that they have. Because we want nice, happy brains that are writing new features and solving bugs. We don't want a very grumpy, angry brain that's like, where do I, how do I, what, how? Oh, here it is, I guess, and now I'll fix it. So we want to talk about why we're picking these different tools and processes and how we make those decisions to make sure that we're successful throughout the life of the project. And as far as I know, I haven't seen a one-size-fits-all friend in architecture yet. So that means that we all have to kind of be aware of what the tools are that are out there, what kind of processes there are, and why you might use these things. And at the end, we'll have some time for questions. But if you don't get your question in or you think of something later, feel free to hit us up in real life or on the inner weapons. Second slide there will have our contact info. And yeah, we love talking about the stuff for some silly, stupid reason. So let's get into it with Karwin Young. So I'm gonna talk about that stuff. The organization of the front end is, to me, the underlying foundation of all of the architecture and stuff that we're gonna talk about today. And whether you're flying solo on a project or working with a big team, organization is crucial. That doesn't necessarily mean that you need to structure a small team project the same way that you do a large team project. But there has to be some level of organization or you'll end up with a mess on your hands even if you follow all the other advice in this talk. So that's a mess and that's kind of the thing that we're trying to avoid. Like I put there, there's no logic in this place. It's huge. The organization and planning of the front end is one of those pieces of a project that's usually either neglected until after it's already way too late and you already have a big mess on the project or it gets fixated on by developers to the point that they don't actually get any work done. And so I would like if you didn't take anything else away that if you just drilled this one thing into all of your heads. Some kind of plan is better than no kind of plan. Well, no plan at all. Arguably the most important thing a solid organizational structure does is it make it easier for you to find your stuff. No matter who you are on a project, inevitably you'll come across the need to find something somebody else has written or you'll have one of these questions. Where should I put this fancy new template file? That kind of thing. And sure you can use grep or your IDs find function if you want, but if you know the patterns and the organizational paradigms that your project is using, you can get to modifications quickly and you can work more quickly in general. And it'll just provide instant answers to all these kinds of questions as they pop up. So having a solid plan for the front-ends architecture also prevents an overlap of code and it encourages compartmentalization. This makes it easier to work on new features and it gives you some measure of breathing room when you break something because you aren't breaking 5,000 other things on your site. And if you can break just one thing on your website at a time, I think you're living the dream. Because that's really hard to do. It's hard to break just one thing. So a solid organization and a documented set of project conventions are invaluable to every project. So now I've talked a little bit about why organization planning is so important. So let's talk about how you decide what to organize and to what extent. So firstly, what kinds of things can we organize on the front-end? Well, you can organize templates, your processor files if you're using those, CSS properties if you hate yourself, JavaScript libraries, helper functions, et cetera and literally whatever else you have going on. In short, everything. Organize everything. Write it down, document it, drill it into your heads. This thing goes here and that thing goes there and projects will be a little bit different depending on everyone involved. It is a real balancing act that takes place around the extent to which you organize. The level of detail you put into your plans will vary significantly with experience. So start small and then build on that. If it makes sense to you to organize right now, organize that and don't sweat the details of what should I be organizing because you'll have an innate feeling about this needs to be organized. So HTML, templates and preprocess. You can organize this. In general, a good thing to think about when considering how to organize templates, preprocess stuff is do these functions or files, does anything in here rely on code provided by something else, like a module? If the answer to that is yes, it might be a good idea to keep them coupled. If the answer is not yes, then it might be better to just put it in one place like the theme. That way, especially if you're on a small project, you just know exactly where it is. All my stuff for this thing is over here. So there's no right or wrong answer to something like this, but a call needs to be made up front so that the project is easier to understand. Otherwise we're running into small things that eat up lots of time. For instance, I was on a project where we had things spread out all over the place and it took me a lot of time just to figure out where and how I should be working rather than actually getting any work done and that was really frustrating. And then on a different project, I've had developers who were adding markup to items and views through the UI and that wasn't documented. So I had no idea where to make the changes I needed to make. And the reason for that was there weren't any firm decisions that were documented somewhere that I could read and say, okay, this must be infused somewhere. So making up front decisions is important, especially regarding front-end architecture. Wes actually wrote this slide. I thought it was funny. I'll let it sink in. Okay, I heard some chuckles. That's good. So JavaScript, we already know this. JavaScript planning is actually relatively simple, especially in the Drupal landscape and the decisions you make around how to organize things, they follow mostly the same logic as templates and processing functions. If your JavaScript relies on something, it makes sense to keep it with that thing. You will have some different decisions to make if you're implementing third-party libraries or jQuery plugins or something like that. You should probably handle that with package manager, which Sally's actually gonna talk about a little bit later. Let's just move on. CSS is probably the most front-endy thing I can think of and that's an actual word that I submitted to Webster, but they haven't put it in yet. There are a good number of organizational paradigms that you can adhere to, particularly if you're dealing with the preprocessor landscape in CSS. So instead of talking over the finer points of one or another methodology, I wanna talk about how to choose one first. And then before I get into that, I wanna say that if you're unsure of which one to choose, you can simply pick one that sounds interesting and then run with that because there's absolutely nothing wrong with it. Like I said, some kind of plan is better than no plan at all. So to get a little more specific, I think of CSS methodologies in three basic types. This is an official, this is just me. There's the component methodology, which is highly modular, discrete chunks of CSS and markup. Utility classes, or utility methodologies. The Lego version of CSS, you kind of tack on classes to markup as you go. And they do very few things like dot underline or dot red, which as you may expect, will make something underlined or red. And then hybrids, which are kind of a mix of the two, good for the environment. You can pick something that lines up with any of these, but the decision about which one to use needs to be based around how you and potentially your team want to work together. If it's easier in your mind to modify markup, you'll have pretty good luck with utility class-based paradigm, really. If you need to reuse a lot of markup patterns, component-based methodologies work great for that. Most projects I've been on recently kind of use the hybrid thing, where we start out with a component-based methodology. And then as we get further along in the project, we realize, oh, we didn't account for X, Y, or Z, or we didn't think about this, and so we can add a utility class here or there that kind of helps bridge those gaps. And that works really well. And in fact, that's my favorite way to work. As long as you don't go overboard with utility classes when you're mixing them, life gets pretty easy. And it's worth noting that Drupal 8 already has some standard best practices around how to architect your CSS. So if you're unsure of what to do or having trouble deciding, that's a safe bet. You can go with that. That way, the other benefit is, if you ever want to contribute something back to Drupal, you're already adhering to the Drupal standard. There's still no logic in that place. I hope we never have projects like that. So every project on some level runs on the currency of time. Some obviously have a lot more than others. And personal projects especially can seem like their budget of time is infinite. The upfront cost and time of organization when planning out the front end can be really, really hefty. And it's tempting as a developer to just say, I don't have time for this. I just want to take this PSD and I want to make something visual that people can play with and look at. But if you skip the planning organization, you'll end up with really fragile code. And you won't be able to live the dream of being able to just break one thing at a time. So be aware of that. Don't over engineer this stuff. Speaking from experience, I can tell you that it's really easy to let this organizational stuff kind of consume your life on a project. I mentioned earlier that sometimes developers can get so fixated on this stuff that they don't actually do any work. And I'm guilty of that myself. So that's definitely a real problem. And as I mentioned earlier, it's also important to realize that everything changes. So all the plans and conventions that you come up with, planning out the front end, they're all going to change. The project moves on. You're going to be working with people who are going to say, hey, I've been doing this for like two weeks now and it totally sucks. So you need to spend time, set aside time for architectural decisions, keep them simple, and revisit them as much as you can. Preferably throughout the duration of a project that way everyone can land on something that they like and that they can work with easily. So I'll leave you with this once again. Some kind of plan is better than no kind of plan. Wes. All right. So now we're going to talk about build tools. So build tools have become really big lately. And in the last four years, we've gone from like a handful to so many that no one person can keep track of all these stupid things. So if I'm not using any right now, let's say why might I want to adopt build tools? What are they going to do for me? So one of my favorite things about build tools is it adds a layer of abstraction. So working in compiled languages is a good reason to use it. Sass, less, copy, script, handle, all that kind of stuff. Copy, yeah, the other ones. And then how you work and how your code is delivered are not the same thing. That was true to an extent before them but now you can do something that's very good for you but would be very bad if you delivered your code the exact same way. So having small files that are just for one component might only be like 20 or 30 lines. You might, if you did that back in the day, you would have way too many CSS files unless you concatenate them all. But there's a lot of cool little ways you can make it easier for you on the backend and then on the browser side, they get what they need in a really nice way. If you're doing all this stuff right, your code can be drier and more compartmentalized which goes back to the being a lot easier to work with. There's definitely, it can go wrong and that won't be the case but then look at best practices, figure out what other people are doing, how it's working for them. There's lots of great articles about ways of working with build tools. And then another thing that I really like about build tools is they can help bridge gaps in between different skill levels. So what I mean by that is a clean example are SaaS mix-ins. So you can have your front end dev that's like your lead, right, a really good mix-in for maybe a complicated little thing that you have to know all these arcane terrible IE8 things in order to get to work right in every browser and they got it right, they tested the crap out of it. And then another developer who might be junior or might be new to the project can use that and it'll just work and it's tested and when they build new feature B, it's gonna look great because they've already been able to handle that before. Another great thing about build tools is they automate tasks. I hate menial repetitive tasks. Computers on the other hand, really good at them, which is nice. So things like linting, repetitive command line tasks, minification, compiling, browser prefixing. My command R, Twitch, is going away slowly but surely. So you can do all these kinds of wonderful things and to do all this, you generally are using a task runner. So task runner will perform a certain set of things and it'll just kind of write down and use you this, that and the other thing and then you'll set up a trigger which is either I'm gonna type this into the command line or I'm gonna save a file and then you need to do all this junk. Another great thing about task runners is you can set up different types of task chains. So you could have one for different environments, local versus test versus production or you could have different ones for different type of developers. So your front end person would be really concerned with you know, SaaS linting or little different compiling things and they might want things to run a certain way whereas your backend developer doesn't care about any of that and they just want the site to not look broken because there's no CSS. So you might have something a lot quicker for them that they only have to run a couple of times. So a common front end task chain might look like this. Compile my code, let's say we're using SaaS or whatever it is, auto prefix it. So if you haven't heard of auto prefix there's a popular one. It'll query the last three major versions of browsers, figure out if you need Mose or WebKit or whatever kind of obscure little fix in there. Minify, so it's really nice and small, save the end product in the right location and then reload my browser. And all that happens within three seconds and that feeling is better than drugs. It is so good. I can't even explain it. So not all sunshine and flowers, there are some drawbacks to using them, there are some like gotchas. So caution all you who enter. If you're new to build tools, there's a learning curve. It is not quite as bad as the Drupal learning curve but it is definitely there and bumps and bruises will happen. Getting your first setup will come up with Bumside, guarantee it. The documentation for some of them isn't great but what is great is they're getting really popular and a lot of people are writing really good and getting started articles and there's a lot of really good stuff out there. So definitely look for that kind of stuff. General warnings, so if you use them for a long time you might run into some of this stuff. There will be some maintenance cost. The goal is that the benefit you get out of using these things is way better than the time you spend like making sure it's running the way you want it to run. So things that might come up are long load times or long compile times or you might have a new tool you wanna use because you have a new feature set or something that came down and you found a really nice build tool to help you address that problem. Don't over engineer. So that's always a risk with development but if you start using build tools that temptation is palpable. So just wanting to use the latest and greatest tool or get that compiled dime down just like a couple more seconds or like a half second. Beware long build times. That's definitely can cause a lot of frustration with developers. We had one compile time on a project I was on recently where it was up to a minute for some people and it's based on CPU time and whatever else kind of other things but you're usually able to address that. We got it down to 10 seconds for them and it only took an afternoon of someone's time. So it's not like you're stuck with that. Front end build tools. They're still pretty young. So there is some change that's still happening but it has calmed down and it is starting, we're starting to find like lots of cool workflows that people tend to use. So it's not turbulence but if I was getting started I would wanna know that yeah it is still kind of changing sometimes. Another thing that people may not think about all the time is that build tools can increase developer specialization meaning if you have a lot of cool tools that you're using like SAS and Copscript and all these things it might be harder for a backend developer to swing in and help out with a front end task real quick. They might not be familiar with everything that you're using. So how do I decide whether or not I should be using build tools? For me it kind of breaks down into project and code size for the most part. For small teams especially if you've never done it the setup can be prohibitive depending on how big the project is. If it's really small, it's like one page or something and I probably won't bother. It can hamper the cross functional team members so if you have, if it's you and a buddy and you're working on a site for someone and they're more back endy and let's say they don't know SAS or they're not as comfortable with build tools but they can help you with vanilla CSS I might just leave out some of that stuff or maybe all of it. If you have, but if you have a common set of problems and you have someone that you work with a lot you can get like a basic go to set of build tools that you use that solve your common problems and help you get started up quicker. So it's not always a yes or no situation. Or it's not always a no situation. So on larger teams project and projects I think it's easier to sell. They build tools really help build for scale. They really help if there's a lot of people contributing to one code base. And if you have a large team and you're probably gonna have a large code base too that any kind of efficiency you can get there is very helpful. Another thing is on a larger team you can probably have a point person that knows what happened if the build tool isn't working as well as should or someone's having problems getting started and that kind of thing. You'll usually have someone that can focus on that. And then again, word of warning. On bigger teams sometimes you can lose sight of whether or not these things are adding value. So you wanna come back and revisit that and make sure it's making it easier to work on and not being more frustrating. Watch for the long build times. Bigger code base can mean bigger load times but or bigger compile times. But like I said, that is something that can totally be addressed. Requiring a lot of command line knowledge can be a little tricky. Maybe some people who are new to front end or maybe new to the project that might be a little difficult for them but if you document, document, document how to get started, what your life is gonna be like now that you're working with these build tools, like how might you work a little differently? If you're writing that stuff down in a read me or whatever, it's going to make it a lot easier and cut down on some of these negatives. So are there large projects that I wouldn't use build tools on? I could think of one rather big one. One that we're all here for? Drupal. If I could control core for a day, I would not put in my favorite build tools. Build tools make a system opinionated about how you're working with them. It's not really the point of Drupal to say this is exactly how I want you to write your CSS that needs to be in SAS and then we're gonna use auto-prefixer and it's gonna work like this. So a little more realistically, let's say you're working on a large project and you might not know who's gonna maintain it down the road or it's gonna have to be used by so many different types of people that having build tools in it might be very prohibitive for them. So having that kind of judgment of whether or not it's gonna be valuable for who ends up having to use it is really where I kind of make that line. And yeah, another thing you can potentially do is if it's a big project and you really want to have the benefit of working with build tools, there is sometimes the option of being able to strip them out when you ship it so that the final deliverable is really nice, well-organized CSS but on the back end you're using SAS or whatever it is that you were using. So yeah, and with that, Lady Sally Young. Hi, so welcome to the package manager section of the talk. I'm gonna show you a problem that I come across quite often and it's this. So I start on a project, I open up the theme or whatever app I'm working on and suddenly I see a pile of JavaScript and that's great, I'm sure it's all working and I open up something that I need to debug. So some of the things that, one thing I need to debug is this minified JavaScript here. Well, firstly, I don't have the unminified version so that makes life really difficult. There's no meta information attached to it so I don't know where this JavaScript came from. I don't know if it has any dependencies or if something depends on this. I don't know what version we're using right now. I also don't know if anything else came with this JavaScript with any CSS required for this to do what it does. So this is something that package managers can solve really well for us and this is where we get slightly less abstract because it turns out you don't have too many choices on the front end for package management. So any kind of external dependencies, any kind of external dependencies that you wanna pull in so loadash or modernizer for JavaScript or Susie Grids for CSS, you can do that with NPM or Bower. They're the two main front end package managers that we use. You have probably already used a package manager in other aspects of using computers. If you've ever used Debian and done App Get or Yum on Red Hat, then you've used a package manager. It went off, it found the software that you needed, figured out all the dependencies for you, brought it all in and bam, there's your software. If you use Drupal 8, then it comes with Composer which is PHP's package manager. That's how we pull in all the third party symphony components. We're now able to keep track of all the versions. We know where everything came from. If there's a problem with that component, we can go back upstream and make the changes up there. So I'm gonna talk about NPM to start with. That's no JS's package manager. It has a really simple configuration file. It's a JSON file and there's not much to it. It just lists out the short names of everything that's in our project. So now if I wanted to look up Cheerio, I could go on npm.org. It'll give me a whole big description about it. It'll take me to the GitHub issue queue if I need. I know what version is there. I can see any dependencies that it might have as well. There's other things you can do with this file as well. You can split out dependencies that you might only want when you're doing development. So maybe I need some kind of packages to help with my build tools or I can just have any kind of dependencies I need for my front end. One common misconception about this is that you have to be using no JS in your project for this to actually be useful and you don't have to at all. You really, really don't need no JS to be able to take advantage as long as you're using any kind of JavaScript or I think you can even get CSS frameworks and other things through this as well. You can pull it in through NPM and even though NPM is the biggest repository of packages on the internet now I think, you don't necessarily have to use NPM parts on this. You can put GitHub short names in. You can point it to tags and do all kinds of stuff. So it's very flexible. If you have any private repositories, you can manage it through that as well. The other option is Bower. Guess what its JSON file looks like? Pretty much the same. So why would you want to use NPM over Bower or the other way around? They're slightly different in that their dependency structure is not the same. So for NPM, it's a nested dependency structure whereas Bower is specifically made for front-end dependencies. So that's flat. What does that mean? So when we bring in a package, you'll see this big node modules folder there. And we pulled in a bunch of stuff that I mentioned earlier. So if we look at Cheerio, we can see underneath there it has its own node modules folder. And underneath there, you can see that we had a dependency on CSS select and under there CSS select had a bunch of dependencies there like CSS what and DOM utils. So this is something you really have to watch out for because it can get very turtles all the way down if you're not careful. But one advantage of that is you can be pretty sure that nothing's gonna go wrong because you have the exact versions of everything you need. Bower on the other hand, if I download two modules and they both require jQuery because it only has a flat structure, it's only gonna pull in jQuery once at the top and both my modules can point to that. So why would you want to use one over the other? I tend to use NPM if I'm writing JavaScript modules, you can use the require function in that to pull them in as well, which is great. So you can package up all your JavaScript modules with Browserify or Webpack, just use it, that's great. It doesn't tend to come out too big. NPM also has what's called a Djupe command and it will attempt to take all these dependencies that are common and push them up to the top. It's mostly effective, not always. Whereas Bower, you might wanna use that more for bringing in polyfills, things that are just gonna globally sit on your page. So you can use them both. What are the downsides? Well, now you've added all these external dependencies instead of having to check your JavaScript into your repository. I experienced this recently. Many of you probably did when GitHub was being hacked by, well, DDoft, sorry, by Chinese people. It all went down and every time I was trying to compile my project, I went off to NPM to get the packages and it just kept timing out. So I couldn't do any deployments, which was very irritating. But my project itself was hosted on GitHub. So I kind of would have had the problem had I not used NPM anyway. But that was definitely something you need to weigh up. So moving on to everyone's favorite subject, which is testing. I split up front-end testing into three areas. Visual testing, including regression testing, is probably the hardest of all of them to set up. And the reason for that is that setting up each application that you work on, they're gonna be very different. So say we were working on a Drupal project, it's gonna have all its build tools, whatever we're using in the front-end. So say Wes comes along and makes a pull request, he changes some CSS. So okay, we wanna do some visual testing on that. We're gonna have to spin up a new version of Drupal, apply the new code, figure out what pages we wanna take screenshots of and everything. So there's no one recipe for that. It's quite difficult, but it can be very useful, especially if you're doing any kind of cross-browser stuff. We can kind of hit that all in one go, see what it all looks like. And if you're not using a strict component-based architecture, if things have got a little bit spaghetti and cross-over-y, then that's really, really useful as well. Like you made some CSS changes in one place, and it made some kind of effect somewhere else that you weren't really expecting. And this sort of stuff is really good for catching that. It might not be great to even set up regression testing until you're kind of towards the end of your main dev effort because everything's gonna be changing really, really rapidly. So every pull request you make is gonna be like, well, a bunch of stuff changed. Like, yeah, I know. So that's kind of good towards the end of a lifecycle. And then as things start to kind of move a bit slower, very useful. The next type is unit testing. You might have seen or done some of that in Drupal 8 in particular with PHP unit. We can do unit testing in JavaScript as well. So we're actually checking that the logic of what we're writing, like typically JavaScript, actually does what we want it to do. With that, we're not testing any kind of services. We're just making sure that the code we've written is solid. And if we make any changes elsewhere, we're not gonna have broken the logic for other things that we've done. There's a bunch of different stuff you can use for unit testing. If you're using any kind of JavaScript framework, usually there'll be some kind of popular testing thing that goes with it. Use your Google Foo for that one. The easiest kind of testing you can set up, and for me has been the most useful though, is code sniffing and linting. And it's fantastic because it can save you so much time. You'd be surprised, like, I do it all the time. I put little areas in my JavaScript. I forget to do it. You can just pull that up straight away. So it really improves your code quality quite rapidly. It will also help you enforce coding standards across a project. So you can make sure that everyone uses camel case, which is very useful. You can also check for any performance problems that might arise or any kind of misuse of JavaScript variables. Always really good stuff to look out for. Super easy to set up. One thing to watch out for though is that you really need to keep an eye on false positives. Tests are not like humans. You know, they have a very set way of doing, they're set pattern of doing things. So for example, say we're using a database module, we've decided that our variables are always going to be camel case, but to use this database object that we've loaded in, it requires some kind of snake case. Well, now our lint is going to fail. That's what we do. Do we just let it fail or are we going to have to go and change the external library? It's not really possible. So most linters will actually let you turn that stuff off line by line. So that's pretty good. Also, don't always assume that the tests you've written are the be all and end all and everything is right. I've seen situations where a test has failed and in order to fix it, it threw up a performance error and actually the fix made performance even worse. So in that case, we need to go back and we need to fix the test. So you always need to keep an eye on stuff like that. And the thing that will stop that happening is that you have a really good peer review system in place. So you're never going to be able to replace humans. Humans are great. They can figure out all kinds of things that are wrong with your code. So make sure everyone's checking your stuff. And with that, I'm going to pass you back to Wes to talk about frameworks. Hooray. All right, front end frameworks. So we're talking Bootstrap, Susie Grids, Yeti Foundation, this kind of stuff. So why might I pull in one of these guys? Benefits. So a lot of testing, grunt work, coding already done for you. Also documentation done. And usually it's beautiful documentation, which is great. A lot of support, either official support or it's all over Stack Exchange or whatever, you'll just pull it up with Google and you can figure out what other problems people are having that might help you out. Those are almost always built to help devs of varying front end dev skill levels accomplish good interfaces. So if you have a project that doesn't necessarily have a bunch of front end rock stars on it, it might actually help you out. And then one benefit is that some front end architecture decisions are already made for you. So you can kind of just kind of go with what they've already been doing. They've documented it well, almost always. So you can just kind of go with the flow with that. Downsides, the more you deviate from the design that they have, the harder it's going to be to maintain. If you can find one that's exactly what you want, good for you, maybe you should use that. But if it's very different from what you want and you want to be able to tweak things, that's gonna hurt. Code bloat can be an issue. That is one of the popular downsides of this and the one thing I would say about that is it assumes that you would be good at not making code bloat anyway. So if you're not full of front end rock stars, it might actually be better to use this. Specificity wars, those will happen, especially if you start deviating, you're gonna start having to write really weird selectors and making sure that your CSS wins out over theirs because editing the base code will make it even more of a headache because now you can't upgrade or update whenever something new comes out. And then downside, a lot of front end architecture decisions are made for you and that's also a downside because if they don't work for you, it's kind of tough luck. You literally have to go with the flow at that point. So when might I adopt one of these frameworks? So it is pragmatism over idealism in some respects because one of these architectures are really hard to build on your own and if you're building for scale and you might have crunches in team abilities or time or you can't QA something that has to be so large, this can kind of cut some of that out. There is a lot of testing already done on these things. A lot of people are using them. It will save you a little time, especially if you are spanning multiple applications and multiple systems with one front end architecture. This can come in handy. And then supporting a lot of devs that may or may not be front end savvy is a lot easier. They can go and see that if I wanna make a component it looks like this that is this kind of content. My application needs to spit out this kind of markup in classes and I put my content here, here and here. So it can be pretty useful. I will say that if you do have a lot of front end rock stars and you do have the time, I don't recommend this. But that is not always the case. It is not always that perfect world. So the too long did not listen portion of our presentation. Some kind of plan is better than no plan at all. Build tools are good probably. Package managers, yes please, those are awesome. Testing is good but people are good too. The robot revolution is not here yet. Frameworks, use at your own risk. So with that, you can ask one of us lovely people any question you want. There is a microphone right there or I will repeat your question into this microphone and hopefully someone has a really awesome answer. I saw one guy back there for sure. I mostly use Bower for doing polyfills. So if I didn't have to do that I probably wouldn't use Bower at all. Oh sorry, the question was do you foresee a time where you would just use NPM instead of Bower? There are projects I could work on that I wouldn't need to use Bower at all. Some I wouldn't need to use NPM at all. So it depends what you're doing. You definitely don't have to use both. Thomas Laddermore who I totally don't know at all. So the question was how does browser if I play into NPM and all the package manager goodness? That's a question. So if you haven't used browser if I before what browser if I can do when you're writing JavaScript well no JS even you can do VAR whatever equals require and then you can pull in a module that you've downloaded through NPM. And then what browser if I will do is go through all of your JavaScript modules. It figures out all the dependencies and then it will add them into one big bundled JavaScript file. And so it lets you write your client-side JavaScript as if it were on the server which is really great and you can then run it in both places which is pretty awesome. Yeah I use that word. Yeah so you wouldn't, browser if I doesn't really work with Bower I'd say. Is there a way of automating it do you mean? Or yeah I'm not really, can you repeat the question I'm not? I think the question was something like is there a way of automating testing that makes it easier for users to be able to test your things? Yeah if you can for every code change you make if you can make some kind of automated environment that spins up and so they can someone who's like a product owner for example they're not gonna be able to pull in your branch and then like pull all the code in and test it. So if you can automatically spin up those environments which you kind of need to do if you were doing any kind of visual testing then they can just go in and click a button and like oh hey the navigation changed to green that's exactly what I wanted to do. So yeah you can. Yeah very little but have we done anything with PhantomJS visual regression testing? The answer was yeah a little bit. I actually played around with Wraith a little bit which I think is built on top of PhantomJS but the last time that I used Phantom it was a bit broken in that it could only really work in one browser at the time I don't remember I think it was Chrome. Okay session on it tomorrow at 2.30 if you'd like to know more. Nice. It was good. That's a different talk. Yeah so which build tool should we use and why? So there are advantages to different build tools and there's holy wars on the internet right about that. Yeah no I'm a grunt guy I'll say that but in this talk I didn't want to say like you should use this one because I like it a lot. So I just wanted to say like okay why would I use one of these things what is it even going to do for me? So yeah that's my answer. I use grunt. Grunt. Yeah we're grunt people. Yeah. Yeah it's a gulp. Okay so this is quite a common thing that people think grunt can't do and it definitely can do things asynchronously. I think there's a grunt concurrent plugin and that's one thing I really like about grunt is the ecosystem for it is huge so if you can think of something there's probably some kind of plugin for it that does it. Yeah. So the question was once you've pulled in all these things with package managers how do you pull them into whatever you're doing in Drupal? And it depends how you're using those packages so like the question earlier about browserify. If we were pulling things in with NPM to do it that way then browserify would take care of it for us. You can just put them into your info file manually if you like the file names won't change so when you update stuff with NPM or Bower it's still gonna work. There's a grunt plugin you can use called WireDep and if you look at the, there's a starter theme on the Lollabot GitHub called Windup and if you go in there there's a little script you can run and it will wire up all your dependencies for you and put it in the info file which is kind of cool. I think we're out of time now so thank you.