 So I've been writing JavaScript for the last five or six years. My first memory of JavaScript is crying under my desk at about three at night, trying to figure out why I wouldn't do my Ajax request. Even though I copy pasted it faithfully from W3 schools and all that, it wasn't happening. That was the beginning of a long and romantic journey, so to speak. Anyway, so I've been writing for a while and my deal is that I've learned usually with mistakes. I've worked with bad teams, I've worked with good teams, I've worked with corporates, I've worked with startups, and as it turns out, best practices are there for a reason. It isn't just about process. Process is irritating when it comes to a whole lot of other things, but if you get yourself into a nice routine when you're developing, especially front-end code, and you have a seamless way of actually making a very short trip from writing the code to deploying it, it turns out your productivity increases by multiples, because you get to see your results like instead of going through a build process and QA in the center. If you can do a bunch of that as part of your own development workflow, you get to a place where you're super productive and you start seeing real-life results because you can match your production environment even more closely on your memory. So along the way, along the teams that I've worked with, I've come across at least the basic things that you do. Maybe not something as hardcore as doing... You can do your performance test when it comes to loading a dollar, but when it comes to running performance, that's a case-by-case basis. What you really want is to make sure that you have the basics right. No premature optimization, but you get your basics right to make sure your foundation is right. So my talk is going to be about those five or six things that you can line up in a row and seamlessly throw into your project without changing any of your own development work style. I will talk about how these things affect production environment, specifically when it comes to page load times, response times when the user is actually using it, the order in which these assets should be loaded and how it affects your first impression. I'll be doing this by taking a small app that I built in the beginning just front-end code and by the end of the talk, we'll have a deployable ready-built that you can deploy to anywhere and show you how to integrate in workflow. That's the goal for my talk, that's what I'm going to do. Will there be a demo? The whole thing is going to be a demo. It's a workshop, it isn't necessarily a lecture. I will tell you how I'm going to start. I'm going to start with, here is my code that I've just written for the last three days. Now I need to get it up on the server so people can see it and go live. What are the things that we do? Step one, step two, step three, step four. A good thing about all these steps is once you do it, you don't have to do it again. It's there as your foundation. That's the entire idea that it integrates into your workflow and you don't even see it as invisible. Ideally, you do a one-line build and it gets deployed and all is good with the word and your CEO really likes you saying, good job man. That's good.