 It's going to get the audio going. All right, so cool. If anybody wants to follow along, my slides are not easy. You have to clone this repo and then run grunt. So hopefully you have grunt and solve if you want to follow along. So this is actually kind of a mini web app, in the broadest sense possible. I'll go into some of how I built this a little bit later. But yeah, just so you know, if you want to follow along, not just the HTML, you have to run this repo. Cool. So yeah, I hope everyone's feeling good right now. I know I am. I got my favorite coffee. I got my cat hair hoodie. I'm ready to rock. So this is going to be a little bit different. So my slides, it's just a little presentation. But I'll be showing a little bit more code than the previous talks I've been doing. I've been doing a lot of experimenting with some of the new features coming out. Just people have been complaining a lot about modules and which format am I supposed to use. There's a couple of posts that have been coming out recently. Lean towards the ECMAScript 6. So I've done a little plank around with that and just seeing what it's like to build a backbone app that way. So let me get the slides up. Cool. So yeah, the title talk is Growing Up a Backbone. And this was just a title in my head that I had for a while before I came up with content for it. And it's just that I felt, ever since I started using backbone, I've become a stronger developer. Even though there have been times where I wish backbone did more for me, the fact that it didn't, it kind of gave me that opportunity to grow my skill set. So I've talked to a few other developers, and they kind of inspired me subliminally that there are other developers who need this help. Maybe they don't. When I start getting these slides, it seems really obvious, every single step. Yet I see so many boilerplates that are getting released, and people talk about web app development. They don't even scratch the surface of some of the stuff. So this line right here is something that I discussed with Mike, standing to the left of me. And I had to sell them on what I meant. So through the nature of the web, and specifically, in this case, backbone, we're all becoming our own little front end, independent framework developers who have to cobble together a whole bunch of different random projects to make our own projects build and run and do what we want them to do. So in fact, we're always assembling pieces. As they come together, we have our own little thing that maybe you have your own personal backbone boilerplate. So that's an unfortunately, ill-named title. It's really Tim's workflow is what that project is. So as I come up with better ideas, I put them into this project, and I discuss with other people. There's Ember Tools, and Ryan Florence created his own workflow to work with Ember. And I'm sure you have your own. If you're at your own company, you're using Java, you probably have some kind of weird build script that puts together your application. You're becoming your own little framework engineer. So the three parts of this talk, there are originally four. I was going to try and get to data binding, but all the good presentation books say you do three sections. So going with three, there's going to be plenty of content. I'm going to go for another 40 minutes on this stuff. So we're going to start with structuring. So just what do you need to structure your application? And that's not necessarily what module system you're choosing, or what template engine, or anything like that. This is not how you put your models, where you put your collections. How is the file system structured? How are your tasks running in order to build and optimize distribution? Then we're going to go into modular development. What are the different module systems out there? And we're going to look at some code that I've written right now that I think has the best possible way to use either AMD or ECMAScript 6 at this point. And the last bit are just, what are some techniques for using components? What are web components? I was going to do a deep dive onto Shadow DOM and some other of these very expansive specced components of web components. And that's not going to happen. I'm going to go over how I see developers using backbone integrating with the methodologies and the philosophies of web components. Oh, actually, I just forgot that I implemented speaker slides, or I'm not even using them. Also, OK. So these two philosophies are not mutually exclusive by any means. I'm just trying to take two different ideas that I've found that are very distinct. And they're very specific. So the Linux philosophy that I picked is through Arch Linux, and that's the distribution I'm running right now. They are very geared towards elegance and simplicity, yet giving you all the options available. So they give you everything up front. It's up to you to customize what you want. But they're not layering tools upon tools to make this job simpler. They're keeping it raw and basic. And there are a lot of purist developers that really abide by that methodology. They want to keep things pure, simple, and basic. And then you have the Apple philosophy here. And after Steve passed away, I've been watching all of his videos, and this guy's a genius. And one of the videos is when he magically announced back at Apple. Nobody knew he was doing this. So the guy who followed him even kind of freaked out. But it's up to 25-minute marketer is what I want. This is when he's demoing Open Next and it's integration. They run. And these objects will run themselves. And now they are just communicating at runtime. No code's been generated. There's no code to maintain. What we found a long time ago was the line of code that a developer can write the fastest, the line of code that a developer can maintain the cheapest, and the line of code that never breaks for the user is the line of code the developer never had to write. And I get to solve those freaking answers. Yeah, you know, you don't have to write any code and you can start building this app. And I feel like we're seeing that a lot with other front end web application frameworks. They're talking about less code to write, less boiler played, we take care of 80% of everything for you. And that's just a totally different methodology. So I think there are two distinct philosophies here. The kind that want everything upfront, no magic, no surprises, because that's how you build an app. That's how your mind works. And then there's the other philosophy where it's like, you have made a prototype. You want to bang something out pretty quickly. You just need to get something working. The Apple philosophy might kind of align better with you. And the reason I'm bringing these up are I've taken a step back and I've stopped being so opinionated about things because I realized people have different minds. We think differently. So when somebody complains that, oh, why aren't you using no modules and browser files? This is clearly the obvious choice. I'm not going to bash them back and say, no, because you can't load stuff asynchronously and that's something I really need. You've got to explain that I need more control, more flexibility, and that's just a different philosophy that I subscribe to. So it's just like, this is something that I've seen very common that people are on either side and trying to convince the other side to go there. I think we need to be kind of aware of this as developers. So to start, it's a web application structure. So I've been talking to Mike again about how frameworks and modules don't really have anything to do with your structure. And the cool thing is it's kind of evidenced by the UMD pattern, which I'm going to describe later in the modules section. But this allows you to kind of unify all these different module formats together and have your code run in all these environments. Just the fact that we can do that kind of really separates the need for your framework or your structure to be tied to a specific module type, like specific module format. And when we develop our JavaScript and our coffee script, it all gets compiled down to JavaScript that runs in the browser. So that's just the one thing to think of. So when I work on my web apps, I can organize and put files wherever I want because I know in my mind it's like a sieve and it just comes down and it ends up in either one CSS file or one JavaScript file. OK. So I'm already getting into grunt here. But I'm pretty sold on grunt as my task runner. Make is just as good. So if you prefer make, that's fine. The concepts I'm going to go over are just the steps and the tasks that I rounded or to build my application and to structure it and to keep it maintained. And the whole point of this is that you can actually have more maintainable code. So there's nothing that's saying you can't just write script tags and just drop them in your page. But are those scripts going to be able to load independently from another when you're testing and keep them in an isolated environment? There's just going to be questions that pop up later on where each kind of has a finagle and may things work that way. So I prefer to have a very strong foundational structure. And I find that developers who can quickly adapt to that, like they can see, OK, I know where this code is because everything works the same way. It's all structured. They're easily onboarded onto a project. And that's an anecdotal thing that I've noticed just from developers that are working on these larger applications. It was great because I've worked on one app where we needed to bring in one extra developer. He's a Python guy, he's a full stack, but he was able to jump in the project and start working on code. And that really kind of blew my mind. I thought I was going to have to hold his hand and help him through this. But when you have a decent build process and people can see the life cycle of how stuff works, it makes it a lot clearer. So I'm going to start with really, really basic steps all the way forward. I don't know where everyone's at with their build process. How many people here use a build process? Even for your personal projects, are we doing build processes, or is it more kind of like, I mean, that's not as important. It's really when you're working on a team that a build process really shines and having proper structure. But at the very beginning, I do this even on my personal projects now. I always separate my vendor code, my third party code, from my own application code. So this seems really, really obvious, but so many times I'll just see everything dumped into a JavaScript folder. And that's your code and the vendor code combined. And there are many reasons why you don't want to do this. And I'll top my head what I can think of is when you're hinting or linting your code, the rules that your third party code have abided by, and they have their own strict checking, that may not necessarily work well with what you're writing your code. So for instance, they can be using strict, and you're not using strict, and now you're mixing these linting rules. So yeah, that's not what we want. So we want to keep that code separate. So starting a way even higher level, this isn't really slide worthy, but you really want to be linting and cleaning out your distribution directories so that you don't get any surprises. So so many times that I run a build, and I skip the linting, and then something breaks, and then oh my gosh, jeez. If I just remembered to do linting first, this would not have broken. And cleaning was one of the first tasks I wrote for Back on Board played when I first created this, because I would be writing into my distribution directory and then keeping some of the lagging files. These are obvious things. So do these things. It's one line in VSD, which is RM, RF. So rebunding sources. This is another interesting task that needs to happen at some level, in some way, you need to do this. And this is the transformation between your development markup and your production markup. So when you're doing development, you're running all the development sources, so that may be every single script tag in your project, just in your HML. But when you're building this, it's not going to be every single script tag, hopefully. Hopefully, you're going down to one file. This is an interesting project that I found called Process HTML. And this is actually not anything new. Target HTML was a grown task that was around for a while that was influenced by another project. But the idea is that, actually, I can't see right now. Can everyone see this code? It's, is it because of the background? It's small. It's also small. Do you think if I was just larger, like, is that better? OK, cool. Just want to make sure everyone can see this, because these comments are a little faded out in here. And they're the meat of this whole point. So if we look at the style sheet up in here, we see that I'm pointing to app styles index.css. This is a logical place you wouldn't want to put things, right? So you minify everything down all your CSS. So in here, index.css loads all the other style sheets. Let's just pretend there's a bunch of imports in there. And then when you've built, you now have all those built files in, like, slash files.css, so you can just load that one styles. You can rewrite this href now to go to that styles.css in your build. So just think there's a build step. There's a piece of code that just parses this HTML, finds these targets, sees href, replace it with styles.css in my build. And then down here, I'm loading required.js during development, which then bootstraps my app. But when I build, I want sourced.min.js. So this is a nice way of developing, because, one, you don't need any kind of preprocessor or compiler or transpiler at all. This is just HTML. And there's directives inside of the comments. This is pretty common, I think, in maybe Rails, where they put comments for the requires for your JavaScript. I kind of relate it in that way. It's like you're still using standard directives, comments, so parts of the HTML language not defining anything new. So I've seen other ways. And the other ways I've seen are using something like jade that provides ifs, saving conditionals, and then being able to build that and then run your code that way. I think both are valid. It's just, to me, this feels a little bit not safer, but it's a gut feeling. And I think that's really what I'm siding with. I think both will work just as well. So what I have here are two screenshots from Chrome. And this is with source maps enabled. So one thing that I would like to see more from developers, especially server-side guys, who they say that they're Django, they're Rails, they does all the building and minification for them, to always enable source maps for development. I find that this makes it so much easier because you can have your development process. So you're just developing. You have all your code running in the browser. That's great. And then when you go to your build, you can actually dev again just to see that all your code works correctly when it's being built. And so many times I've had little, weird debugger issues come up because of a brace condition, because now it's synchronously loading instead of asynchronously loading or something weird like that. So I introduced just an error in here to show how I loaded source.min.js. And loaded, actually, let me just zoom out just a little. So it loaded like 54 kilobytes over the compressed, expanded to 166 kilobytes. But now when we look in our sources panel, we can see that it mapped all the JavaScript back to where it was on the file system. And this is becoming really common. I'm demoing the browser file, has support for our JS, has support for Rails, has support for Django, has support. You may have to finagle it a little bit to get it working in some of those systems. But the payoff is really worth it. So I would say this is fundamental now to development if you're doing fine coding. And if you're a node land, you can use a Glify.js. And if you use Grunt, the Glify task does that for you as well. Okay, so you can use any technology. I just mentioned Django, Rails, the asset pipeline. All these things work and they do the job. The point is that we are trying to get our code from development in a way that makes it easy for us to develop and output in a way that's easy for us to distribute and is efficient. So if you can figure out any technology that you want to switch out for there, because maybe you have a better preference for JS men or something else, well just make sure that you can actually output source maps. You can do these things that you want, that you're gonna need in your developers, in front of the developers you're gonna want. I don't know how many people here have ever developed or have ever developed a production issue with minified source and then that is just awful. It is like you don't want to have to go back to that and we don't need to. These things work, they're in all the major browsers that we're debugging in. The one caveat that I found though, is that they recently switched from a pound sign, sorry I'm sorry, an at sign to a pound sign for the, I'll show you what I'm talking about, just so I'm not rambling here. So you see here that it originally used an at sign and this is what all the browsers I have tested still support in Linux. So I'm in Linux right here for anybody, there's no noticing this, there's no Chrome canary in Linux. So I can't test all the latest browser features and it's unfortunate that required JS and Oglify 2 have switched over to the new pound sign format because now I have to go in and manually edit this file after building which is a little annoying. But the reason why they did that is because they didn't really think ahead and there's some bugs in IE8 where it gets interpreted as something weird in IE so it's probably some C data or something like that. So they recently switched it. So if you find the source maps aren't working just double check, make sure that you're using the right format. Okay, so this is the next segment and this is organizing application with modules and when I say modules now I'm not necessarily meaning just like one class or one constructor per file that gets assembled and put together. It's really kind of thinking about componentizing as well and how modules lead you into that sort of realm. It's like when you have files that can be independently loaded from one another and you can compose them together to form a component and that could be HTML, CSS, JavaScript, doesn't necessarily have to be just like I'm talking about AMD here. This is really architecting the app in such a way that you have these disconnected pieces that when assembled together form something. And it does work. So just some background. I started switching over into Angular on a client project that I've been working on and this was at the client's request and I find that Angular really makes this easy to understand how to like put everything together into a component is the idea of directives that you can say for this element attach this template and put these styles on. So it doesn't necessarily give you the styles piece but it's very conducive for that with something like require. I can just require in the style sheet and then for that module load it. So now I want to bring these ideas back into Backbone and I'm still very much in love with Backbone and I think it's great for developing apps and I want to take some of this new knowledge that I have now and apply it into these applications. So this will make more sense in a little bit when I start showing code. So I'm going to start showing this code right after this slide. So this right here is my idea of what it's like to create modules. So when you're looking at an app and I created this app a while ago called GitHub Viewer and I've recently upgraded it, updated it to the latest technology out there, all the latest plugins. One of the ideas around it is that you have small templates that can get rendered independently. So if we look at the user list, it's not like the entire header becomes this one giant thing that has to refresh every time a new user item gets added. These are distinct smaller templates that can be rendered independently. So I'm going to open up the code for this. Just I'll give an example of what this thing looks like and then show you how it's structured. So this is using the new Bootstrap 3 which is they've gone with the flat design which is kind of, I kind of like it. And we see here that this app simply you give it an organization, click on a user, click on their repos, and then it'll asynchronously load their commits. GitHub's a pretty good example for this. Just they have a nice API and it allows you to really flow from one thing to the next and show multiple views working independently. But yet all code is set into the same state. This is probably just GitHub taking forever. So I'm going to move into what the code looks like. This font size is going to be a little small so let me change that. Okay, so I had mentioned before that I have code structured in such that my modules and my code that I've written goes in a separate directory from where the vendor code goes. So this is what you'll see at the very top level. You'll see app, this is where my application code goes, vendor, that's where the package management, third party plugins, anything that I've written that isn't actually in a package manager will go into the JS folder. Anything I've pulled, so I think there's like one plugin here. Yeah, so it's just like one of my random plugins that just get dropped in somewhere. Okay, so the way this thing is structured with modules, I have the idea of a commit repo user and they're all put in here and those represent the objects that we just saw on the screen. But one of the issues that I found with a very large application written in backbone, if you take this approach and you have numerous modules, so let's say you have like maybe 25, that's 25 rows down your screen. Now your templates are in a totally separate directory. That's another 25 down your screen. So when you start going for like, let's say I had to commit and I wanted to work on just the commit module or now we could save in component, I would have to open this file and it's no longer relative to where the code actually is. So one of the big steps that I've taken and I'll show in the, so this is the refactor branch, now there's an even better refactor branch. And that brings all of these resources together. So when you're thinking about editing one region of the screen, you may find that the JavaScript and the CSS are kind of close together. You're doing stuff right side by side. I know there's a few editors out there that can actually kind of bring these items together. It goes off of a naming convention in your file system and group them locally. I mean, that's fine if you have that editor but I haven't found anything like that in them. So I do that manually. And what I'm saying is just organizing such that the template, the JavaScript and the CSS are all together. Okay, so we see in here though that there are templates. So the commit, every one of these modules has an item in the list just so happens that that's how this app is structured. List items just render individual models and the lists render all of those individual and sort of the container that wraps around it. All of these modules are currently written in common JS but the way that I have this set up is over the wire, there's middleware that will compile that to AMD and then run in the browser. And what I'm gonna show you around with ES6 is the same approach, only one more level. So now it's, well, it's not one more level. It's ES6 to AMD to the browser. This is common JS to AMD to the browser. It's kind of funny that AMD is like this great format that you should compile to as your target and then run that in the browser. But writing it at a large app scale, putting the finds everywhere I find gets very tedious and it's not very appealing. There's something cognitive about it where you just notice it, you see it and you don't want it there. It's fine when you're developing modules, I feel. I'm sorry, when you're developing a library that's consumed within an application but when you have so much application code it can get unwieldy a little quickly, especially if you have a ton of dependencies you can't use the array syntax. You can just get a little weird reformatting and such. I find that this is just a lot better. So this is, yeah, again using the common JS syntax on attaching just collection views. One other thing that I'm doing is kind of different in here is I'm combining different types in here. So I have a collection and I have views that are defined. This was a practice that I used to promote pretty heavily because all my modules used to be really small. Then I worked on a larger app and I found that, okay, the apps I thought were large weren't really that large. This is really not the best idea. So in the next refactor, these things are actually broken out into separate files. Collection is in its own file, views are in its own file. And then when we see how ES6 works, you'll notice that it's just so much more convenient. It's a lot easier to deal with all this kind of stuff. So yeah, this app is pretty basic. It's just like, it's got some CSS, got modules. Build process, I use coffee script for my grunt files. I've written a post on this. I find that coffee script, not always tolerable for me as a source language, but as a configuration language works very, very well. Less things that you have to see when you're in here. And I feel like less things that I may accidentally mess up. But all this stuff does is what I talked about earlier. This will clean the directory, this will run JS linting, this will minify, runs the process HTML task I talked about. So this is just one way of doing it. This is a pre-made configuration that you guys can grab from the back and boilerplate repo. You can run it on your own, kind of take what you want. BBB used to be all or nothing. So the back and boilerplate build buddy, weird acronym that I came up with. Yeah, they used to be all bundled together and it was like do or die. Like you either have to do it my way or it's just really a hassle to do it your own way. I've fully embraced Grunt now and it's modular plugin architecture in order to provide my subset of plugins. So I have a Grunt BBB server that does on the fly less compilation. It does on the fly SAS, doesn't do SAS, SCSS syntax, but it for sure does stylus. And those are all parsed out of an index.css file that contains a bunch of ad imports. So it uses the native CSS way of loading in CSS for development. And then during production, parses through that and builds all of those for you. So you can just drop in stylus and less files in there and they will automatically compile. So that's just something nice that I happen to like. A lot of people like watch tasks. Just don't use this. Use your watch task, have that run and then have it live reload and I'll work just as well. So yeah, BBB server has a few things that are specific to my workflow. I have a very strong reaction to watch tasks that I just get very frustrated with them. They always die on me and I never know why something isn't working. So I'm committed to over the wire transformation. So the other thing that BBB server will do is the common JS transformation and the ES6 translation. The second task is run BB require JS that's sort of like hand in hand with the server. Server helps you while you're developing. Require JS helps you build. There are plenty of other require JS run plugins. Mine just has to be a little more tailored. It has some defaults that work better for this project. And then the last one is styles. That one just does what I mentioned before. It iterates over your index.css file. And I'm just saying, let me actually show you the code here so it speaks for itself. So you see here that I'm importing the bootstraps CSS and I'm importing this stylus file. And it just gets handled over the wire, gets piled down for you. So you don't really have to worry about that. It'll be nice once we get stylus source maps and SAS source maps fully baked in. I think they're only available behind the flag right now. Actually, it might be a good tool. But yeah, so we're getting source maps all over the place. There's a lot of preprocessors that are being used that make things easier for us to do. So there's like vendor prefix saying all that. And there's good reasons why we would want to use a preprocessor. And I'm actually a little slower than what I should be right now because there's a lot more to cover. OK, so yeah, that's all this stuff is for the imports. We see right here the style sheet loads that index.css. Just that CSS, it loads all of your stuff. So you can just put everything modular in there if you wanted to and then build out. So I think what I did is I full screamed. OK, so universal module definition. I brought this up earlier. This is a beast. So imagine you had to write this at the top on every single one of your files because you don't know if it's going to be included in a node environment. If it's an A and D environment, you might want to switch later on. There are people who advocate using this. I find this is best used as part of the build process for a library that gets objected by or consumed by others. It's not something you want to manually maintain. And it's not something you want in your raw source file. So there were attempts to get this into Backbone for a while. And I fully agree now that nobody wants to maintain this. Nobody wants to look at this. This could be a part of a build process. Backbone simplicity is it doesn't need a build process. So really, you don't need that. And we're getting by fine with Backbone as it can be loaded in node environments. It can be loaded in browser-file environments. It can be loaded in AMD environments with shimming. This is kind of a nice to have. So this is like if you want to go the extra mile, you already have the build step in your library. You want to add this extra chunk. This thing will actually go through, figure out what environment you're in, and then know how to call your code and return that object that's represented by your module. So shimming, I just used that term. Shimming is something that I had come up with a long time ago to solve a problem. And I don't know how many people I know shimming is. How many people don't like shimming? Yeah, so I knew that would happen. It's just like I mentioned before, they're purest and this is completely valid that you don't want to do anything weird. And what shimming does is, let's say you have a module loader AMD. AMD expects you to define a module a certain way. You're loading arbitrary JavaScript with this because you're loading Backbone. Backbone doesn't support AMD. What are you, SOL? No, you're not SOL. What you can do is you can map what Backbone's behavior is in that environment into the module system. So there's three components to that. There's specifying where this file lives. So I'm specifying here some plugin lives at this path. And then in my shim configuration, I map that same name. I say, what are its dependencies? And you can usually pull those out of a Bower Confeg out of a package.json file. And that will ensure those files are loaded first. And then you can do the exports which takes whatever it's, whatever this file is exported into the global scope, put this as that object. So if anyone ever does require some plugin now, that's some plugin will act as if it had AMD, had it been written in AMD. This solves the problem temporarily. I think we're gonna have to do something better in the future. It's really tricky with ES6. I feel like once ES6 lands, we're all gonna gravitate towards that and I'm being a heavy optimist here, but that would make things a lot easier. It's just, it's hard to get everyone to agree on a single module format. Nobody's gonna put UMD in everything. So I feel like for right now, the best choice that I have is to use required and shim the things that I need. One problem with that is that shimming gets really tedious in a very large application. You're manually maintaining your own configuration for all of these modules. And I really feel when you start using a package manager that the package manager somehow needs to be tied into the config. And I spent a lot of time talking to Ben Almond about this and he agrees wholeheartedly that a configuration's not something for you to maintain. How many of us still maintain our package.json file whenever we get a dependency? Once we've learned about save and save dev. So if you're installing node dependencies, you can have node actually maintain your configuration file for you. I feel like that's what these things are for. I mean, just the fact that NPM does it and it's one of the most opinionated package managers there are really tells me there's something there that a package manager should be able to modify a configuration file and do that for you. One of the main benefits though I found from package managers are really elevate your dependencies up to another level. Kind of gives them more meaning when you're building your application. So when you install a backbone, it actually gets the correct dependencies and ensures that those things are actually correct. Put some on the top level for you. And just make some a higher class citizen and just pasting stuff in the files and throwing them into a folder. There's still a lot of debate, a lot of discussion I think is all completely reasonable as to whether or not you should use package manager in your application. But for right now, my use of them has been purely experimental and evaluating like am I getting a lot of benefit out of this? Because I can't stand here and promote and say everyone should use a package manager because oh it handles all your dependencies because stuff still gets messed up. Like just the other day I tried to install bootstrap and Bower again somebody deleted the tag or something so we couldn't get it. So there's always problems with that kind of stuff. But I think package managers are a great idea. I think that people are moving in the right direction. And again maybe in the future stuff will be a lot easier and we won't have to worry about getting an AMD module out of the package manager and writing a config. It's kind of like one of the darker sides of the web right now when you're assembling a large app is that you do have to maintain a lot of configuration or so. This is something that's an interesting concept that Alex, yeah Alex Jackson had told me many, many times and I always took a deaf ear to it and it's building only what you reference in the app. And I did that for all my scripts, my modules but I never did it for my templates or my CSS and I never thought I really needed it until I was working on a large application and I realized we had a lot of template debt that was building up in our templates directory. So what I used to promote is that you would have a templates directory, you would dump all your templates into that and then you would just iterate over, find everything that ended in .html, process it as a pre-compiled underscore template and then save it in a giant file. And that works really, really well unless you have like 30 or 40 templates that are actually kind of large because they're full of comments that are getting injected into your output. So I really like the idea of building only what you reference and this is like your script loader now becomes a resource loader and I'll show you how this works in ES6 too because it's pretty slick what you can do. And I have a few tips that go along with being modular and these are just things that I picked up. I use an app object, a global app object that I either attach things to or I use as a getter only. It all depends on the application but for the most part I use it as a getter only so I'll put like app.api and that'll be API prefix to where I'm getting my data from or something. But it shouldn't modify the state of your objects because when you're doing testing and you're requiring your module that now internally is requiring this global app, you wanna make sure that global app isn't doing anything clunky. That it's really the only exception I can think of to modifying object state in there is when you're configuring plugins or you're configuring something that's not really going to be detrimental to your module being run. And then I have this here where it says decoupling the application running from loading the configuration. I used to do this where I would load the config and then there'd be a depth property in there and that would load my applications. Every time I included the config file I would run the app and that seemed really easy because it was like this nice configuration, it's tightly right in there, I didn't need an extra file. But now I make an extra file that actually bootstraps and it runs the config and AMD gets all our paths, all that shimming stuff that I talked about, make sure all that's right and then it loads the application once that file is done. And I find that that's really good because when it comes to testing I can now load the configuration, load a specific module, make sure that that module is set up because all of its dependencies and I don't actually start the application, it doesn't run. So if you're thinking about doing a require.js and the reason why I'm putting these require.js specific slides in here is like everyone talks about require.js and I've seen a lot of people taking notes about it and they're interested in doing this in their own app. This is something to be aware of. It's like you're gonna see a lot of examples once you start building your app a little bit larger that show bootstrapping your app from the config. And I'm not saying that that's the worst way possible and you can't possibly do testing with that. There are some ways that I've seen now where you can disable that depth property. This feels like the cleanest way to do it and it just seems a little more logical to me. Okay, before I get into web components I do wanna show a lot of the stuff I was talking about because we're at nine minutes and I'm really excited about this ES6 stuff that I got working and it just blows my mind that it works. Because there have been so many folks. I don't know if everyone keeps up with the JavaScript weekly and all the Twitter traffic but Ryan Forntry recently wrote something about developing ES6 now and then there are a bunch of comments that are like it's not ready, it's not ready. So I wanted to put it to the test. Let's drop it in this GitHub Viewer app and see if it will actually work. And there was a little hiccups here and there. I was still learning the syntax a little bit and the transpiler is a little funky. But what I managed to do is build the AMD step first and then from the AMD step pump it into the existing AMD step that was already in GitHub Viewer. So I just added one extra layer which is the transpiling of ES6 to AMD. So let's take a look at that because it's really neat once you're sort of bizarre. So I redid this app and I changed the folder from modules to components and really this is just a semantic meaning that there's more than just JavaScript in this folder now. Or there could be, in this case there actually isn't because there's not many styles that are necessary for this. And I saw the template circuit down here. So what I've done here is I've defined everything in ES6 so you can see how the syntax is slightly different. But when you're in the case of something where you need a template, oh, I'm sorry, there is templates in here. You can import using the same text plugin and require JS. So all the transpiler does is when it goes to AMD is it takes whatever you put inside the quotes and then drops it in the AMD. So I can actually use any AMD plugin I want, any required just plugin and it will just work this way. And one thing else I noticed is that it explicitly needs semicolons. So for all these semicolon haters you absolutely need to use semicolons when you're doing your ES6 transpiling. But it's kind of nice how this looks though. At least this is what I think. It's like I'm defining my dependencies at the top. I need the application object because that sets up and makes sure that layout manager is loaded and all these other things that are inside of here. And then I'm importing the template text just from this text file that's right relative to that directory. So if I wanted to work on both of these at the same time it's really trivial to be able to work on one here and then on the other. What I want to show later on is the last piece in that scope CSS. So I've been doing a lot of experimenting with scope CSS and I'm super excited about that. I'm actually more excited about scope CSS than ES6 because when I did my slide deck I have a cut each slide is unique and it's slightly different from the others. And it's really annoying to have one giant style sheet where I have like slide dash one, slide dash two, slide dash three. So instead what I did, oh God I can't bounce around like this I gotta stay focused. Okay we're gonna go through the ES6 stuff and then I'm gonna show the scope CSS. All right so how this actually works is that we clean out the directory. We do the process html so that processes that index html and make sure all the paths are written correctly and it pumps out in the distribution directory. Then it does the copy task. I do the copy task because when I do the transpile it will dump the transpile, it will dump every file that's in my app folder exactly as is hierarchical but it will not copy over the templates. So I just do a basic copy task first and that puts all the source inside of that distribution directory that I may need to reference. Then I run the transpile task and the transpile task is not written by the guys who did transpiler but it's just a guy who wrapped it and just allows you to expose the options. So you see here it's really simple. It's like I specify the type and I wanna compile down to AMD and I set current working directory to the app directory and the destination goes into the disk folder and then the source is everything underneath the app directory. So that's a gloving expression right there. If you're not familiar with gloving it's a very powerful way of expressing many file paths in recursive depth. So when you see a star star that means go recursively into any folder and then the slash star to JS anything that ends in JavaScript. So that will go through and that will compile everything into the disk directory. So if we open up this let me pick that same component that commit and now we see that it did that really annoying AMD syntax where it's an array and that giant array is just got that text thing that gets thrown in. You can see how it maps. It just does like a one-to-one mapping of this and then this gets pumped into the required JS task that I already had. And the required JS config this is where I get into a little bit more of the Linuxy philosophy. I provide everything available as an option. So you can see very quick required JS is one of those things that is so mind bogglingly hard to understand. Like doing the simple cases is really easy but then you wonder like you can see that James Brooks just added these options every time somebody has hit a bug because he's got conflicting options and he's got comments that say this option is true and this option is false then this thing happens if this thing is it. So I've tried to find what I think are the most reasonable defaults that you need to build an app. So this just sets like the base URL to the distribution directory because now we have transpiled source. So grab that sets almond as the name almond is just the little shim that does require inside of the it's a synchronous require that doesn't need like the 14 kilobytes size required JS. So I just in my builds I use that instead. And then this include and insert require this is all part of his he's got like this little thing that says if you want to use almond use this approach so I followed his approach all this does is it ensures my main bootstrap. So that's the thing that loads the config and then your app gets included and it inserts a require to make sure that it gets run. The reason for that is that if you don't have insert require it will just put everything into the document but nothing will ever kick it off. And we get that kick off in debugging because we have that data attribute on the script tag. I didn't mention it before but you may have noticed that in development there's that data main and then it points to it that is equivalent. That's like an implicit way of doing insert require. Find this dependencies because when we do the nested require calls instead of that main file we require the config then we're required the app by default and only checks the top level to won't find nested ones. I enable that. I don't need to go through every single option here. Really what's important is that we get source maps and those are done through Oglify.js too. So now I want to show on the fly ES6 stuff. So I was running the other GitHub viewer before make sure that's killed. It's from the ES6 version. This isn't quite like coding it's live presentations and these again I usually do terrible with these. So this thing is loaded and we see it's transpiled on the fly. So I didn't have any build setup I can modify that ES6 reload it in the browser and they'll compile so that I can actually write ES6 as I want refresh in the browser and get all the benefits of AMD doing the asynchronous loading during development. So that's pretty sweet I think. I haven't seen how many people do this. And then it gets better because once you build so I'm gonna do a little build over here and that's front default is just the default task. If you don't specify default and you just run grunt it runs the default task but since I'm doing default and another task you have the right default though. So this will go through and clean up the directory process the HTML, copy all those files, transpile yourself quick that transpile it works that is really fast. It probably just takes a little bit of time because it does on the fly and it does on the minification and then code removal and it really optimizes that build. And then I do a little compressed task here. The compressed task is interesting I'm not gonna go too deep into this but basically you can pre-compress into a tarred file tarred GZIP file your source code and then have your website exactly serve that instead of having to generate that compression on the fly. So that's kind of a really neat way of optimizing slightly. Okay, so now I have everything built and I'm gonna do that replacement that I talked about earlier inside of that source map file. Maybe I'll write a task that just does this for me but for now it's not too hard to I'm just gonna rerun the server. Okay, so they have just instantly loads because now we're only loading two files including here, three files. If we go into the source, if we had a bug in here, wouldn't be able to see it. You wouldn't know what's going on. You would just, in fact, let's induce a bug. I just say, I take my word, router inside of the initialize for this router. I'm gonna throw a new error, yaw. Did you already just felt that right? Yaw. Yeah. I hope so. Sure, I'm just gonna say yeah. And then server. Okay, so now I'm gonna build this all out again. Oh, and now I have to do the source map file again. This is tedious. So yeah, I would say if you wanna really experiment with this kind of source map stuff, use Chrome Canary that actually supports the error. Oh, wait. Now I'm confused. Let me make sure that I get this right. This shouldn't have been, no, no, it was a pound sign. I'm supposed to be getting a pound sign out. Okay, sorry. At least the demo isn't here. Who's that what that was? That's not a good deal. Point being though is that source maps are enabled here and that's all I really wanted to show is that you have one file where it's all bunch of jargon. But then when you get me through an exception, you can go into the source here and it's actually mapping back to that transpiled node. So that's really interesting. It's nice to have, especially when it's a really obvious error, you can see exactly where in your code it is. Line numbers aren't exact. It's not the ES6 stuff that you're used to seeing in your editor, but it's one way of doing it. It's getting us there. Okay, so I have 10 minutes left to go over some web components stuff, but I did wanna show this off right now. I'm gonna push up everything tonight. I'll make a big tweet about how, hey, you can try out ES6 on your own. Cool. See, I really like this. I like the fact that I can do ES6. These people weren't lying. They weren't misleading us. We can actually write ES6 now, compile to AMD, and then run that in the browser, get our source map support, get all our compression. Everything does what we want it to do and it's a lot cleaner look. So I'm gonna take a really stronger look at this, try this out a little bit more. Maybe report back next year on how well this is going, but it will also be interesting once if a browser supports ES6 modules. Currently none of them do. All right, let me get into components real quick and then I can take some questions. Okay, so what components are a spec that's currently in W3C? I think now is the best time for us to be vocal and try these out because they're heading in the direction that I may not necessarily agree with. I love the philosophies behind everything they're doing. They're getting all of our CSS, all of our JavaScript and all of our templates together as one and being able to distribute that component. It's actually a collective of a bunch of little things that, again, get assembled into something bigger. So they have templates, they have decorators, custom elements, the shadow DOM imports. And I do NDV here because it's actually only being worked on in Palmer and it's in Chrome Canary if you enable that flag, but there's no spec for it. It's kind of like what's going on here. It's like just Google playing around with stuff and putting it in their browser. So we should probably pay attention to this because this is gonna be what we're expected to use as live data binding in our templates. We're not gonna be using handlebars, we're gonna be using NDV. So I think people should really take a good look at this and be vocal about what they don't like. So the idea of what components are that you're defining, the way that I've done it within backbone is that we have backbone views that are one to one to one DOM element and that's really how you think about it. You just make a new instance, you bind it to one element. This is a little different in that you define a custom element and then the code will actually react onto that. So my entire slide deck is actually built this way and I'm just gonna show that real quickly. So I have components up here and then I have one component that I've defined and it's called slide item. So for everything in my template, for every slide that it finds it creates a slide item with a given ID and a slide index that has that, I don't think it's attached to it. That just says what I do notice. The script is using this little backbone plugin I created called backbone.component. It might get released, it might just be adjust. It's really not that much code. It's built on top of LayoutManager. You can see here that I can specify a tag name and I'm using the tag name here as a custom element attribute. So you can define what attribute you want this to run on. You can specify a template and a style and for mine, all it does is remotely load them from the file system. And what's interesting here is that it does scope CSS. So I'm gonna show a little demo of that, but this is really cool. Scope CSS allows you to write your CSS like this where you just use the app host. This is something that's being proposed in web components to reference the host element itself. And then everything underneath it is actually scoped to that app host. So I can do this p tag down here and this will only be affected inside of the slide items. So there's no magic going on. All I do is I process the slide style sheet rules. I find the selector text property on a given rule and I prefix it with whatever the custom element is or if it's inside of another element and I'm using the scope attribute, it'll make a data attribute and I'll scope it to that. So yeah, that's all this stuff does. There's a library called scope CSS that I've written that you can try out on your own, put it in your own projects. That's just tbranian on GitHub, scope CSS right there. It's actually ready to have people start using. And what those scoped attributes look like on these slides. So you see how I mark down up here, this is just a mark down file. At the bottom I have style scope and now I can write scope CSS for just this slide and I can write it just using any like paragraph, H1s. And one of the cool things with this is that there's a happy accident in Chrome that when you modify selector text to prefix it, doesn't actually show the prefix. So when you're looking at it in the inspector, you'll still see just p, you won't see the prefix in front of it. It's kind of nice, it's like, it gives you like this seamless development feel. But that's just a browser bug. It's probably gonna get fixed at some point. Anyway, so I've shown you guys a lot. There's gonna be even more in this talk originally when I found out I actually had quite a bit of time to talk. There's so much I wanna share and like maybe I'll do screencasts, but this is a good introduction I think to just seeing what kind of future we have in Backbone. I think I'm really low on time right now so I'm not gonna be able to continue, but at least I was able to show you guys some of the stuff with my components. ES6, fun stuff. I'm actually excited again. I was getting really depressed for a while. I really liked AMD and then I was shown the light. AMD really does suck to write and I don't wanna do that. ES6 is really nice to write and it compiles down to what I do like. So I'm seeing win, win, win all over the place here. So I'm really excited about that. I'm gonna probably write some posts on book, book who blog, all this kind of stuff. It's just really amazing that it works. For once, they don't lie to me. Yeah. Yeah. And you know what, these slides are online. Feel free to look at the rest of this stuff on here. I just talk about like, you know, and there's slide notes inside of each one of these. So you can go through that. Yeah, that's my talk. So if anybody has any questions, like. Just a quick question about process. Where are we? One second. I'm right here. Oh, here we are. Process HTML versus, so my general development environment, in my development environment, I'm using Node with a server.js, or express or something. And I might be, and I'm deploying it to somebody who's gonna bootstrap it and some server-side page generally. And so I'm just curious, why use a process HTML as opposed to, you know, a server-side templating solution and just server-side environment variables? Yeah, I mean, that's totally valid, right? That if it gets you the outcome that I'm getting here and it's more flexible for that solution than by all means to use that, I'm a client-side developer by nature. So typically I'm writing client-side apps or maybe not even via server, so that's not always an option. I found that for deployment, it's really nice to have one HTML file, one CSS file, one JavaScript file, and that they can all work together under any server environment, and that's what this does. You can just launch an HTTP server, Apache, whatever, now point to that directory and just load your app. That seems really powerful and more flexible, maybe in your specific case with your custom deployment targets and who knows who's gonna be consuming it on the other end. Maybe it makes more sense to use the server. But yeah, I'd definitely employ you to, like, check out the slides, like how they were written, the custom components in there, the scope CSS, because the scope CSS stuff is like really smaller. So, awesome, yeah, thanks guys. And you know, please do talk to me. Sometimes I look like I don't wanna talk to you, but I really do. It's just a face, you know? Yeah. I really do. It's just a face, you know? Yeah.