All too often front-end JavaScript code has been considered a second class citizen, and when treated without due care and attention it can be buggy and hard to maintain. This attitude is changing though, and thanks to the rapid growth in popularity of JavaScript as a first-class language, there is a large and expanding ecosystem of tools that a developer should know to make their client-side code as “clean” as the rest of their stack. This talk aims to introduce and discuss how to implement modularisation, functional idioms and testing in JavaScript in an idiomatic way, to allow you to code JavaScript to a higher quality and, ultimately, more sustainably.
 Everyone, can you all hear me at the back? Is everyone OK? Excellent. I'm going to warn you now that you are getting a talk from me just recovering from tonsillitis. So I am very sorry if my voice doesn't quite hold out to the end. But I made it here to talk to you today about high quality front end. Just before we leap on into the content of the talk, I'll just let you know that the slides are available online. They're already here at this URL. I'll tweet a link to them at the end of the talk as well. So don't feel as though you have to be constantly scribbling notes. Hopefully, I'll make my way through the slides relatively quickly today. There are a lot to get through. So you can go here afterwards and hopefully reflect a little bit more on the information that I'm giving you during this talk. While people are shuffling into the back, I'll get the formalities out the way. I'm David. I am Sparmish Turtles on all social media worth mentioning, Twitter, GitHub, the internet. I'm a tech lead at SoftWire, working with open source technologies. And my background is in statistics and simulations. So my experiences with front end have been more on the data visualization and the business insight side. My boss has told me I had to include this slide. SoftWire is a software consultancy that deals with every aspect of the software lifecycle. We've got a lot of projects running at any given point. And I have been told to ask, if anybody's got a software project, they're looking to outsource to come and speak to me at the end of the talk. That is, however, the only. Sorry, there are seats down at the front and on this side, if people want to shuffle around. Yeah. Yeah, there's quite a lot of seats in the middle of Ray. So if people want to move it down just to try and hopefully get people seats, it's quite a full talk. This is the only slide in which I'm going to tell you. And I think we can forget about that now and get on with the technical side of things. But I did want to bring up that what I'm telling you today, I'm not going to tell you anything bleeding edge. I'm not going to mention any massively innovative JavaScript libraries or anything like that. What we're bringing you today is hard-won experience over the last year, two years of working with Frontend Code. Knowledge that we found out as a company by working with a lot of different projects on the web. So specifically, what I'm hoping to talk to you about today, I'm going to talk to you about three different things. Firstly, the past. So what is JavaScript's legacy? How have we gotten to where we are today? And then the bulk of the talk is going to be talking about the modern JavaScript ecosystem, the modern JavaScript libraries that you'll want to use in order to make a nice, clean frontend for your site. And then hopefully, by the end of the talk, you'll have some practical next steps to go away with and to try and apply on your projects. So specifically, we're going to be talking about JavaScript today. We're going to look at the problems with JavaScript, the impacts that they'll have on a project, and then hopefully look at a broad range of native solutions to them, look at potentially other languages that we can use to supplement JavaScript, and then the third-party libraries will add to the quality of our code base. Sorry to disappoint if you're here for any of these things. We're not looking at any HTML or CSS. We're not going to be looking at Node.js or any server-side JavaScript. There are some great talks today about future versions of ECM script and other JavaScript libraries, including React and so on. And there are some great talks about that this week, but we're not going to go into too much detail here. So sorry if I'm disappointing. Feel free to find another talk in this slot, if that is what you're looking for. You're all staying, so I assume that this is hopefully something that you want to hear about. So firstly, let's think about where we are at the moment. Where does JavaScript come from? How did we end up where we are? And I want to give you a very brief introduction to JavaScript, both in the computer science realm and my personal history with JavaScript. So it was originally written in 1995. It was there to support user interaction. It was there to be rendered on web browsers. It was the only thing there that could really, at that point, in the internet give interactive script on web pages. Things have come and ebbed and flowed and things have gone away again. But JavaScript has been the only real constant over these last 20 years of web development. It is interpreted by browsers according to a set of rules, which is this ECM script. You're going to be hearing a lot about future versions of that this week. And it was originally intended as a combination of a scripting language, functions for first class objects, so there's a lot of functional paradigms there as well, and there's also a bit of object-oriented nature in there, but not the way we understand it from C, Shaf and Java. Hopefully, you already know that. So I want to talk about my personal history of JavaScript and my first ever encounter with this now famous language was from a site called Dynamic Drive. I don't know if any of you have heard of that. Essentially, what it did is allowed people to go and copy and paste JavaScript that made your website look awful and perform really badly. So this example here is it allowed you to go and get snowflakes falling down your screen, if that's what you wanted. And people just copied and pasted it and plonked it in the middle of their site and had no idea what Earth was going on and tinkered with some valleys here and there in order to actually get the site to look as awful as they wanted it to. And this was JavaScript back in, it must have been 2002 now, and that is how all of my friends learned what web development was back in the day. I mean, there were probably more professional outfits that didn't quite copy and paste snowflake graphics, although if you look at the Space Jam website, they are still using their original JavaScript from however long ago that was. Things may have been done better in other places, but if people were doing better, it wasn't because JavaScript supported them and supported what they were doing, it's because they realized they needed discipline to fight against the problems that JavaScript was causing. What problems are they? I'm going to issue a slight provider at this point. I'm going to list a load of problems that people think that JavaScript has. I don't necessarily agree with all of these problems. I think in a number of cases, what people perceive as problems with JavaScript are actually surprises about JavaScript because people have come into web development from a Java or a C-sharp background and they're like, oh, JavaScript isn't behaving exactly as I would expect it to coming from these languages. And well, to some extent, that is the point. But at the same time, we found even if these are language features rather than language bugs, they do catch people out again and again, and they are impacting our ability to develop for the web. The big problem that JavaScript had back in the early days was that there was no ability to separate it down into separate files or no easy way to do that in any meaningful way. So people just used to put one big lump of files there, expressing a large number of global variables that would eventually just either start conflicting with each other or become an unmaintainable mess. There was no easy way to encapsulate code, which meant that there was no real code reuse. And because of that, it was very hard to separate out the bits of functionality that you wanted to test. It was very, very hard to unit test. And this is because of the era from which Java came. Automated testing hasn't been around as a expected standard of code development for that long. And JavaScript, because of it, didn't really have JavaScript wasn't built with that in mind. People complained about the lack of JavaScript's classes. Now, I think this is one of the places where it's not that JavaScript is bad, it's that JavaScript is unexpected. But people, especially object-oriented developers that have moved into the front end space, have come to expect classes when they write their code. They've come to expect the ability to inherit from other places. They've come to expect polymorphism as a way to control their logic flow as their writing code. And when they come to a language that doesn't have this, they have a struggle and flounder, or they try and invent libraries that will reverse engineer these features into the code itself. And we look at libraries like jQuery Extender. We'll do exactly that. People don't like the way that JavaScript manages its scoping. So JavaScript uses functional scope. That is, a variable is defined exactly within the function in which it is defined. This console.log here is actually going to upper undefined, but the one inside the function will up at 7 purely because local var ends its definition at the bottom of that funk. People are surprised about this. It doesn't work the same way that object-oriented languages do. It is a slightly bizarre, different way of doing things. Again, if you've learned JavaScript as your first language and know it all your life, then fine. Great. It's a normal way to do things. But there are certain implications to the OA developer. For example, people don't have private variables anymore. I mean, you can define a variable inside the function and expose it through the return value. But that's a couple of steps removed from the very easy way that you can define fields in C-sharp. And people always complain about its type system. This isn't going to turn into another talk in which we discuss all the obscenities with JavaScript's casting. But there are some very odd behaviors. We don't need three undefined or error types in a language. They don't really add much to each other. Here's a little quiz. See if you can work out what each of these are going to be. If you can get 5 out of 5, I'm very impressed. I mean, it's just, well, OK. If you want to do that, that's fine. And JavaScript also has the concepts of truthy and falsy, rather than true or false, which, again, can be seen as a very good feature of the language. But if you're not expecting it, well, it's surprising to say the least. The last thing I want to talk about before we go on to actual advice about improving the cleanliness and quality of your code is to hopefully step back a little bit and say, well, OK, you're going to go into work on Monday, and you're going to want to implement all of these lovely things that you've seen in this talk. But your project managers are going to say, why? You have to give me the use case for this, the business case for this. So I just want to pop this in here to hopefully give you the ammunition you need to complain to your project managers. We can talk all day about why we want to use clean code. There are excellent books written on it, the famous one being by Uncle Bob, very, very good book, explaining the principles of object-oriented clean code design and the benefits of using it. To summarize it briefly, if your code is more readable, then it's going to be easier to maintain. You're going to reduce the support costs of your code, because if you've got bugs, you can pinpoint exactly where they are a lot more easily. You can hand over your code to another developer a lot more easily. If you're encapsulating your code properly, then it will be easier to replace the benefits of a system as your architecture grows and your requirements change. Enhancements for code, so feature requests are broken into smaller bits, so it's easier to follow in your mind. And if you're testing your code, well, hopefully we all agree that we should test our code, but it does provide assurance that our code is working as it should. It's providing documentation as we go along. And if we build our code with testing in mind, then it actually enforces good design principles, such as the single responsibility principle when you see your test. There's a big question as to why JavaScript is receiving the attention it is now. There's no definitive answer to this. There's no definitive answer as to why we want to improve our JavaScript in the next month to a year. To some extent, web development is becoming a much bigger topic now, but that's actually been true for a good two to five years. So that doesn't really explain at all. JavaScript as an ecosystem, rather than as a language, is becoming significantly bigger. Node.js is now a very mature server-side language if you want to write JavaScript down to the mid-tier layer. But also, a lot of databases, a lot of no SQL databases, are using JavaScript as a query language as well. So especially looking at things like the mean stack, Mongo Express Angular Node, you can see JavaScript now becoming a language that we use across our whole system. And also, I think to some extent, developers have become a lot more picky in the last five years. The rise of Silicon Valley has meant that there's a lot more jobs. We can be a lot more choosy about what we want to do. The mid-tier layer has become actually very mature and very lovely to work on, layer. Look at what the JetRainers is doing to make development like a really seamless experience. And because of that, we can start looking at other areas of code where we don't enjoy working. And start issuing a lot more demands. We can hold our project teams to ransom because of how fussy we're becoming. That's just a pet theory of mine. So I asked, how do you convince your project managers to invest in the improvements I'm going to suggest today? Poorly written code is expensive. Poorly maintained code is expensive. Poorly understood code is expensive. We want to be pushing for nice, easy-to-use code. And that will fit into their objectives as well, because it will allow us to quickly deliver functionality, quickly extend our teams, and quickly support our code. The bottom line is that bad software is expensive. And JavaScript has been quite bad for quite a long time. So talking about the past, JavaScript is basically our only choice if we want to run complex client interaction on the front end. And due to historical context, it is actually quite an unpleasant language to work with. But fortunately, we actually do have the motivation to change it if we want to make our software project successful. So hopefully I've convinced you that JavaScript and JavaScript projects have been neglected for quite a while. So now let's look at what we can do better when we're looking at our JavaScript projects. And then first of all, going to start looking. Without making any changes to the tooling or the libraries of the frameworks we use, can we just approach writing our line by line JavaScript in a more mature way? People say that a bad workman blames its tools. And if you start complaining about JavaScript on your project, it is probably true to some extent that you're fighting JavaScript. JavaScript comes with a lot of idioms that are different to the object-oriented development paradigms of C-sharp and Java. So if you're going to try and put inheritance into your JavaScript code, you're probably going to be fighting against it. And that's going to be more pain than it's worth down the line. But saying that, I also think it's true that if a language forces you to fight it, then it's probably not a good language. So I'm not going to stand here and evangelize to all of you that your JavaScript code is awful and that you are bad people. But it is fair to say that maybe if you align yourself to some of JavaScript's more interesting features, that you can actually get a lot of value out of this before we start investing in significant architectural or tooling changes. So first of all, we have to understand JavaScript's language features. You have to know the language that you're writing. A little while ago, a new JavaScript framework called vanillaJS was released. VanillaJS promises to be a fast, lightweight, cross-platform framework for building incredible, powerful JavaScript applications. And it offers all of these different functionalities. It went around a bit. People were quite excited about this. And then they slowly dawned on them. The vanillaJS isn't a framework. This is all stuff that JavaScript can do out of the box. JavaScript has got closures in it as a first-class citizen. It's got functions. It's got functional paradigms. You can easily write DOM manipulation and Ajax requests using native JavaScript. There is lots of misunderstanding about what JavaScript does as a language. I'm blaming jQuery for this. And I'll rant a little bit more about jQuery later in the talk, something to look forward to. But at the end of the day, you have to recognize that JavaScript can do a lot of things you want it to do. And sometimes when you're leaning on a third-party library, you don't need to do that. It's also important to consider that JavaScript isn't your favorite language of choice. I bullied C sharp here because this is ostensibly a.NET conference. But I could have chosen any language with which people are familiar. You don't have classes. That is not a thing that really exists in JavaScript. It doesn't exist yet in JavaScript. You don't have all of these paradigms of classical inheritance. I know I've ranted about this a couple of times already in this talk, and we're only 17 minutes in. But I really strongly believe that one of the biggest problems of JavaScript two, three years ago is that people were like, OK, JavaScript is a bad language. Let's make it a good language. What language is good? C sharp is good. Let's make it C sharp. And you'll doom to fail if you're doing that, because you're just going to be fighting against the paradigms of the language. You don't have strong types. Don't pretend that you do. You can use prototypical inheritance if you want to, but then actually understand prototypical inheritance and understand where it differs from classical inheritance if you want to use it as a major architectural point of your application. JavaScript is functional paradigms as well. It is a functional language. So if you can use functions like map and filter and reduce, so this is very similar to the link of the.NET world, all of these are native to the array prototype as of IE8 and above. If you're having to support IE6 and 7, first of all, I'm very sorry. But also, you can import libraries like load- or underscore, which will add those in for you as well. So you've got no excuse not to be using a lot of the lessons that functional programming has given us. Stop iterating through for loops. You don't need for loops anymore in JavaScript, because mapping will do exactly what you need for you, or filtering will do that for you. So let's start thinking about what happens if we're prepared to start making changes to the way within which we are writing and using our JavaScript. So let's assume that we're willing to add more tools. Well, the JavaScript ecosystem is actually very big these days. The JavaScript ecosystem has a large number of modules. If you look at the number of libraries that the ecosystem contains, then NPM has overtaken Maven and is increasing at a much faster level. So it may not have everything that you need built into it, the same way that Java 4c sharp has a lot more functions than JavaScript. But it's now become a very community-supported ecosystem. So if there's something that you're missing from your application, you can just take it from this open source community and plug it into your application. Almost everything you would like to do in JavaScript, a plugin already exists for. And you're going to hear me use the phrase a lot over this talk. There's a JavaScript library for that, because there is. There is a JavaScript library for almost everything. That was to training some of our devs at Softwire about JavaScript and showed them a slide very similar to this and challenged the six of them in the room to come up with a common English word for which there was not a JavaScript library named after. The six of them failed. There is almost a one-to-one mapping between English dictionary words and JavaScript libraries. It has become that extreme. If you want to start using these libraries, you can just download them from the internet, throw them into your application. I don't like that. It doesn't give you the ability to update your libraries. There's a version of a third-party libraries increase. And also it encourages people to go and tinker with those libraries and to do slightly more what they would like to, despite the fact as it deviates from your online versions. So there are package management tools for JavaScript. Bower is the typical one that we use for frontend. NPM is what we typically use for our server-side code. And these are the equivalent of, say, NuGet for the.NET ecosystem and Maven for Java. We talk a little bit about Bower. So Bower is this package management tool. It manages its own central repository of JavaScript libraries. And then it also provides a command line interface, which allows you to download the libraries from this central ecosystem. And it also provides a syntax for this Bower.json file that defines the dependencies that it has. Typically, if you wanted to install a library using this, you would use a command line interface, remembering, as always, in JavaScript, the dash-save flag, which allows it to be saved so that other people on your team will also install it when they get the latest version of the code. OK. Bower has almost all of the interesting JavaScript libraries in it. I'm just going to mention a few of them of particular interest, either to myself or hopefully to you as well. D3, standing for data-driven documents, is a library that exists to take your DOM, take your HTML page, and slightly change the nodes in your DOM based on data that you provide it. It's a very, very low-level library, and it provides a lot of good use cases, especially around SVG mutation. However, we almost always use it now in its wrapped form for with chart.jsc3 and MVD3, which all wrappers around D3, which provide good charting support. Numeral.js in my moment, these are very useful tools when we're dealing with forms or validation or displaying data from a database back to the user. We give a format string to the library and also just a raw string that a user may have inputted. And then we're able to format these strings nicely according to numbers, money, units, say, and date and time for a moment. And then it also provides a lot of domain-specific methods on top of this. So if you find yourself in JavaScript writing a lot of custom validation logic, or find yourself writing a lot of date manipulation logic, string manipulation logic, there's a very, very good chance that this already exists out there. You don't need to reinvent the wheel. And then just a couple more libraries, Q, which provides promises to JavaScript, which avoids callback L, and low-dash, which, if you're not working with IE8 or above, will provide a lot of functional idioms and also actually add some top of what the array prototype will provide you. So this is a nice way to start actually utilizing the fact that JavaScript, at its very core, is quite a functional language. So these are all third-party libraries that we can use. And they're nicely encapsulated. They provide one thing. And so it's now time to start thinking about how we can organize our code in that equally modular structure. To break our code down, so instead of having this one big file problem that we talked about earlier in the talk, we can start breaking our code down into modules. So a brief introduction to what a module is, a self-contained piece of code, traditionally one that doesn't really express its internal affairs, so that we can integrate with our modules and integrate our modules together through very defined interfaces at the edges of our modules. So in C-sharp, this could be something like a class, but also actually C-sharp provides name spaces if we want to think at a bigger level, and class libraries if we want to think about an even bigger level than that. JavaScript doesn't really provide any of this. We can write JavaScript in files, and we can put different concerns in different files. But actually, very traditional JavaScript doesn't provide a nice way to ensure that the internal dealings of that class aren't exposed. So our patents will help us with this, but there, again, you're fighting against the ecosystem if you choose to use them. So as I mentioned, JavaScript design patterns, brilliant book. I recommend reading it if you can. It has an example of how this might work. And it's, again, using this idea of functional scope. So we define this module, so that's looking at the top and the bottom line of this. And because of functional scope, we are able to encapsulate anything we don't want to expose inside this module. So this foo variable is not possible to be accessed by anywhere else in our code. And instead, we're returning a subject that provides access to it in very specific defined ways as we would like it to be exposed. And this module is good. In fact, it's necessary if you're not willing to go into third-party open source libraries, but it is very possible to actually get this from elsewhere. So we don't need to reinvent the wheel. First thing to say is that it is coming to native JavaScript as of the next version of ECMAScript. The reason I've not been assuming that we can use that, up until now, is, A, there are better talks about that this week than mine, but also because the browser support for that is not yet complete. This is a graph showing the major browsers and how much of the ECMAScript 2015 spec that they have implemented. Chrome, Firefox, and Edge were doing fairly well, but Safari in particular, and IE, as always, are quite far behind. So we can't actually assume that users are going to have access to these native modules. So instead, I want to talk about a third-party library that will add modularity. This isn't the only one by any means, but it's the one that we've had the most experience and success with, the software. And that's RequireJS. So RequireJS is a module-lating framework. By that, we mean you can define modules. The modules will not leak any of their internal affairs unless you choose to release it. And then you can share and add dependencies between all of these modules as you go. Require by default will take an entry point into your application, and then it will work out the tree of dependencies that you need in order to have all the functionality necessary for that module. Modules can be your own code. You can write your own modularized JavaScript. But most third-party these days will also support RequireJS as a module-lating system that you can use to share the third-party functionality. So if we just look at how RequireJS would work, it adds this define global variable to your application. So when you start talking about this module, this define says, right, I'm defining a module now that other things can use if we choose to. You then list all of its dependencies, and then you just assign them JavaScript variables. And then inside this module, you can do whatever you want with the variables and return exactly what you would like at the end. So potentially a way to modify the state of this module, but also potentially the result of some calculations. That module can be a function itself. It can be any kind of JavaScript object. So it could be a function. It could be an array. It could be a primitive. Absolutely fine. So just an example of how this might work is if we've added the load-functional language. The load-functional library to our project, we can define a module that takes in load-insidependency and then run this code, adding one to each of the array. It will end up returning the array 234. So we can add modules in that way. So we talked a little bit about JavaScript's failings as a language. We've talked about the problems. And we've also talked about the libraries that we can add onto JavaScript if we wanted to add more functionality or try and solve some of these problems. So you might be asking, well, actually, it sounds like we're doing a lot of work to actually fight the language. Why can't we just dump JavaScript? Why did we just say, this is an awful language. I'm never going to use it again. What are the alternatives that you could use? I mean, Flash and Java applets will provide functionality for your clients. But these are significantly outdated. And the final nail in Flash's coffin was when the iPhone chose not to support it. And there are options around server-side rendering. And these are definitely good options for projects with simple client interaction or very minimal client interaction that just needs to display data that you get from a database on loading the page. It's very possible that server-side rendering will be entirely sufficient. But it's not always going to be the case that server-side rendering is enough. Server-side rendering does have problems when it comes to when you have to make lots of requests to a server or when you need to do complex interaction. So sometimes JavaScript is the only option. So when we think about JavaScript and the problems that it's got and our desire to try and avoid writing using it, I want you to cast your mind to Java. And I want you to cast your mind to this architecture that you may have seen before, which is the motivation behind the JVM. So we wanted to write code that would be able to run on both Unix and Windows. And the way to do that was to implement separate virtual machines that can run on either of those two operating systems and then define a language, a pseudo assembly language that would be able to run on either of these two machines that Java would compile down to. People thought that Java had problems. People thought that Java was verbose. It wasn't particularly functional. It lacked features. And it was a very committee-driven language. And so people wanted to write their own languages. And rather than having to write their own new JVM, they actually tried to write languages that would either compile down into the Java itself or compile directly into Java bytecode. They would solve some of these problems. And so when I look at the JavaScript ecosystem, we see a very similar pattern that we did when we were looking at the Java ecosystem. We've got a couple of different environments that we wanted to run on. There is essentially a VM. I mean, it's not a VM. It's a runtime engine. They're sitting inside these two browsers. And then JavaScript is running directly on those two via this runtime. So there's no reason why we couldn't take the same solution that Java had and write in languages that will compile down to JavaScript. And that's what's been done over the last 5, 10 years. So there are now languages that will compile to JavaScript and almost use JavaScript as the equivalent of Java bytecode in the browsers. There's a large number of different libraries that can do this. More than I can name. So there is a link there that you can look at to see a lot more about this ecosystem. There were early adopters that seem to have come into the scene and slowly depleted until they're no longer massively supported. So we're looking at things like Kotlin, LiveScript, and ClosureScript there that still are used on projects but lack the maturity for some of the other ones to do. And in fact, a lot of these other languages, Java, Ruby, Python, C-Sharp, all have compilers that will compile them down to JavaScript. But the problem there is that they're not really designed to be run on the front end. And so the languages and how they work with JavaScript are not that intuitive. So instead, the two languages that are currently speaking have come out on top of this big battle to become the best compiled JavaScript language are TypeScript and CoffeeScript. It's early days in this site, and I'm sure there'll be a lot more challenges coming in the next three years. But it looks like TypeScript is becoming the favored language. It's supported by Microsoft, so it's got a fair amount of maturity behind it. And we've actually found working on different projects in TypeScript and CoffeeScript that we do prefer TypeScript as a language. CoffeeScript is absolutely fine, but it suffers a little bit in tooling, and it also suffers because it is different to JavaScript, whereas TypeScript is a superset of JavaScript. So we can always fall back to native JavaScript if we choose to. Just to give you a brief overview of TypeScript as a language, it is strongly typed, hence the name. And therefore, a lot of the benefits that you get in your IDEs, or with compile time type checking that you get with your traditional LRO languages you're getting in TypeScript. It adds missing features to JavaScript, so it has got classes. It's got modules. It comes with the same package manager. And it is backwards compatible with other existing JavaScript libraries because, well, it is a superset of JavaScript, so you will be able to just import them in. But also, so that you can use them in an idiomatic TypeScript way, there's an open source project that's built around adding static type checking to these JavaScript libraries. So just looking at some TypeScript code, it's very different, in theory, to JavaScript. We've got classes. We're using classes in the same sort of way that we're using in C-Shop and Java. But you can actually see some of this JavaScript being used here. So when TypeScript doesn't add exactly what we want, it's giving us this ability to just fall back to the native JavaScript. We're adding types to our methods. So the return types, we're also adding them to our variables. But they're optional. We don't need to give it a type if we don't want to. It's just there at compile time to check if we do. Let's talk about JavaScript testing. We've already briefly touched upon why we test code. So I'm going to very quickly zoom through this. It reduces regression. So if we've got tests in place to make sure that our functionality is working as we programmed it, if we make a change that breaks something down the line, we'll catch it. It reduces bugs in old features. And it also reminds us if we have changed something in a new feature. It makes sure that we've considered every edge case. It makes our code more maintainable. I do not necessarily agree with this idea of testing juice design damage. I think it's a lovely idea. But actually, I think it's more emblematic of a bad programmer than a bad test. If you are writing unit tests, it forces you to structure your tests in a way that are modular, that are testable, that don't expose what's going on inside. I genuinely believe that if you unit test your code well, you will end up with a better design at the end of it. And it will also, yeah, exactly as I said, it will improve the design. So there are a couple of different ways to test your front end. One of them is functional testing. So this is a traditional way to test your application, your web app, which is to get Selenium to run through your code exactly as a user would. And that is definitely provide value. But unit testing your code provides a different kind of value. It provides assurance that any complex logic is well tested. It gives you the ability to test a lot more cases, specifically edge cases, than you would do using functional testing, where actually it might be quite expensive to go through a lot of different negative test cases running your script. Ideally, you would use both. But actually, I totally appreciate that testing can be quite expensive on a project, and that sometimes it might actually be worth making a sacrifice and only getting one of them. We're going to talk about unit testing today. There are some great references about how to write good functional Selenium tests. Again, these slides will be in line afterwards. So you can click through those links if you're interested afterwards. So let's talk about unit testing. When we talk about unit testing, we're talking about testing the isolated parts of functionality. It's worth just bringing up because JavaScript doesn't have a class system, we're not necessarily talking about testing classes the same way that people assume we are when we're writing C-sharp or Java code. Instead, we're talking about if you're using a modular framework, then great. It's brilliant if you can test around the edge of your modules. But I'm not going to assume that you are. So instead, we're talking about testing simple and small parts of a system. It can be very hard to do this in JavaScript. It is not as easy as in Java and C-sharp, where if you go to IDE and create a new project, you're automatically going to get an entire testing ecosystem set up in your IDE for you. So as I said, it can be hard. But there are lots of libraries that will help you, will support doing that. Before I leap into exactly what these libraries are, it's worth just quickly running through what a unit testing lifecycle looks like, just because sometimes with JUnit and men unit doing all of the work, we forget that there are distinct parts involved. First of all, we need to write our test. That's going to require having access to the language features that we need to define our test and the final insertions contained within. We need to create any necessary test doubles. So if we're interacting with something else, we need to mock that to stop its logic interfering with the logic that we're testing. There's a lot of great libraries out there that make assertions easier to read and easier to write and provide more functionality. And at the end of the day, nothing of the first three is going to actually run our tests and tell us whether there's success or failure. So when we start thinking about a unit test and a unit test ecosystem, we need to think about all four of these parts. So as I said, in JavaScript, we don't necessarily have any classes. So rather than the classes with methods on them, tests typically tend to be nested functions. And the standard idiom in JavaScript is to write these in a BDD fashion. So to use string descriptions of exactly the functionality that you want your units to have. There are two typical keywords in the big JavaScript frameworks, Jasmine and Mocha, which are describe, which describes what your unit test is actually testing, and this it keyword, which tells you what your JavaScript object should do. So this is an example of a test taken from the Mocha website. It's using this describe to talk about we're using, we're testing an array. And specifically, we're testing the index of method of an array. And this it is telling us what the functionality is. It should return minus 1 if the value is not present. So as you can see, the two assert.equals here are provided nicely by Mocha for us. So this is hopefully a very typical test structure that you would not be surprised to see in Java or C sharp, but using this describe in it functionality. I use Mocha as my example. It's lightweight. It's nice. We quite appreciate Mocha's flexibility because it isn't massively opinionated about all of your tests. It actually allows you to pick and choose other bits of the testing ecosystem you want to use if you have a particular use case for them, while still actually providing all the basic functionality you would want. Let's talk about test doubles. Test doubles, Martin Fowler, brilliant blog post about this. Essentially, they're just a way to provide very simplified objects to avoid any kind of contamination if you're lacking functionality in one part of your ecosystem. Lots of different kinds of test doubles, not as users of Makito think everything's a mock. There are actually a lot of subtleties within your tests. I put this up here because it's a massive pet peeve of mine because I'm not going into massive details. The thing to remember about JavaScript is that it's dynamically typed. We don't have strong static typing. And therefore, we don't need to go through all of the hassle that we might do in C-sharp of creating interfaces to mock and generics and anything like that. We can just do it ourselves. We can just create a very easy test double ourselves and throw it in because it's not expecting something of a particular type. We can just throw it in there. I'm aware I've taken for granted dependency injection, et cetera, beyond the scope of this particular point. So yeah, it's easier in JavaScript. This is exactly what your mock, et cetera, is going to be doing in C-sharp. But it's easy because of dynamic typing. If we wanted to start adding more complex functionality, there are libraries out there which will provide a lot of basic functionality similar to your Makito to your mock. And seeing on is probably the most mature. And so that is possible. But actually, we often find that it's not necessary in JavaScript. And that writing lots of test doubles and lots of mocks will artificially couple your modules together. So I always try as hard as I can to avoid test doubles if I can. The default assertions in your testing libraries are actually pretty good. But there are JavaScript libraries that will make them easier to read if you want to. So this is Chai. Chai will provide you with all manner of different kinds of assertions that are more sentence-based and will provide easier to read tests at the end of the day. And as discussed, you will need something to run your tests. Typically, these are done either in a browser. So you can actually get a web page that's running all of your JavaScript tests for you or a headless browser like Phantom.js. Or test runners are actually starting to utilize Node.js a lot more. So the Node.js JavaScript runtime is exactly the same as that of Chrome. It's the Chrome V8 runtime. And therefore, running your tests on Node will provide you assurance that your tests are going to work nicely in Chrome. So sometimes you don't even need to load up a browser these days. The typical test runners that we would choose to use are Karma, which is very stable, very well supported. No matter what other parts of your testing ecosystem you need to use, Karma will be able to support it. But also, we're finding that Wallaby.js is lovely these days. Wallaby.js is a relatively modern part of the JavaScript ecosystem. But it will clip onto your IDE, run all of your tests when if you change anything, and provide you green or red line by line coverage to tell you whether or not your this line is covered. And if it is, whether the tests that are covering it are passing. So if you use familiar with nCrunch, Wallaby.js is nCrunch for JavaScript. I want to talk briefly about building your code. We've talked so far about these things to improve JavaScript. We've talked about third-party libraries. We've talked about modules. We've talked about languages that will compile to JavaScript. We've talked about testing. What do these all have in common? Well, they are all things that require external processes to the JavaScript. So if we have a quick look, third-party libraries will need to be downloaded and pulled in. Modules will need to be turned into one single JS file for your web application to load. We'll need to compile our JavaScript when we're building it. And our tests will need to run so we don't deploy broken code. And so we need to start thinking about tools that we can use to automate this process so that we're doing it in an automated manner. When we talk about build tools, if you're familiar with any of these, this is the sort of thing we're talking about. We're talking about building them to the JavaScript ecosystem. We're looking at tools that are going to be doing all of the external processes that we need prior to deploying our code. We have found that grunt is our preferred build tool of choice. But we are actually on the eye out for a number of other build tools. I'm aware that Gulp and Broccoli are both very preferred build tools from some people. So we're keeping an eye out. But when we're working with actual clients, we're finding that the maturity of grunt is actually very useful. So grunt stores its configuration. That is the instructions that you need to build it in a grunt file. And these will contain any dependencies of the libraries you're using and any processes that you may want it to run. And these will be grouped into tasks that you can run with any number of these build steps in. Most of it is third party. It can be made to run from any other build we're using. So if you're running a Java project, you can trigger your grunt build from Maven, similar from this build. And so that means that you can actually make sure that your entire project's run if you click the Play button or from one single command line tool in a remote CI server. Looking at a grunt file, I'm not expecting you to read through all of this. I want to draw your attention to a few things. Firstly, these lines which are defining your tasks. So these are defining your JS hint process, which JS hint essentially provides you static checking and co-quality checking for your JavaScript. And what we're defining here is all of the config that we need to make sure that's running properly. We're also defining a watch task. And that's going to rerun the processes whenever what you're writing has changed. So it will provide you continual assurance that your JavaScript is of high quality. This on its own won't do anything, notably because it actually grunt by default won't know what JS hint and watch are. So we need to load these in using NPM, the Node Package Manager, which will make sure that these are in the file system before we run our code. And then finally, we can just register this task at the bottom, register task, default JS hint. And that means that if we run a grunt on the command line where the grunt file is, in the path where the grunt file is, it will run JS info. It's very easy to add more to this. If we want grunt to run our tests, we would add these lines. We would need to load our NPM task in. We need to load the Karma plug-in save. We want to use Karma to run our tests. We would then add some config. I notice that there's a typo on this slide. That should be config. We want to load that in so that grunt knows about Karma. And then we always simply do is register this task. So if we now go to the command line where the grunt file is and run the grunt test, it will run these processes for us. So grunt is a very simple thing to use. Its plug-in architecture is very powerful. There are plug-ins to do anything you want. All major testing ecosystems, compiling for almost all third party libraries. Compilers for almost all JavaScript libraries. It provides test coverage. If you are using SAS or less to make your CSS nicer, it will provide pre-compilers for that. And it will rerun certain tasks when watched files are changed. Grunt also works very nicely on a no-dk system. So now that we've done all of this, now that we've looked at all of the improvements that our JavaScript code could undergo, let's glue it all together. And let's start thinking about why we write front-end code. And at the end of the day, it's because we want to make websites that have logic in them. We want to make sure that our websites are responding to what the users are doing. As I mentioned before, server-side code is an option. You can use Razor. You can use JSPs or Timely for Java. And you can keep all of the logic about data in the server-side. But there are problems with this. It can be very slow. It has to do all the calculations on the server-side before it sends a response back. It forces a page refresh. And it limits the ways that clients can interact with your data, because it has to go back to the server every time. So the traditional solution to this problem was to use something like jQuery. So jQuery is a very famous JavaScript library. And it's very good for some things. It's great for manipulating your DOM. It provides you a massively beneficial wrapper around all of the DOM manipulation you're doing. And it will make Ajax requests to your API very nicely. And if it's JSON, it will interpret it brilliantly. So you can start writing your applications in a much more browser-driven way. So your browser will see the page. It will go and get the data. And it will put it on the page and form it nicely for you. But there's problems with this approach. For one thing, jQuery is massively bloated. Early JavaScript libraries were all basically bootstrapped onto jQuery. So you have things like jQuery. jQuery has all of your functional paradigms. And jQuery will give you extend functionality. And jQuery will re-implement global variables if you use push me pull you, which is a strange library. It contained everything. And it also did everything for you. And the problem when one library does everything is that all of a sudden you're mixing all of the concerns. If jQuery is managing your data, as well as working out how it's displayed, then you're mixing your concerns there. So if you ever want to change the way your data is displayed, you actually have to leap very quickly into the way it's brought into your code. So we're mixing all of these things. jQuery is not a bad library. jQuery has things that it is very good at. Use it for DOM manipulation and use it to wrap your Ajax requests. But recognize that there are libraries that are better at jQuery for everything else. And make sure that you're encapsulating these things in small places. So jQuery no longer just takes over your whole application. So if we're only using it for the DOM manipulation and maybe to make some requests of a server to find things out, well, where's that last little bit? Where's the bit that actually glues together for data that we're getting and how that's displayed in the front end? As I said, there's another library for this. This is exactly the same motivation that led to the MVC pattern, say, for web applications, where we're dictating what we're seeing based on the data that's being supplied to the application. And JavaScript's taking this MV star pattern by separating the concerns of getting, storing, working out how to shape the data with how it's displayed. And these are the frameworks that we're talking about like AngularJS, like KnockoutJS. So KnockoutJS is responsible for that top line of code. We're getting a view model, and we are putting the data onto that. And the KnockoutJS is responsible for making sure that the view is changed with this data stapled onto it. AngularJS does a very similar thing in a different way. There are loads of great MV star frameworks that we can start using to start splitting these concerns apart, that we can start splitting the model and the viewer part. Now that we've actually got these great language features in JavaScript, like modules, like third party libraries, this plug and play architecture, we can start using the more traditional RO patterns with great amounts of discipline. A quick aside as to which of the frameworks, AngularJS, KnockoutJS, et cetera, we prefer, our experience is relatively limited. We have used AngularJS and KnockoutJS more purely because they were big players earlier on in the ecosystem. We've shunned backbone much to some people's delight. We are keeping our eye on React number, but we haven't had a reason to leap massively into that space yet. There's a lot of talk about which of these two libraries is better. Essentially, it depends on what your use case is. We prefer Angular for big, large, complex projects. And we find KnockoutJS very quick and easy to add on to either legacy projects or very small projects. So that is everything I wanted to say about the middle, the present, the current JavaScript ecosystem of things that we might want to do. And I promised you that I'd try and sum it up nicely at the end by talking about the practical steps that we can go off on our projects on Monday and do. So what do we do now? What do we do now that we've got this information? And as I see, there are two points that I want to make here. And the firstly is if you're on a Greenfield project, what do you do? Because obviously, you can start from scratch. You can architect your system from scratch. And the first thing is make sure you treat your JavaScript with respect. Make sure you treat your front-end code with respect. You will very possibly be putting a significant amount of logic there now. So you can't shun it the same way that we did two, three years ago. It's a smaller time as that that these changes and this paradigm shift about JavaScript has happened. So I'm not saying you should have a crystal clear structure in mind when you begin. Evolving design is still a thing, and I'm still going to advocate for that. But do you think about the libraries and frameworks you're going to use the same way that you would think, oh, I'm going to use Spring. Think, oh, I'm going to use Angular. Do you structure your application in a potentially layered way or a modular way? And make sure that you're encapsulating your concerns. We have produced an ideal front-end tech stack at software. We also understand that every project is different, and that what works for one project may not work for others. But with that provider in place, this is what we would probably consider as a default when pitching for a new project. We like TypeScript. We would probably, where possible, like to avoid writing native JavaScript moving forward. Because TypeScript gives us a lot of the language features we miss writing JavaScript. We used Run-to-sab-builtle. We're keeping an eye on others. But this is a mature, stable one that we've got knowledge of in-house at the moment. It will compile and minimize our TypeScript and also run all of our tests. We like the lightweight ecosystem of that Mocha provides with the flexibility to add Chai, Synon, and Karma as well. We'll put Wallaby.js in our IDEs to make sure that our tests are being run continually and to get as close to 100% coverage as is feasible. And we use AngularJS for projects that will run for a longer time. But we also recognize that Knockout.js is great for small projects or projects with a lot of new starters on or junior developers on that actually we want to ramp up very quickly. But that's the easy one. We're starting out from scratch. What's our ideal development process? So what do we do if we want to migrate our legacy JavaScript? It's rarely feasible to start from scratch. It's rarely feasible to throw everything away and start again. So instead, what we want to do is we want to try and identify some quick wins. Firstly, this should be a principle on every project, the Boy Scout rule. Leave the code base cleaner than how you found it. Whenever you go in, whenever you work on code, make sure this is anything that you don't like, you can change it. Make sure you've got buy-in from your team to actually invest a little bit of time in making these improvements. Am I great away from any old language features and towards a better tomorrow? That sounded corny. Add a build tool. Do this early. At the very beginning, when you're not using any of the other improvements that I've suggested today, it will seem like an absolute waste of time. But it will unblock future improvements that you'd like to make. And it will increase. It will become much, much more difficult to do this as time goes on. So build this into your process early. Migrate to modules gradually. Modularization will significantly improve your code's maintainability. It is probably the best thing that we can use to migrate away from the JavaScript of five years ago. Test your code. Once you've started modularizing it, unit testing can be added. But I don't think that's where the value on legacy code lies. I think that the JavaScript that you've written, even the legacy JavaScript that you've written, is actually going to be very hard to test, because it wasn't written with that in mind. So instead, I think that the value that comes on a legacy project is from adding full stack Selenium integration testing. Because that's going to test the functionality that you've written, still guard against regressions, but not require significant refactoring of the JavaScript code. And we actually quite like knockout on legacy projects. Knockout can be added gradually. It's very easy to put in very key strategic places, where, say, a lot of jQuery, DOM manipulation, data mess ups are going on. So it's very easy to add incrementally. We don't recommend quarantining the old bad code and starting again. I've seen enough code bases in my time that look like trees, in that if you cut them down, you can see rings of the code base that age the project, and age when the file was written. You've got the ring in the middle of ASP 1. You've got the ring on the outside of ASP 3, and then moving toward single page applications, and then migrating to TypeScript. That is going to do nobody any good. It also doesn't help that JavaScript has a nasty habit of modifying global scope. So actually, you may think that you've hidden all of your problems in old JavaScript away, but it will come back to bite you. And the person who works on that code is probably going to leave your company in two months. And we also don't recommend attempting to adopt a massive code base shaping library. AngularJS is brilliant. It provides a lot of easy additions when you are starting on a new project. But actually, the cost of migrating across to it can be very hard. So your front-end code should be first class. You should be architecting with that in mind. There's the text that we recommended a few minutes ago. And as I said, even if you don't have the chance to migrate to that full text stack, there are still quick wins that you can do. So these are the recap slides that you've seen already. And I'm aware that I've been keeping you longer than I should. So that was everything I wanted to talk about today. Unfortunately, I've run out of time. So I don't have time for questions. But I'm going to be around for the next two and a half days of the conference. So if anybody sees me, feel free to grab me and ask questions then. So thank you. Thank you.
 Everyone, can you all hear me at the back?  Is everyone OK?  Excellent.  I'm going to warn you now that you are getting a talk from me  just recovering from tonsillitis.  So I am very sorry if my voice doesn't quite hold out  to the end.  But I made it here to talk to you today  about high quality front end.  Just before we leap on into the content of the talk,  I'll just let you know that the slides are available online.  They're already here at this URL.  I'll tweet a link to them at the end of the talk as well.  So don't feel as though you have to be constantly scribbling  notes.  Hopefully, I'll make my way through the slides relatively  quickly today.  There are a lot to get through.  So you can go here afterwards and hopefully reflect  a little bit more on the information  that I'm giving you during this talk.  While people are shuffling into the back,  I'll get the formalities out the way.  I'm David.  I am Sparmish Turtles on all social media worth mentioning,  Twitter, GitHub, the internet.  I'm a tech lead at SoftWire, working  with open source technologies.  And my background is in statistics and simulations.  So my experiences with front end have  been more on the data visualization  and the business insight side.  My boss has told me I had to include this slide.  SoftWire is a software consultancy  that deals with every aspect of the software lifecycle.  We've got a lot of projects running at any given point.  And I have been told to ask, if anybody's  got a software project, they're looking to outsource  to come and speak to me at the end of the talk.  That is, however, the only.  Sorry, there are seats down at the front and on this side,  if people want to shuffle around.  Yeah.  Yeah, there's quite a lot of seats in the middle of Ray.  So if people want to move it down just to try and hopefully  get people seats, it's quite a full talk.  This is the only slide in which I'm going to tell you.  And I think we can forget about that now  and get on with the technical side of things.  But I did want to bring up that what I'm telling you today,  I'm not going to tell you anything bleeding edge.  I'm not going to mention any massively innovative JavaScript  libraries or anything like that.  What we're bringing you today is hard-won experience  over the last year, two years of working with Frontend Code.  Knowledge that we found out as a company  by working with a lot of different projects on the web.  So specifically, what I'm hoping to talk to you about today,  I'm going to talk to you about three different things.  Firstly, the past.  So what is JavaScript's legacy?  How have we gotten to where we are today?  And then the bulk of the talk is going  to be talking about the modern JavaScript ecosystem,  the modern JavaScript libraries that you'll  want to use in order to make a nice, clean frontend  for your site.  And then hopefully, by the end of the talk,  you'll have some practical next steps to go away with and to try  and apply on your projects.  So specifically, we're going to be talking about JavaScript  today.  We're going to look at the problems with JavaScript,  the impacts that they'll have on a project,  and then hopefully look at a broad range of native solutions  to them, look at potentially other languages  that we can use to supplement JavaScript,  and then the third-party libraries  will add to the quality of our code base.  Sorry to disappoint if you're here for any of these things.  We're not looking at any HTML or CSS.  We're not going to be looking at Node.js or any server-side  JavaScript.  There are some great talks today about future versions  of ECM script and other JavaScript libraries,  including React and so on.  And there are some great talks about that this week,  but we're not going to go into too much detail here.  So sorry if I'm disappointing.  Feel free to find another talk in this slot,  if that is what you're looking for.  You're all staying, so I assume that this is hopefully  something that you want to hear about.  So firstly, let's think about where we are at the moment.  Where does JavaScript come from?  How did we end up where we are?  And I want to give you a very brief introduction to JavaScript,  both in the computer science realm  and my personal history with JavaScript.  So it was originally written in 1995.  It was there to support user interaction.  It was there to be rendered on web browsers.  It was the only thing there that could really,  at that point, in the internet give interactive script  on web pages.  Things have come and ebbed and flowed  and things have gone away again.  But JavaScript has been the only real constant  over these last 20 years of web development.  It is interpreted by browsers according to a set of rules,  which is this ECM script.  You're going to be hearing a lot about future versions  of that this week.  And it was originally intended as a combination  of a scripting language, functions for first class  objects, so there's a lot of functional paradigms there  as well, and there's also a bit of object-oriented nature  in there, but not the way we understand it  from C, Shaf and Java.  Hopefully, you already know that.  So I want to talk about my personal history of JavaScript  and my first ever encounter with this now famous language  was from a site called Dynamic Drive.  I don't know if any of you have heard of that.  Essentially, what it did is allowed people to go and copy  and paste JavaScript that made your website look awful  and perform really badly.  So this example here is it allowed you to go and get snowflakes  falling down your screen, if that's what you wanted.  And people just copied and pasted it  and plonked it in the middle of their site  and had no idea what Earth was going on  and tinkered with some valleys here and there  in order to actually get the site to look as awful as they  wanted it to.  And this was JavaScript back in, it must have been 2002 now,  and that is how all of my friends  learned what web development was back in the day.  I mean, there were probably more professional outfits  that didn't quite copy and paste snowflake graphics,  although if you look at the Space Jam website,  they are still using their original JavaScript  from however long ago that was.  Things may have been done better in other places,  but if people were doing better, it  wasn't because JavaScript supported them  and supported what they were doing,  it's because they realized they needed discipline  to fight against the problems that JavaScript was causing.  What problems are they?  I'm going to issue a slight provider at this point.  I'm going to list a load of problems  that people think that JavaScript has.  I don't necessarily agree with all of these problems.  I think in a number of cases, what people perceive  as problems with JavaScript are actually  surprises about JavaScript because people  have come into web development from a Java or a C-sharp  background and they're like, oh, JavaScript  isn't behaving exactly as I would expect it to coming  from these languages.  And well, to some extent, that is the point.  But at the same time, we found even  if these are language features rather than language bugs,  they do catch people out again and again,  and they are impacting our ability to develop for the web.  The big problem that JavaScript had back in the early days  was that there was no ability to separate it down  into separate files or no easy way  to do that in any meaningful way.  So people just used to put one big lump of files there,  expressing a large number of global variables  that would eventually just either start conflicting  with each other or become an unmaintainable mess.  There was no easy way to encapsulate code, which  meant that there was no real code reuse.  And because of that, it was very hard  to separate out the bits of functionality  that you wanted to test.  It was very, very hard to unit test.  And this is because of the era from which Java came.  Automated testing hasn't been around  as a expected standard of code development for that long.  And JavaScript, because of it, didn't really  have JavaScript wasn't built with that in mind.  People complained about the lack of JavaScript's classes.  Now, I think this is one of the places  where it's not that JavaScript is bad,  it's that JavaScript is unexpected.  But people, especially object-oriented developers  that have moved into the front end space,  have come to expect classes when they write their code.  They've come to expect the ability to inherit from other places.  They've come to expect polymorphism as a way  to control their logic flow as their writing code.  And when they come to a language that doesn't have this,  they have a struggle and flounder,  or they try and invent libraries that will reverse engineer  these features into the code itself.  And we look at libraries like jQuery Extender.  We'll do exactly that.  People don't like the way that JavaScript  manages its scoping.  So JavaScript uses functional scope.  That is, a variable is defined exactly within the function  in which it is defined.  This console.log here is actually  going to upper undefined, but the one inside the function  will up at 7 purely because local var ends its definition  at the bottom of that funk.  People are surprised about this.  It doesn't work the same way that object-oriented languages do.  It is a slightly bizarre, different way of doing things.  Again, if you've learned JavaScript as your first language  and know it all your life, then fine.  Great.  It's a normal way to do things.  But there are certain implications to the OA developer.  For example, people don't have private variables anymore.  I mean, you can define a variable inside the function  and expose it through the return value.  But that's a couple of steps removed from the very easy way  that you can define fields in C-sharp.  And people always complain about its type system.  This isn't going to turn into another talk in which we  discuss all the obscenities with JavaScript's casting.  But there are some very odd behaviors.  We don't need three undefined or error types in a language.  They don't really add much to each other.  Here's a little quiz.  See if you can work out what each of these are going to be.  If you can get 5 out of 5, I'm very impressed.  I mean, it's just, well, OK.  If you want to do that, that's fine.  And JavaScript also has the concepts of truthy and falsy,  rather than true or false, which, again,  can be seen as a very good feature of the language.  But if you're not expecting it, well,  it's surprising to say the least.  The last thing I want to talk about  before we go on to actual advice about improving  the cleanliness and quality of your code  is to hopefully step back a little bit and say, well, OK,  you're going to go into work on Monday,  and you're going to want to implement all of these lovely  things that you've seen in this talk.  But your project managers are going  to say, why?  You have to give me the use case for this, the business  case for this.  So I just want to pop this in here  to hopefully give you the ammunition you  need to complain to your project managers.  We can talk all day about why we want to use clean code.  There are excellent books written on it,  the famous one being by Uncle Bob, very, very good book,  explaining the principles of object-oriented clean code  design and the benefits of using it.  To summarize it briefly, if your code is more readable,  then it's going to be easier to maintain.  You're going to reduce the support costs of your code,  because if you've got bugs, you can pinpoint exactly where  they are a lot more easily.  You can hand over your code to another developer  a lot more easily.  If you're encapsulating your code properly,  then it will be easier to replace  the benefits of a system as your architecture grows  and your requirements change.  Enhancements for code, so feature requests  are broken into smaller bits, so it's easier to follow  in your mind.  And if you're testing your code, well,  hopefully we all agree that we should test our code,  but it does provide assurance that our code is working  as it should.  It's providing documentation as we go along.  And if we build our code with testing in mind,  then it actually enforces good design principles,  such as the single responsibility principle  when you see your test.  There's a big question as to why JavaScript  is receiving the attention it is now.  There's no definitive answer to this.  There's no definitive answer as to why  we want to improve our JavaScript in the next month  to a year.  To some extent, web development is becoming a much bigger  topic now, but that's actually been true for a good two  to five years.  So that doesn't really explain at all.  JavaScript as an ecosystem, rather than as a language,  is becoming significantly bigger.  Node.js is now a very mature server-side language  if you want to write JavaScript down to the mid-tier layer.  But also, a lot of databases, a lot of no SQL databases,  are using JavaScript as a query language as well.  So especially looking at things like the mean stack,  Mongo Express Angular Node, you can see JavaScript now  becoming a language that we use across our whole system.  And also, I think to some extent, developers  have become a lot more picky in the last five years.  The rise of Silicon Valley has meant  that there's a lot more jobs.  We can be a lot more choosy about what we want to do.  The mid-tier layer has become actually very mature  and very lovely to work on, layer.  Look at what the JetRainers is doing  to make development like a really seamless experience.  And because of that, we can start  looking at other areas of code where we don't enjoy working.  And start issuing a lot more demands.  We can hold our project teams to ransom  because of how fussy we're becoming.  That's just a pet theory of mine.  So I asked, how do you convince your project managers  to invest in the improvements I'm going to suggest today?  Poorly written code is expensive.  Poorly maintained code is expensive.  Poorly understood code is expensive.  We want to be pushing for nice, easy-to-use code.  And that will fit into their objectives as well,  because it will allow us to quickly deliver functionality,  quickly extend our teams, and quickly support our code.  The bottom line is that bad software is expensive.  And JavaScript has been quite bad for quite a long time.  So talking about the past, JavaScript is basically  our only choice if we want to run complex client interaction  on the front end.  And due to historical context, it is actually  quite an unpleasant language to work with.  But fortunately, we actually do have the motivation  to change it if we want to make our software project successful.  So hopefully I've convinced you that JavaScript and JavaScript  projects have been neglected for quite a while.  So now let's look at what we can do better when we're  looking at our JavaScript projects.  And then first of all, going to start looking.  Without making any changes to the tooling or the libraries  of the frameworks we use, can we just approach writing our line  by line JavaScript in a more mature way?  People say that a bad workman blames its tools.  And if you start complaining about JavaScript on your project,  it is probably true to some extent that you're fighting  JavaScript.  JavaScript comes with a lot of idioms  that are different to the object-oriented development  paradigms of C-sharp and Java.  So if you're going to try and put inheritance  into your JavaScript code, you're probably  going to be fighting against it.  And that's going to be more pain than it's worth down the line.  But saying that, I also think it's true  that if a language forces you to fight it,  then it's probably not a good language.  So I'm not going to stand here and evangelize to all of you  that your JavaScript code is awful  and that you are bad people.  But it is fair to say that maybe if you align yourself  to some of JavaScript's more interesting features,  that you can actually get a lot of value out of this  before we start investing in significant architectural  or tooling changes.  So first of all, we have to understand  JavaScript's language features.  You have to know the language that you're writing.  A little while ago, a new JavaScript framework  called vanillaJS was released.  VanillaJS promises to be a fast, lightweight,  cross-platform framework for building  incredible, powerful JavaScript applications.  And it offers all of these different functionalities.  It went around a bit.  People were quite excited about this.  And then they slowly dawned on them.  The vanillaJS isn't a framework.  This is all stuff that JavaScript  can do out of the box.  JavaScript has got closures in it as a first-class citizen.  It's got functions.  It's got functional paradigms.  You can easily write DOM manipulation and Ajax requests  using native JavaScript.  There is lots of misunderstanding  about what JavaScript does as a language.  I'm blaming jQuery for this.  And I'll rant a little bit more about jQuery later  in the talk, something to look forward to.  But at the end of the day, you have  to recognize that JavaScript can do a lot of things  you want it to do.  And sometimes when you're leaning on a third-party library,  you don't need to do that.  It's also important to consider that JavaScript  isn't your favorite language of choice.  I bullied C sharp here because this is ostensibly  a.NET conference.  But I could have chosen any language with which people  are familiar.  You don't have classes.  That is not a thing that really exists in JavaScript.  It doesn't exist yet in JavaScript.  You don't have all of these paradigms  of classical inheritance.  I know I've ranted about this a couple of times already  in this talk, and we're only 17 minutes in.  But I really strongly believe that one  of the biggest problems of JavaScript two, three years ago  is that people were like, OK, JavaScript is a bad language.  Let's make it a good language.  What language is good?  C sharp is good.  Let's make it C sharp.  And you'll doom to fail if you're doing that,  because you're just going to be fighting  against the paradigms of the language.  You don't have strong types.  Don't pretend that you do.  You can use prototypical inheritance if you want to,  but then actually understand prototypical inheritance  and understand where it differs from classical inheritance  if you want to use it as a major architectural point  of your application.  JavaScript is functional paradigms as well.  It is a functional language.  So if you can use functions like map and filter and reduce,  so this is very similar to the link of the.NET world,  all of these are native to the array prototype  as of IE8 and above.  If you're having to support IE6 and 7, first of all,  I'm very sorry.  But also, you can import libraries  like load- or underscore, which will add those in for you  as well.  So you've got no excuse not to be using a lot of the lessons  that functional programming has given us.  Stop iterating through for loops.  You don't need for loops anymore in JavaScript,  because mapping will do exactly what you need for you,  or filtering will do that for you.  So let's start thinking about what  happens if we're prepared to start making changes to the way  within which we are writing and using our JavaScript.  So let's assume that we're willing to add more tools.  Well, the JavaScript ecosystem is actually  very big these days.  The JavaScript ecosystem has a large number of modules.  If you look at the number of libraries  that the ecosystem contains, then NPM  has overtaken Maven and is increasing at a much faster  level.  So it may not have everything that you need built into it,  the same way that Java 4c sharp has a lot more functions  than JavaScript.  But it's now become a very community-supported ecosystem.  So if there's something that you're missing from your application,  you can just take it from this open source community  and plug it into your application.  Almost everything you would like to do in JavaScript,  a plugin already exists for.  And you're going to hear me use the phrase a lot over this talk.  There's a JavaScript library for that, because there is.  There is a JavaScript library for almost everything.  That was to training some of our devs at Softwire about JavaScript  and showed them a slide very similar to this  and challenged the six of them in the room  to come up with a common English word for which there was not  a JavaScript library named after.  The six of them failed.  There is almost a one-to-one mapping  between English dictionary words and JavaScript libraries.  It has become that extreme.  If you want to start using these libraries,  you can just download them from the internet,  throw them into your application.  I don't like that.  It doesn't give you the ability to update your libraries.  There's a version of a third-party libraries increase.  And also it encourages people to go and tinker with those libraries  and to do slightly more what they would like to,  despite the fact as it deviates from your online versions.  So there are package management tools for JavaScript.  Bower is the typical one that we use for frontend.  NPM is what we typically use for our server-side code.  And these are the equivalent of, say,  NuGet for the.NET ecosystem and Maven for Java.  We talk a little bit about Bower.  So Bower is this package management tool.  It manages its own central repository of JavaScript libraries.  And then it also provides a command line interface,  which allows you to download the libraries from this central  ecosystem.  And it also provides a syntax for this Bower.json file  that defines the dependencies that it has.  Typically, if you wanted to install a library using this,  you would use a command line interface,  remembering, as always, in JavaScript, the dash-save flag,  which allows it to be saved so that other people on your team  will also install it when they get the latest version of the code.  OK.  Bower has almost all of the interesting JavaScript libraries  in it.  I'm just going to mention a few of them of particular interest,  either to myself or hopefully to you as well.  D3, standing for data-driven documents,  is a library that exists to take your DOM, take your HTML page,  and slightly change the nodes in your DOM based on data  that you provide it.  It's a very, very low-level library,  and it provides a lot of good use cases, especially  around SVG mutation.  However, we almost always use it now in its wrapped form  for with chart.jsc3 and MVD3, which  all wrappers around D3, which provide good charting support.  Numeral.js in my moment, these are very useful tools  when we're dealing with forms or validation or displaying data  from a database back to the user.  We give a format string to the library  and also just a raw string that a user may have inputted.  And then we're able to format these strings nicely  according to numbers, money, units, say, and date and time  for a moment.  And then it also provides a lot of domain-specific methods  on top of this.  So if you find yourself in JavaScript  writing a lot of custom validation logic,  or find yourself writing a lot of date manipulation logic,  string manipulation logic, there's  a very, very good chance that this already exists out there.  You don't need to reinvent the wheel.  And then just a couple more libraries,  Q, which provides promises to JavaScript, which  avoids callback L, and low-dash, which,  if you're not working with IE8 or above,  will provide a lot of functional idioms and also actually  add some top of what the array prototype will provide you.  So this is a nice way to start actually utilizing  the fact that JavaScript, at its very core,  is quite a functional language.  So these are all third-party libraries that we can use.  And they're nicely encapsulated.  They provide one thing.  And so it's now time to start thinking  about how we can organize our code in that equally modular  structure.  To break our code down, so instead of having  this one big file problem that we talked about earlier  in the talk, we can start breaking our code down into modules.  So a brief introduction to what a module is,  a self-contained piece of code, traditionally one that doesn't  really express its internal affairs,  so that we can integrate with our modules  and integrate our modules together  through very defined interfaces at the edges of our modules.  So in C-sharp, this could be something like a class,  but also actually C-sharp provides name spaces  if we want to think at a bigger level, and class libraries  if we want to think about an even bigger level than that.  JavaScript doesn't really provide any of this.  We can write JavaScript in files,  and we can put different concerns in different files.  But actually, very traditional JavaScript  doesn't provide a nice way to ensure  that the internal dealings of that class aren't exposed.  So our patents will help us with this,  but there, again, you're fighting against the ecosystem  if you choose to use them.  So as I mentioned, JavaScript design patterns, brilliant book.  I recommend reading it if you can.  It has an example of how this might work.  And it's, again, using this idea of functional scope.  So we define this module, so that's  looking at the top and the bottom line of this.  And because of functional scope, we  are able to encapsulate anything we don't want to expose  inside this module.  So this foo variable is not possible to be accessed  by anywhere else in our code.  And instead, we're returning a subject that  provides access to it in very specific defined ways  as we would like it to be exposed.  And this module is good.  In fact, it's necessary if you're not  willing to go into third-party open source libraries,  but it is very possible to actually get this from elsewhere.  So we don't need to reinvent the wheel.  First thing to say is that it is coming to native JavaScript  as of the next version of ECMAScript.  The reason I've not been assuming that we can use that,  up until now, is, A, there are better  talks about that this week than mine,  but also because the browser support for that  is not yet complete.  This is a graph showing the major browsers  and how much of the ECMAScript 2015 spec  that they have implemented.  Chrome, Firefox, and Edge were doing fairly well,  but Safari in particular, and IE, as always,  are quite far behind.  So we can't actually assume that users  are going to have access to these native modules.  So instead, I want to talk about a third-party library that  will add modularity.  This isn't the only one by any means,  but it's the one that we've had the most experience  and success with, the software.  And that's RequireJS.  So RequireJS is a module-lating framework.  By that, we mean you can define modules.  The modules will not leak any of their internal affairs  unless you choose to release it.  And then you can share and add dependencies  between all of these modules as you go.  Require by default will take an entry point  into your application, and then it  will work out the tree of dependencies  that you need in order to have all the functionality necessary  for that module.  Modules can be your own code.  You can write your own modularized JavaScript.  But most third-party these days will also support RequireJS  as a module-lating system that you can use to share  the third-party functionality.  So if we just look at how RequireJS would work,  it adds this define global variable to your application.  So when you start talking about this module,  this define says, right, I'm defining a module now  that other things can use if we choose to.  You then list all of its dependencies,  and then you just assign them JavaScript variables.  And then inside this module, you can do whatever you want  with the variables and return exactly what  you would like at the end.  So potentially a way to modify the state of this module,  but also potentially the result of some calculations.  That module can be a function itself.  It can be any kind of JavaScript object.  So it could be a function.  It could be an array.  It could be a primitive.  Absolutely fine.  So just an example of how this might work  is if we've added the load-functional language.  The load-functional library to our project,  we can define a module that takes in load-insidependency  and then run this code, adding one to each of the array.  It will end up returning the array 234.  So we can add modules in that way.  So we talked a little bit about JavaScript's failings  as a language.  We've talked about the problems.  And we've also talked about the libraries  that we can add onto JavaScript if we wanted to add more  functionality or try and solve some of these problems.  So you might be asking, well, actually,  it sounds like we're doing a lot of work  to actually fight the language.  Why can't we just dump JavaScript?  Why did we just say, this is an awful language.  I'm never going to use it again.  What are the alternatives that you could use?  I mean, Flash and Java applets will provide functionality  for your clients.  But these are significantly outdated.  And the final nail in Flash's coffin  was when the iPhone chose not to support it.  And there are options around server-side rendering.  And these are definitely good options for projects  with simple client interaction or very minimal client  interaction that just needs to display data  that you get from a database on loading the page.  It's very possible that server-side rendering  will be entirely sufficient.  But it's not always going to be the case  that server-side rendering is enough.  Server-side rendering does have problems  when it comes to when you have to make lots of requests  to a server or when you need to do complex interaction.  So sometimes JavaScript is the only option.  So when we think about JavaScript  and the problems that it's got and our desire  to try and avoid writing using it,  I want you to cast your mind to Java.  And I want you to cast your mind to this architecture  that you may have seen before, which  is the motivation behind the JVM.  So we wanted to write code that would be able to run on both  Unix and Windows.  And the way to do that was to implement  separate virtual machines that can run on either of those  two operating systems and then define a language, a pseudo  assembly language that would be able to run on either  of these two machines that Java would compile down to.  People thought that Java had problems.  People thought that Java was verbose.  It wasn't particularly functional.  It lacked features.  And it was a very committee-driven language.  And so people wanted to write their own languages.  And rather than having to write their own new JVM,  they actually tried to write languages  that would either compile down into the Java itself  or compile directly into Java bytecode.  They would solve some of these problems.  And so when I look at the JavaScript ecosystem,  we see a very similar pattern that we did when we were  looking at the Java ecosystem.  We've got a couple of different environments  that we wanted to run on.  There is essentially a VM.  I mean, it's not a VM.  It's a runtime engine.  They're sitting inside these two browsers.  And then JavaScript is running directly on those two  via this runtime.  So there's no reason why we couldn't take the same solution  that Java had and write in languages that  will compile down to JavaScript.  And that's what's been done over the last 5, 10 years.  So there are now languages that will compile to JavaScript  and almost use JavaScript as the equivalent of Java bytecode  in the browsers.  There's a large number of different libraries  that can do this.  More than I can name.  So there is a link there that you can look at to see a lot more  about this ecosystem.  There were early adopters that seem  to have come into the scene and slowly depleted  until they're no longer massively supported.  So we're looking at things like Kotlin, LiveScript,  and ClosureScript there that still are used on projects  but lack the maturity for some of the other ones to do.  And in fact, a lot of these other languages,  Java, Ruby, Python, C-Sharp, all have compilers  that will compile them down to JavaScript.  But the problem there is that they're not really  designed to be run on the front end.  And so the languages and how they work with JavaScript  are not that intuitive.  So instead, the two languages that are currently speaking  have come out on top of this big battle  to become the best compiled JavaScript language are  TypeScript and CoffeeScript.  It's early days in this site, and I'm  sure there'll be a lot more challenges coming  in the next three years.  But it looks like TypeScript is becoming the favored language.  It's supported by Microsoft, so it's  got a fair amount of maturity behind it.  And we've actually found working on different projects  in TypeScript and CoffeeScript that we do  prefer TypeScript as a language.  CoffeeScript is absolutely fine, but it suffers a little bit  in tooling, and it also suffers because it is different  to JavaScript, whereas TypeScript is a superset  of JavaScript.  So we can always fall back to native JavaScript  if we choose to.  Just to give you a brief overview of TypeScript  as a language, it is strongly typed, hence the name.  And therefore, a lot of the benefits  that you get in your IDEs, or with compile time type  checking that you get with your traditional LRO languages  you're getting in TypeScript.  It adds missing features to JavaScript,  so it has got classes.  It's got modules.  It comes with the same package manager.  And it is backwards compatible with other existing  JavaScript libraries because, well, it is a superset of JavaScript,  so you will be able to just import them in.  But also, so that you can use them in an idiomatic TypeScript  way, there's an open source project that's built around  adding static type checking to these JavaScript libraries.  So just looking at some TypeScript code, it's very different,  in theory, to JavaScript.  We've got classes.  We're using classes in the same sort of way  that we're using in C-Shop and Java.  But you can actually see some of this JavaScript  being used here.  So when TypeScript doesn't add exactly what we want,  it's giving us this ability to just fall back  to the native JavaScript.  We're adding types to our methods.  So the return types, we're also adding them to our variables.  But they're optional.  We don't need to give it a type if we don't want to.  It's just there at compile time to check if we do.  Let's talk about JavaScript testing.  We've already briefly touched upon why we test code.  So I'm going to very quickly zoom through this.  It reduces regression.  So if we've got tests in place to make sure  that our functionality is working as we programmed it,  if we make a change that breaks something down the line,  we'll catch it.  It reduces bugs in old features.  And it also reminds us if we have changed something  in a new feature.  It makes sure that we've considered every edge case.  It makes our code more maintainable.  I do not necessarily agree with this idea of testing  juice design damage.  I think it's a lovely idea.  But actually, I think it's more emblematic of a bad programmer  than a bad test.  If you are writing unit tests, it  forces you to structure your tests in a way that are modular,  that are testable, that don't expose what's going on inside.  I genuinely believe that if you unit test your code well,  you will end up with a better design at the end of it.  And it will also, yeah, exactly as I said,  it will improve the design.  So there are a couple of different ways  to test your front end.  One of them is functional testing.  So this is a traditional way to test your application,  your web app, which is to get Selenium  to run through your code exactly as a user would.  And that is definitely provide value.  But unit testing your code provides a different kind  of value.  It provides assurance that any complex logic is well tested.  It gives you the ability to test a lot more cases,  specifically edge cases, than you would  do using functional testing, where actually it  might be quite expensive to go through a lot of different  negative test cases running your script.  Ideally, you would use both.  But actually, I totally appreciate  that testing can be quite expensive on a project,  and that sometimes it might actually  be worth making a sacrifice and only getting one of them.  We're going to talk about unit testing today.  There are some great references about how  to write good functional Selenium tests.  Again, these slides will be in line afterwards.  So you can click through those links  if you're interested afterwards.  So let's talk about unit testing.  When we talk about unit testing,  we're talking about testing the isolated parts  of functionality.  It's worth just bringing up because JavaScript doesn't  have a class system, we're not necessarily  talking about testing classes the same way that people  assume we are when we're writing C-sharp or Java code.  Instead, we're talking about if you're  using a modular framework, then great.  It's brilliant if you can test around the edge of your modules.  But I'm not going to assume that you are.  So instead, we're talking about testing simple and small parts  of a system.  It can be very hard to do this in JavaScript.  It is not as easy as in Java and C-sharp,  where if you go to IDE and create a new project,  you're automatically going to get an entire testing ecosystem  set up in your IDE for you.  So as I said, it can be hard.  But there are lots of libraries that  will help you, will support doing that.  Before I leap into exactly what these libraries are,  it's worth just quickly running through what  a unit testing lifecycle looks like,  just because sometimes with JUnit and men  unit doing all of the work, we forget  that there are distinct parts involved.  First of all, we need to write our test.  That's going to require having access  to the language features that we need to define our test  and the final insertions contained within.  We need to create any necessary test doubles.  So if we're interacting with something else,  we need to mock that to stop its logic interfering  with the logic that we're testing.  There's a lot of great libraries out there  that make assertions easier to read and easier to write  and provide more functionality.  And at the end of the day, nothing of the first three  is going to actually run our tests  and tell us whether there's success or failure.  So when we start thinking about a unit test  and a unit test ecosystem, we need  to think about all four of these parts.  So as I said, in JavaScript, we don't necessarily  have any classes.  So rather than the classes with methods on them,  tests typically tend to be nested functions.  And the standard idiom in JavaScript  is to write these in a BDD fashion.  So to use string descriptions of exactly the functionality  that you want your units to have.  There are two typical keywords in the big JavaScript frameworks,  Jasmine and Mocha, which are describe,  which describes what your unit test is actually testing,  and this it keyword, which tells you what your JavaScript  object should do.  So this is an example of a test taken from the Mocha website.  It's using this describe to talk about we're using,  we're testing an array.  And specifically, we're testing the index  of method of an array.  And this it is telling us what the functionality is.  It should return minus 1 if the value is not present.  So as you can see, the two assert.equals here  are provided nicely by Mocha for us.  So this is hopefully a very typical test structure  that you would not be surprised to see in Java or C sharp,  but using this describe in it functionality.  I use Mocha as my example.  It's lightweight.  It's nice.  We quite appreciate Mocha's flexibility  because it isn't massively opinionated  about all of your tests.  It actually allows you to pick and choose other bits  of the testing ecosystem you want to use  if you have a particular use case for them,  while still actually providing all the basic functionality  you would want.  Let's talk about test doubles.  Test doubles, Martin Fowler, brilliant blog post about this.  Essentially, they're just a way to provide very simplified  objects to avoid any kind of contamination  if you're lacking functionality in one part of your ecosystem.  Lots of different kinds of test doubles,  not as users of Makito think everything's a mock.  There are actually a lot of subtleties within your tests.  I put this up here because it's a massive pet peeve of mine  because I'm not going into massive details.  The thing to remember about JavaScript  is that it's dynamically typed.  We don't have strong static typing.  And therefore, we don't need to go through all of the hassle  that we might do in C-sharp of creating interfaces  to mock and generics and anything like that.  We can just do it ourselves.  We can just create a very easy test double  ourselves and throw it in because it's not expecting  something of a particular type.  We can just throw it in there.  I'm aware I've taken for granted dependency injection,  et cetera, beyond the scope of this particular point.  So yeah, it's easier in JavaScript.  This is exactly what your mock, et cetera,  is going to be doing in C-sharp.  But it's easy because of dynamic typing.  If we wanted to start adding more complex functionality,  there are libraries out there which  will provide a lot of basic functionality similar to your  Makito to your mock.  And seeing on is probably the most mature.  And so that is possible.  But actually, we often find that it's not necessary in JavaScript.  And that writing lots of test doubles and lots of mocks  will artificially couple your modules together.  So I always try as hard as I can to avoid test doubles if I can.  The default assertions in your testing libraries  are actually pretty good.  But there are JavaScript libraries that  will make them easier to read if you want to.  So this is Chai.  Chai will provide you with all manner  of different kinds of assertions that are more sentence-based  and will provide easier to read tests at the end of the day.  And as discussed, you will need something to run your tests.  Typically, these are done either in a browser.  So you can actually get a web page  that's running all of your JavaScript tests for you  or a headless browser like Phantom.js.  Or test runners are actually starting to utilize Node.js  a lot more.  So the Node.js JavaScript runtime is exactly the same as that  of Chrome.  It's the Chrome V8 runtime.  And therefore, running your tests on Node  will provide you assurance that your tests are going to work  nicely in Chrome.  So sometimes you don't even need to load up  a browser these days.  The typical test runners that we would choose to use  are Karma, which is very stable, very well supported.  No matter what other parts of your testing ecosystem  you need to use, Karma will be able to support it.  But also, we're finding that Wallaby.js is lovely these days.  Wallaby.js is a relatively modern part of the JavaScript  ecosystem.  But it will clip onto your IDE, run all of your tests  when if you change anything, and provide you green or red line  by line coverage to tell you whether or not  your this line is covered.  And if it is, whether the tests that are covering it  are passing.  So if you use familiar with nCrunch,  Wallaby.js is nCrunch for JavaScript.  I want to talk briefly about building your code.  We've talked so far about these things  to improve JavaScript.  We've talked about third-party libraries.  We've talked about modules.  We've talked about languages that will compile to JavaScript.  We've talked about testing.  What do these all have in common?  Well, they are all things that require external processes  to the JavaScript.  So if we have a quick look, third-party libraries  will need to be downloaded and pulled in.  Modules will need to be turned into one single JS  file for your web application to load.  We'll need to compile our JavaScript when we're building it.  And our tests will need to run so we  don't deploy broken code.  And so we need to start thinking about tools  that we can use to automate this process so that we're doing it  in an automated manner.  When we talk about build tools, if you're familiar with any of these,  this is the sort of thing we're talking about.  We're talking about building them to the JavaScript ecosystem.  We're looking at tools that are going  to be doing all of the external processes that we  need prior to deploying our code.  We have found that grunt is our preferred build tool of choice.  But we are actually on the eye out  for a number of other build tools.  I'm aware that Gulp and Broccoli are both very  preferred build tools from some people.  So we're keeping an eye out.  But when we're working with actual clients,  we're finding that the maturity of grunt  is actually very useful.  So grunt stores its configuration.  That is the instructions that you need to build it in a grunt file.  And these will contain any dependencies of the libraries  you're using and any processes that you may want it to run.  And these will be grouped into tasks  that you can run with any number of these build steps in.  Most of it is third party.  It can be made to run from any other build we're using.  So if you're running a Java project,  you can trigger your grunt build from Maven,  similar from this build.  And so that means that you can actually  make sure that your entire project's run if you click  the Play button or from one single command line  tool in a remote CI server.  Looking at a grunt file, I'm not expecting  you to read through all of this.  I want to draw your attention to a few things.  Firstly, these lines which are defining your tasks.  So these are defining your JS hint process, which  JS hint essentially provides you static checking  and co-quality checking for your JavaScript.  And what we're defining here is all of the config  that we need to make sure that's running properly.  We're also defining a watch task.  And that's going to rerun the processes whenever  what you're writing has changed.  So it will provide you continual assurance  that your JavaScript is of high quality.  This on its own won't do anything,  notably because it actually grunt by default won't  know what JS hint and watch are.  So we need to load these in using NPM, the Node Package  Manager, which will make sure that these are in the file  system before we run our code.  And then finally, we can just register this task  at the bottom, register task, default JS hint.  And that means that if we run a grunt on the command line  where the grunt file is, in the path where the grunt file is,  it will run JS info.  It's very easy to add more to this.  If we want grunt to run our tests,  we would add these lines.  We would need to load our NPM task in.  We need to load the Karma plug-in save.  We want to use Karma to run our tests.  We would then add some config.  I notice that there's a typo on this slide.  That should be config.  We want to load that in so that grunt knows about Karma.  And then we always simply do is register this task.  So if we now go to the command line  where the grunt file is and run the grunt test,  it will run these processes for us.  So grunt is a very simple thing to use.  Its plug-in architecture is very powerful.  There are plug-ins to do anything you want.  All major testing ecosystems, compiling  for almost all third party libraries.  Compilers for almost all JavaScript libraries.  It provides test coverage.  If you are using SAS or less to make your CSS nicer,  it will provide pre-compilers for that.  And it will rerun certain tasks when watched files are changed.  Grunt also works very nicely on a no-dk system.  So now that we've done all of this,  now that we've looked at all of the improvements  that our JavaScript code could undergo,  let's glue it all together.  And let's start thinking about why we write front-end code.  And at the end of the day, it's because we  want to make websites that have logic in them.  We want to make sure that our websites are responding  to what the users are doing.  As I mentioned before, server-side code is an option.  You can use Razor.  You can use JSPs or Timely for Java.  And you can keep all of the logic about data in the server-side.  But there are problems with this.  It can be very slow.  It has to do all the calculations on the server-side  before it sends a response back.  It forces a page refresh.  And it limits the ways that clients  can interact with your data, because it has to go back  to the server every time.  So the traditional solution to this problem  was to use something like jQuery.  So jQuery is a very famous JavaScript library.  And it's very good for some things.  It's great for manipulating your DOM.  It provides you a massively beneficial wrapper  around all of the DOM manipulation you're doing.  And it will make Ajax requests to your API very nicely.  And if it's JSON, it will interpret it brilliantly.  So you can start writing your applications  in a much more browser-driven way.  So your browser will see the page.  It will go and get the data.  And it will put it on the page and form it nicely for you.  But there's problems with this approach.  For one thing, jQuery is massively bloated.  Early JavaScript libraries were all basically  bootstrapped onto jQuery.  So you have things like jQuery.  jQuery has all of your functional paradigms.  And jQuery will give you extend functionality.  And jQuery will re-implement global variables  if you use push me pull you, which is a strange library.  It contained everything.  And it also did everything for you.  And the problem when one library does everything  is that all of a sudden you're mixing all of the concerns.  If jQuery is managing your data, as well as working out  how it's displayed, then you're mixing your concerns  there.  So if you ever want to change the way your data is displayed,  you actually have to leap very quickly into the way  it's brought into your code.  So we're mixing all of these things.  jQuery is not a bad library.  jQuery has things that it is very good at.  Use it for DOM manipulation and use it to wrap your Ajax  requests.  But recognize that there are libraries that are better at jQuery  for everything else.  And make sure that you're encapsulating these things  in small places.  So jQuery no longer just takes over your whole application.  So if we're only using it for the DOM manipulation  and maybe to make some requests of a server  to find things out, well, where's that last little bit?  Where's the bit that actually glues together  for data that we're getting and how that's displayed  in the front end?  As I said, there's another library for this.  This is exactly the same motivation that  led to the MVC pattern, say, for web applications,  where we're dictating what we're seeing based on the data that's  being supplied to the application.  And JavaScript's taking this MV star pattern  by separating the concerns of getting, storing, working out  how to shape the data with how it's displayed.  And these are the frameworks that we're  talking about like AngularJS, like KnockoutJS.  So KnockoutJS is responsible for that top line of code.  We're getting a view model, and we  are putting the data onto that.  And the KnockoutJS is responsible for making sure  that the view is changed with this data stapled onto it.  AngularJS does a very similar thing in a different way.  There are loads of great MV star frameworks  that we can start using to start splitting these concerns apart,  that we can start splitting the model and the viewer part.  Now that we've actually got these great language features  in JavaScript, like modules, like third party libraries,  this plug and play architecture, we  can start using the more traditional RO patterns  with great amounts of discipline.  A quick aside as to which of the frameworks, AngularJS, KnockoutJS,  et cetera, we prefer, our experience is relatively limited.  We have used AngularJS and KnockoutJS more purely  because they were big players earlier on in the ecosystem.  We've shunned backbone much to some people's delight.  We are keeping our eye on React number,  but we haven't had a reason to leap massively into that space yet.  There's a lot of talk about which of these two libraries  is better.  Essentially, it depends on what your use case is.  We prefer Angular for big, large, complex projects.  And we find KnockoutJS very quick and easy  to add on to either legacy projects or very small projects.  So that is everything I wanted to say about the middle,  the present, the current JavaScript ecosystem of things  that we might want to do.  And I promised you that I'd try and sum it up nicely  at the end by talking about the practical steps  that we can go off on our projects on Monday and do.  So what do we do now?  What do we do now that we've got this information?  And as I see, there are two points that I want to make here.  And the firstly is if you're on a Greenfield project, what do you do?  Because obviously, you can start from scratch.  You can architect your system from scratch.  And the first thing is make sure you treat your JavaScript  with respect.  Make sure you treat your front-end code with respect.  You will very possibly be putting a significant amount  of logic there now.  So you can't shun it the same way that we did two, three years ago.  It's a smaller time as that that these changes and this paradigm  shift about JavaScript has happened.  So I'm not saying you should have a crystal clear structure  in mind when you begin.  Evolving design is still a thing, and I'm  still going to advocate for that.  But do you think about the libraries and frameworks  you're going to use the same way that you would think,  oh, I'm going to use Spring.  Think, oh, I'm going to use Angular.  Do you structure your application in a potentially layered way  or a modular way?  And make sure that you're encapsulating your concerns.  We have produced an ideal front-end tech stack at software.  We also understand that every project is different,  and that what works for one project may not work for others.  But with that provider in place, this  is what we would probably consider as a default  when pitching for a new project.  We like TypeScript.  We would probably, where possible,  like to avoid writing native JavaScript moving forward.  Because TypeScript gives us a lot of the language features  we miss writing JavaScript.  We used Run-to-sab-builtle.  We're keeping an eye on others.  But this is a mature, stable one that we've got knowledge of  in-house at the moment.  It will compile and minimize our TypeScript  and also run all of our tests.  We like the lightweight ecosystem  of that Mocha provides with the flexibility  to add Chai, Synon, and Karma as well.  We'll put Wallaby.js in our IDEs to make sure  that our tests are being run continually  and to get as close to 100% coverage as is feasible.  And we use AngularJS for projects  that will run for a longer time.  But we also recognize that Knockout.js is great  for small projects or projects with a lot of new starters on  or junior developers on that actually we  want to ramp up very quickly.  But that's the easy one.  We're starting out from scratch.  What's our ideal development process?  So what do we do if we want to migrate our legacy JavaScript?  It's rarely feasible to start from scratch.  It's rarely feasible to throw everything away and start again.  So instead, what we want to do is we  want to try and identify some quick wins.  Firstly, this should be a principle on every project,  the Boy Scout rule.  Leave the code base cleaner than how you found it.  Whenever you go in, whenever you work on code,  make sure this is anything that you don't like,  you can change it.  Make sure you've got buy-in from your team  to actually invest a little bit of time  in making these improvements.  Am I great away from any old language features  and towards a better tomorrow?  That sounded corny.  Add a build tool.  Do this early.  At the very beginning, when you're not using any  of the other improvements that I've suggested today,  it will seem like an absolute waste of time.  But it will unblock future improvements  that you'd like to make.  And it will increase.  It will become much, much more difficult to do this  as time goes on.  So build this into your process early.  Migrate to modules gradually.  Modularization will significantly improve  your code's maintainability.  It is probably the best thing that we  can use to migrate away from the JavaScript of five years ago.  Test your code.  Once you've started modularizing it,  unit testing can be added.  But I don't think that's where the value on legacy code lies.  I think that the JavaScript that you've written,  even the legacy JavaScript that you've written,  is actually going to be very hard to test,  because it wasn't written with that in mind.  So instead, I think that the value that  comes on a legacy project is from adding full stack  Selenium integration testing.  Because that's going to test the functionality that you've  written, still guard against regressions,  but not require significant refactoring  of the JavaScript code.  And we actually quite like knockout on legacy projects.  Knockout can be added gradually.  It's very easy to put in very key strategic places,  where, say, a lot of jQuery, DOM manipulation, data mess ups  are going on.  So it's very easy to add incrementally.  We don't recommend quarantining the old bad code  and starting again.  I've seen enough code bases in my time that look like trees,  in that if you cut them down, you  can see rings of the code base that age the project,  and age when the file was written.  You've got the ring in the middle of ASP 1.  You've got the ring on the outside of ASP 3,  and then moving toward single page applications,  and then migrating to TypeScript.  That is going to do nobody any good.  It also doesn't help that JavaScript  has a nasty habit of modifying global scope.  So actually, you may think that you've  hidden all of your problems in old JavaScript away,  but it will come back to bite you.  And the person who works on that code  is probably going to leave your company in two months.  And we also don't recommend attempting  to adopt a massive code base shaping library.  AngularJS is brilliant.  It provides a lot of easy additions  when you are starting on a new project.  But actually, the cost of migrating across to it  can be very hard.  So your front-end code should be first class.  You should be architecting with that in mind.  There's the text that we recommended a few minutes ago.  And as I said, even if you don't have the chance  to migrate to that full text stack,  there are still quick wins that you can do.  So these are the recap slides that you've seen already.  And I'm aware that I've been keeping you longer than I should.  So that was everything I wanted to talk about today.  Unfortunately, I've run out of time.  So I don't have time for questions.  But I'm going to be around for the next two and a half days  of the conference.  So if anybody sees me, feel free to grab me and ask questions  then.  So thank you.  Thank you.
High-Quality_Front_End_-_David_Simons_0_767.png High-Quality_Front_End_-_David_Simons_768_2039.png High-Quality_Front_End_-_David_Simons_2040_3995.png High-Quality_Front_End_-_David_Simons_3996_4751.png High-Quality_Front_End_-_David_Simons_4752_5267.png High-Quality_Front_End_-_David_Simons_5268_6179.png High-Quality_Front_End_-_David_Simons_6180_6347.png High-Quality_Front_End_-_David_Simons_6348_6575.png High-Quality_Front_End_-_David_Simons_6576_8099.png High-Quality_Front_End_-_David_Simons_8100_10115.png High-Quality_Front_End_-_David_Simons_10116_11243.png High-Quality_Front_End_-_David_Simons_11244_12671.png High-Quality_Front_End_-_David_Simons_12672_13739.png High-Quality_Front_End_-_David_Simons_13740_15179.png High-Quality_Front_End_-_David_Simons_15180_15635.png High-Quality_Front_End_-_David_Simons_15636_16379.png High-Quality_Front_End_-_David_Simons_16380_17171.png High-Quality_Front_End_-_David_Simons_17172_17279.png High-Quality_Front_End_-_David_Simons_17280_17663.png High-Quality_Front_End_-_David_Simons_17664_19511.png High-Quality_Front_End_-_David_Simons_19512_21587.png High-Quality_Front_End_-_David_Simons_21588_22523.png High-Quality_Front_End_-_David_Simons_22524_23399.png High-Quality_Front_End_-_David_Simons_23400_23543.png High-Quality_Front_End_-_David_Simons_23544_25007.png High-Quality_Front_End_-_David_Simons_25008_25571.png High-Quality_Front_End_-_David_Simons_25572_26531.png High-Quality_Front_End_-_David_Simons_26532_27227.png High-Quality_Front_End_-_David_Simons_27228_27539.png High-Quality_Front_End_-_David_Simons_27540_30131.png High-Quality_Front_End_-_David_Simons_30132_30455.png High-Quality_Front_End_-_David_Simons_30456_33503.png High-Quality_Front_End_-_David_Simons_33504_34895.png High-Quality_Front_End_-_David_Simons_34896_37859.png High-Quality_Front_End_-_David_Simons_37860_38399.png High-Quality_Front_End_-_David_Simons_38400_39767.png High-Quality_Front_End_-_David_Simons_39768_41051.png High-Quality_Front_End_-_David_Simons_41052_43823.png High-Quality_Front_End_-_David_Simons_43824_46487.png High-Quality_Front_End_-_David_Simons_46488_48023.png High-Quality_Front_End_-_David_Simons_48024_48107.png High-Quality_Front_End_-_David_Simons_48108_49523.png High-Quality_Front_End_-_David_Simons_49524_50627.png High-Quality_Front_End_-_David_Simons_50628_52667.png High-Quality_Front_End_-_David_Simons_52668_54359.png High-Quality_Front_End_-_David_Simons_54360_55523.png High-Quality_Front_End_-_David_Simons_55524_58703.png High-Quality_Front_End_-_David_Simons_58704_60635.png High-Quality_Front_End_-_David_Simons_60636_61799.png High-Quality_Front_End_-_David_Simons_61800_62675.png High-Quality_Front_End_-_David_Simons_62676_63635.png High-Quality_Front_End_-_David_Simons_63636_64163.png High-Quality_Front_End_-_David_Simons_64164_65555.png High-Quality_Front_End_-_David_Simons_65556_66023.png High-Quality_Front_End_-_David_Simons_66024_66383.png High-Quality_Front_End_-_David_Simons_66384_66995.png High-Quality_Front_End_-_David_Simons_66996_67559.png High-Quality_Front_End_-_David_Simons_67560_69491.png High-Quality_Front_End_-_David_Simons_69492_69599.png High-Quality_Front_End_-_David_Simons_69600_70931.png High-Quality_Front_End_-_David_Simons_70932_71111.png High-Quality_Front_End_-_David_Simons_71112_71735.png High-Quality_Front_End_-_David_Simons_71736_72239.png High-Quality_Front_End_-_David_Simons_72240_72791.png High-Quality_Front_End_-_David_Simons_72792_74663.png High-Quality_Front_End_-_David_Simons_74664_75395.png High-Quality_Front_End_-_David_Simons_75396_76211.png High-Quality_Front_End_-_David_Simons_76212_81443.png High-Quality_Front_End_-_David_Simons_81444_81995.png High-Quality_Front_End_-_David_Simons_81996_83603.png High-Quality_Front_End_-_David_Simons_83604_83867.png High-Quality_Front_End_-_David_Simons_83868_84635.png High-Quality_Front_End_-_David_Simons_84636_85619.png High-Quality_Front_End_-_David_Simons_85620_85787.png High-Quality_Front_End_-_David_Simons_85788_85847.png High-Quality_Front_End_-_David_Simons_85848_86183.png High-Quality_Front_End_-_David_Simons_86184_86543.png High-Quality_Front_End_-_David_Simons_86544_86591.png High-Quality_Front_End_-_David_Simons_86592_86711.png High-Quality_Front_End_-_David_Simons_86712_88055.png High-Quality_Front_End_-_David_Simons_88056_91055.png High-Quality_Front_End_-_David_Simons_91056_93719.png High-Quality_Front_End_-_David_Simons_93720_93935.png High-Quality_Front_End_-_David_Simons_93936_94404.png