 But let's continue. So part of this improving JavaScript, I'm going to go through a few tools that I use that sort of, I think, benefit my process. So those things can do things like keeping it clean. Keeping it clean is important because clean code can be readable. Like if you look in the background here, this is artificially terrible code, but it's hard to tell what's going on. It's hard to sort of dive in and be, I know what's going on here, and if there's a bug, I can figure out what would be causing it. So clean code's important there. Having to set standard of style also can be really beneficial for making it easy for people to jump in and out while keeping consistent code that just looks nice and reads nice and is maintainable. Dry is a pretty common expression in coding. It means don't repeat yourself. I added the O there because I'm going to be talking a little bit about including other people's code in your work and using libraries. Basically, making sure your code doesn't have a lot of redundancy in it. The more redundancy you have in your code, the more likely you are to run into issues where maybe something's broken in one tiny place. Even they're repeating this one piece of logic so several times you're coded. There's more places for errors to be. So breaking things down into small repeatable modules and also using external code that other people have solved problems for you to save you time and also reduce the chance for errors there. And to keep it moving forward. So keep using new technologies, trying new things and experimenting to sort of push things forward always and just lead to a more modern web. So the first tool I'm going to be talking about today is called ESLint. ESLint is a code linting tool which basically means it can read through your code and tell you and sort of pick out points that could be common errors. It can see styles and make sure that based on the style set you give it. You follow very strict styles. The nice thing about ESLint is how pluggable it is. It's got a very full feature configuration so that basically any sort of rules you want to set up you can to make sure your code fits exactly the style you're looking for. So I'm going to do a quick little demo of using ESLint. I've got over here some code right here. So I've got a few code I'm going to be working with and I'm going to use this section first. And so right now it's nice to format but I'm going to throw a few little bugs in there just for demonstration. So if you know the WordPress coding standards you know you want to have space between parentheses. You've got to throw some legitimate bugs in there like having a semicolon there when that should be a comma for continuing this bear statement. Let's just mess up a few other things. Okay so we've got some bugs we've got some style issues. So I'm going to go back to the command line which is over here and run ESLint. So I'm using grunt to run it but you can also run it just as a CLI thing. It has also gulp extensions basically however you want to run it you can make it work. So I'm just going to run my little ESLint task here. Is that big enough? I can make that bigger. That's better. So when that runs it sort of reads through my files and that's yeah okay. So it reads through the file and finds any issues with it. So we've got one issue first, parsing error, unexpected token. So that's from the most serious bug added for not having a closing parentheses there. But immediately we know there's a bug here. We don't have to go to the browser. We don't have to get anywhere. It just tells us there's an issue with your code. Right again and we should be getting a ton of issues now. So these are all the different style issues that don't even that don't necessarily break code immediately but seem like they could be an issue down the line. We've got things like this weird error which is actually from that extra semicolon. There needs to be spaces except all sorts of different things there and as you read through them you can go back in here and see oh we're missing a space there. Oh this is a semicolon and that should be a comma. I think that might be the things that we're causing out there. There's still one missing space on line 15. Column 23. Line 15 missing space right there. Okay there we go. So now we just get that one error and it says unexpected constant statement. That's because my current rule set doesn't allow consoles but it's a warning instead of an error. So it doesn't break anything but I just generally want to warn me so that I know when I'm pushing code to production it doesn't allow things to the console. It also doesn't allow debugger statements. If I go back to my code here I can actually open up my configuration file over here which has a lot of rules in it and it probably could be pared down a bit. It's sort of trying to emulate the WordPress coding standards with a few additions here. So we've got something that says we have the browser. We're in the browser so we want to allow things like window and document as global variables. We want jQuery because we're frequently going to be requiring that as part of our WP and Q statement. We're using common JS which I'll get into in a little bit. And then we also have all these rules which sort of set style and allowed things. And there are a lot of yes then rules. So overall we're only to look at right here. But basically each one sort of determines if it's an error, if it's a warning, if we should just ignore it. Special cases like we can set more specific things. Excuse me. So this is sort of a quick little configuration file I set up to try to emulate that WordPress coding standards for JavaScript. I'm sure there's some issues with it. I'm still sort of working on it. It's a living working thing. But it allows me to always make sure that my code matches the standards. So it's cool. And it's fast and it easily lets you know where issues might be in your code. So that's using ESLint. Next up we have Browserify. Browserify is a tool that helps a lot with don't repeat yourself section and also with others. So basically what Browserify does is it helps you, it allows you sort of connect JavaScript files together, both within your own local files and with external libraries. It implements common.js, which is a system used by Node to connect files together. It's sort of used this require statement. If you remember in my code previously, you saw that require statement here. Or not there. Here. Which sort of includes these libraries. If you have just require with a word node.slash in front of it, that's requiring it directly from the node package manager, which I'll talk about in a second. And it's assigning it to that underscore variable. If we do require with the dot slash first, that means we're actually requiring a local file. So that will require a model.js next to the file that it's in. So that allows you to sort of separate your code into multiple files for easy separation concerns for there. And finally, in that model.js file, we can use this module.exports to tell it what actually to get when that require function is called. So back in my code, if we go to this test.js file and not look at this code, look at the code below it. We can see we've got module.exports and then this sort of object that exports these three properties of it. When I export those three properties, we can then access them after it's required. So we've got require dot slash test require the local file. And then we can say t dot test to to access the test to property of t, which is the same property right here. So it allows you to bundle this things together when it's bundled properly. I'll run browser find this file to show you how it looks after it's bundled. We can see it looks a little crazy. There's some extra functions stuff in here that is what browser files magic to connect things together simply. But overall, it's the same sort stuff. And I'll go into some of the details here in a second. But it basically requires these things together and bundles it all into one file for us. One thing I mentioned was including packages from node package manager. No package manager is part is included with node when you install node is the sort of local JavaScript non browser JavaScript. You can install your machine for running all these tools. So if you're running these tools, you'll have npm already set up. But npm can also install libraries for your actual development instead of just for tools. So let's say we want to use load ash in our local is in our project in our code on the browser, we can use npm to install into our project, which installs it into the node modules folder in that project. And then we can use that same required statement like we were up ahead, except instead of underscoring, you use load ash there and you get that underscore variable with the load ash library properly. You know, I'll just be automatically included there. It's very simple. It includes external libraries. You can when you include that save dev, it actually saves it to your package.json file, which allows anyone else to install the same packages and also last for like maintaining proper versions between them. It's real cool. And it's also it's once you actually get to using it, just having all these libraries at your fingertips, be included super easy without having to worry about WP and queue require statements and having a million squares being installed on your browser at once and all that stuff. It's it's really nice. And also that having those required statements means sort of ensures that if you're using a concat, you can have issues with when codes running in the order it's included. Well, this is sort of like, you know exactly where that file is included. And it also doesn't the global namespace because instead of having all these global variables from included libraries, you have them all just in those required statements. There are also things called transforms for browser fi browser fi sort of lets you run transforms, which modify how it behaves. It can modify how files are required. It can modify what sort of files are allowed to be required. You can do things like you can require SAS files into your JavaScript, which will let you just have this one larger JavaScript file that then expands out and to include all the SAS that is properly rendered into CSS. You can have JavaScript templates, which you just do require the template and then run that template as a function to output the proper text. One transform I use regularly for WordPress is called a browser fi shim. So WordPress has a lot of built in libraries. It has things like jQuery and backbone, which while you might think it would be okay to bundle and just have in your one file, if you do that, a lot of other plugins are also using these core libraries. You might end up having to download them twice. If you bundle it, so that's one download, and then another plugin requires it, so that's another download. So ideally you want to have them only use that one, this bundle of core. So what browser fi shim allows you to do is to tell browser fi, hey, don't include this package, access it by a global variable. So over in my package.json file, I actually have a little statement here that says, hey, if anything requires jQuery, instead of packaging the whole jQuery library into my bundle for the browser, I want to use the global jQuery variable. So then I can just have my script require jQuery and the in queue in WordPress, and then it will make sure it accesses that. And what that looks like actually in the compiled file, we can see right here. We can say, it basically says, if it's a window, get the window jQuery property. Otherwise, if there's the global variable is available to us, which is sort of a node thing, then we can get the global jQuery there. It shims in jQuery, so we don't have to include it in the actual package. Well, with load ash here, it's including the whole package down below in all this code. So that's sort of the best way to combine browser fi with WordPress there so you don't have redundancy in our code. The final tool I'm going to talk about is Babel, which is sort of a crazy little tool that compiles JavaScript from one form into another. The most popular use case of it is compiling what's known as ES 2015, or you might have also heard it be called ES6 into ES5 or the JavaScript that most browsers can read. So ES2015 is sort of like the next revision of JavaScript. If you remember like CSS3, when things were getting new rules there, sort of like a standard that's been agreed upon, that of new features that are coming to JavaScript, then most browsers still haven't really fully implemented. Some of these features, some browsers have implemented, but no browsers have implemented all of them. What Babel allows us to do is sort of use these features now and then have them compiled into code that all browsers can read. So some new features we get in ES6 are things like at the top there we've got arrow functions, which are sort of like a function shorthand. The special things they allow are, if you know functions normally, the this variable inside a function refers to the function object itself. An arrow function is that this variable actually is maintained with the outside scope. So it doesn't have its own this, which is useful in a lot of cases instead of having to use .bind for maintaining this. It also does a little trickery where if you only have a single statement in your arrow function, x returns that the result of that first statement. So this x, y arrow x plus y will return the sum of x and y without any return statement necessary. So it's a nice little shorthand that works well for passing in callbacks that are really small. Other things, the next two lines are let and costs. Those are two new variable declaration types. That is a more local variable. Normally with a var that it's only local to the function it's within. It's not local to an if statement. It's not local to just a block of curly braces, but that makes sure it's a truly local variable. It's sort of like really when you're using yes 20, 15, or 6, you can pretty much replace all your bare statements with that because that'll make sure your code is a little more contained within each block and not so much like having all your variables in the function up at the top. You can have all your variables for an if statement and stuff like that. Cost is sort of a variable that never changes you assign it once. It doesn't change after that, which is useful for just sort of establishing a set thing that will cause issues if you ever reassign it. Below that we've got template strings, which are a nice way of having custom template output in a nicely formatted thing that really hasn't been out available in JavaScript before. You've had to do string concatenation or use an external library for that, which is nice. This one below is a little more complicated. It's called Variability Structuring. We've got an array on the right and then two new variables on the left. Basically, we're breaking that array up into variables we can then access. Variables C and D get assigned to the first and second item there. C is equal to 3, D is equal to 4. It's easily breaking those things out. You can use this for things like having multiple variables exported from a function simply, also like that. The one below is a little more complex. The 4 of statement. If you know 4n in JavaScript, which is sort of like the previous 4H from PHP, 4n is nasty. It can cause a lot of issues that you don't expect. 4 of is sort of a more clean, more restricted 4n. It works with iterable objects, which are even objects you can define yourself to cleanly sort of loop through them without having to worry about has own property and all the sort of pitfalls you can run into there. I can't really go into the details of why you don't want to use 4n, but look it up. It can be a little gross. Also, there are a ton more features than this. There are things like classes and all sorts more stuff. You can look it up. Babel has a big list of them with good descriptions on all of them. There's some really cool stuff and I feel like I even haven't sort of just scratched the surface of what you can do here. Babel also can compile JSX, which we'll probably hear about a little more later today as we go into React stuff. JSX is sort of a custom format for React that makes the templating and objects of React much simpler to create and read through. And before I continue, I'm just going to go through a quick little demonstration of how that Babel works. So if you remember before, I was commenting out some things because I actually have the ES6 version of these things. So up here, we can see instead of that module that exports, I'm using this export, which is actually the ES2015 real version of modules in JavaScript. So this is coming. It's cool. And we're going to have it. It's great for HTTP too. But while we don't have that full setup yet, we can use Babel and BrowserFi together to still combine them and modules that use this new syntax. So here, I'm going to do the same thing. So up above, in that previous file, we had the export and this file we have the import. So export is sort of like that you export and you give it variables or functions with names and you can access those on the other side then. On the import side, I can do like import underscore from loadash and then Babel will convert that to a require statement like below and then BrowserFi will include the loadash library in there where we need it. This is a little bit of the special use of the import where we can import specific variables, not the whole package from a separate package, which is a nice way of sort of not getting crazy heavy libraries all at once. So I can import just test two and test three from that test.js file and ignore test one. And I can even reassign the name of test three to just test there. Same thing with this jQuery statement. So when I've converted that now I can save these files, run, I'm actually running Babel here as a transform to BrowserFi so I don't even have to run extra command I just run BrowserFi and automatically transform this. I'm going to run BrowserFi again. It bundles it and we can see back in here in that compiled file. It's going to look a little crazier because we've got all the Babel transforms going on here, but we can see there's still those require statements. It's all working now for us. It's all there. And we can even see we've got an arrow function here working properly if I actually run that test file. So if I run node.slash assets.js something happened. So there was an issue there but generally that would be outputting the right thing. Sorry about that. So we've got the arrow function that gets converted properly into a real function which I will show you up here. So test three exports this function here just like we're defining it here but it's much shorter when it's actually compiled by Babel. So finally let's talk about tying everything together. That link there is actually to a generator I've created. If you saw Mark Jacobs talk about yesterday at the end of the day he was talking about grunt init generator. This is a human generator. It's very similar. It includes this whole JavaScript workflow in it. So if you want to store work on it with your own projects you can generate it right up and play around with it. I've got a grunt file in here which I can show you briefly which has an ESLint task. It has a Browserify task and in that Browserify task I've got both that Browserify shim transform and the babelify which is the babel for Browserify transform which allows me to run all these things at the same time. So then if I run something like grunt scripts it does all three things at once. And I can even run a watch task. So any time I update a JavaScript task it automatically does all these things. It will warn me if there's any issues with the code I just saved. It will compile it properly and then Uglify is another thing that I'm not going over right now but it basically minifies any JavaScript you have going on there. So that sort of gives you the full process real fast, automatic and easy to do with you. And especially if you use that generator it's sort of just like you set it up with JavaScript and it works. You just write your code. You write your code with ES6 if you want to. You don't have to. You write your code with the main modules and it may require some node factory manager. And it's sort of magic. It just sort of works. It's nice. And you know if you if you're familiar with the node ecosystem and with development tools like this there's a lot of stuff going on. It's constantly changed. There are always new tools like if you see me talking about grunt here you probably are like oh but there's also a gulp out there or there's also broccoli or there's you see me talking about browser there's like Webpack and there's JSPM and ESLint. There's also JSLint. There are a thousand tools out there and there are good use cases for each of them and each has their strength so it's often worth it to at least do a little research to see what's out there. These are the ones I've sort of rested upon partially from just getting to them first and partially from seeing other people's recommendations. So it's always good to sort of keep your eyes and ears open with this stuff because there's always new cool things being made out there and also you can be making new cool things if you have an idea of doing these things better than how these have been done. It's all JavaScript so if you know JavaScript you can write these tools. It's all just no JavaScript. So that's those tools. Does anyone have any questions on it? Yeah so back there I am still importing it and all that does in the main.js file I'm importing dollar sign from jQuery which basically gives me the dollar sign variable assigned to the jQuery library and then in the actual compiled file what happens is we get the jQuery global variable set to that. So still when we're enqueuing the script in WordPress we'll set jQuery as one of the dependencies so it uses that global jQuery object in case any other plugins are also using it. What I try to make sure we have well-established tasks so in grandfiles you can sort of you have the specific tasks that are running there but you can also have sort of groups of tasks together so I make sure that anything that has to do with JavaScript I include in the scripts tag so anytime I run the scripts it just does all my JavaScript compilation. I also have that set up with my watch test so up above when I sort of look for any change to a JavaScript file in the assets folder anytime that changes run that scripts tasks and do all the compilation there. So it's sort of there's still like a little knowledge about how it works there but really if you just run the watch whenever you're changing things it should always keep things properly managed there. And as long as you have things properly set up with the package.json file all they have to do is run npm install and they have everything installed properly. Anything else? No. I want to give it a try. I've been like using BrowserFi and sort of invested in it before I like seen what a pack it seems cool. I think it's some of it seems more intimidating because they're sort of more built into it. But I think there's still power in that. Some of the stuff I've seen it do it seems very interesting like it sort of can have multiple files being exported at once rather than a single file like BrowserFi. So if you want to only include partial modules for not including everything on every page that's a cool feature. But I think I'd have to dive deeper into it to fully understand it. I don't I get nervous about tools that I don't understand exactly how they work. So I want to make sure I like fully get it before I can really dive in. I I've definitely looked at that and I'm intrigued by it. I definitely see the bloat that's inherent in using Gulp and Grunt. And it appeals to me to run that because I can see that yes, Grunt is sort of slow. Gulp just still requires good amount of configuration and just rain the script from the CLI. I love the CLI so if I can just get that rain that's great. I think having the watch task is still a little clunky with that. But I've looked at maybe transitioning towards that too. It depends on how many libraries and these are including. I would say probably like with this Grunt setup I never goes over more like three more like three seconds or so. Yeah, if you're having like a lot of really big libraries that can take longer because then like it's including some big files and then also like Aglify has to can't cast a like it's compressed down these huge libraries. But generally it's never like crazy and you can keep programming laws compiling. So it's not usual. Anything else? If not, I'm going to be around. You can always talk to me and I like to talk about this stuff. Thank you.