 Hi, my name is Sunil Pai. I've been writing JavaScript for the last five years or so. This is just before Firework came out and we were still using alerts, which we still do. And we want to satisfy clients. Before I start, I want to really thank the Hasgeek guys. I haven't seen enough people thanking them for the amount of effort they've been putting in. Pretty shortly last night when I was drinking whiskey, these guys were running around trying to make sure that today happens. So thanks a lot to Hasgeek guys. I call this Amplify just because I like guitars. And the secret of every great guitarist lies in two things. One is the skill. You know, you get 10,000 hours of practice and you know exactly how to do what you want with a guitar. But then there's that idea of wanting to get the perfect tone out of your guitar. And it involves an amplifier. You might have a banal octave. So if you're electric, you want to do that, maybe a little post-processing. But in any case, that becomes a stack. That's his thing. And great guitarists are identified by that particular tone. You know, if you hear Joe Satriani somewhere, you know that is Joe Satriani. If you hear a little Metallica, you're like, that sounds like a Metallica song. And if you hear Britney Spears, you should change your entire music collection. My point is that you need to get your tools in a row. The idea isn't to get every damn tool that you can find and put it in your frontend stack. But you find tools that really help you and they satisfy a couple of conditions. They are effortless. You know, since you can drop it in and a little configuration and you get, say, a 10%, 20% increase in productivity. And it works well with teams. It's not that you're working away in isolation. You're working with a group of teams. I work in Yahoo. Yahoo does some very serious jobs. Douglas Cockford works there. I mean, he doesn't really write a record so much as a guy, a slight messiah. But there's a lot of serious jobs to work that happens there. And we try to make sure that everything is as optimized as possible by the time it reaches the browser. Or at the very least, we try to make sure that your page is showing you something before you even loading scripts. We want it to be responsive. And we have a whole bunch of things that we use in the process, but they all follow the basic same principles. So you're not going to see a lot of code during this talk. You're going to see suggestions. If it's something that interests you and you haven't really seen before or haven't considered putting it in your stack, please write it down. Feel free to investigate. Feel free to ask questions. But they're basically the same things. You, so as I was saying, I love setups. My setup, I have something like six tools and I like making a build in one line. Just run it and I love having builds automatically done when I do a comment. I do all those things. I try to make sure that I'm as efficient as possible by the time I press it. Let's talk about you guys. Bad programmers raise their hands again. What programs? Bad programmers. Bad JavaScript, front-end programs. You are too. It looks like you're late. I'm very tears. It's fair enough. Let me tell you how your career started in JavaScript and stop me if I'm wrong. It started off by writing inline CSS and scripts. You thought that was the cat's pajamas, man. You can make your header change color if somebody clicks something. And that was pretty cool for a while. But it's maintenance hell. Like I said, this is all my code which you can't really see. In any case, if you can notice, you can put this light on. Yeah, it's not a moment. Not a moment, not a moment. Oh, whole function. Nice data. I registered it in this way. Yeah, I keep talking. So it starts off with inline scripts and CSS. And you imagine, oh, cool. I can do stuff directly on the browser now. And it looks cool. I can make a little hover state thing. I will get a menu drop-down. Of course, you have to understand everybody hates those menus, so please stop doing it. But you can do that. And after that, you decide to yourself. You know what? I'm going to take all my scripting and I'm going to put it in a main.js file. Fair enough. I'm index.js. But my point is that this file has no structure or organization. You say dollar a.hover.click. You write your handle right there. And it's endless function of the function of this going on and on. And if you need to use the same function, but a little differently in another place, you have to repeat the damn thing. And the moment you change the CSS selector somewhere, entire code breaks, and then you need to find out where it's coming from. This was phase two of your JavaScript career. And you figured, OK, this is not working. This is why every three months you wanted to add a feature, you had to rewrite the entire damn thing. Correct? OK. So then you... And this is what your file system ended up looking like. Where you have main.js, then you have a main three.js. And... I should be. I should be. I should be. And then there's a v4.js for the fourth.js. And then you have a widgets.js that you got from the boilerplate, but you never know what to really put into it. You don't know what a widget is. This is my code, by the way. Just so it's clear. This is what I have written. I have to go through my... So you did that. And then you decided, you know what, I'm going to try splitting it up into a few things. But in the end, then you finally have it on your HTML. You have a string of script types with absolutely no relation to each other, no matter what. And again, you have v4.js here, you're loading underscore here, possibly a typekit thing here. And there's nothing telling you what happens if the script fails to load or even if it's loading performately, if it's coming from the same place, if the protocol is right. It's all gone through this. Finally, right now, you're probably at a place where you love backbone.js. And you're like, okay, you know what, I can write models, views, controllers. And that'd be cool. But then again, since you're just bouncing into MVC by saying backbone.js, it's very lightweight and all that, you're not really separating your code. Your model code has a this.view.update link. Your view code has a this.router.go to this action. That doesn't really work. You're not really having the separation. It's a lot better than that. But we can make it a little better. So my point is this sucks. This sucks not just for you, this sucks for the people who are going to be touching your code. This sucks when something breaks at 3 in the morning and you don't know where to find it. This sucks because you have to, how many people write unit tests for the JavaScript here? Oh, please one. Oh, thank God. Thank you. One person. There is absolutely no reason, one is there's absolutely no reason for you not to be writing unit tests. I'll get to the topic in a while. But second, if you're not writing unit tests, there's absolutely no way to prove that your code works properly across anything without actually going and clicking and your CEO finding out and he's like, hey, this isn't working. What the hell are you doing? And you're like, oh, I'm sorry, can you do another patch? That sucks. The point, what we want to do though, is own the browser. We are going to stop waiting for back-end guys to finish their APIs. We are going to mock our own data. In fact, we're going to use it as a reference point for other people. We are going to tell them, you know, what, here is one HTML page. It's the, everyone in Django, they call it paste.html. I think that's the layout file, it's the standard one. My point is that you'll have one layout.js or something and you say, okay, this is all we're going to use. We're not going to use any other templates. We are writing a JavaScript application here. We are using so much. This is what the back-end guys get and I will take care of the browser. I will take care of URLs. I will take care of API calls. I will write unit tests and I will show you how it works. I will essentially make it work without you having even interface with my code. I will fake Twitter client. I'll write it and I'll mock all the data. So this is what we're going to do. We're going to own the browser. We're going to make sure that finally when we're done with the work, it's all packaged, ready to be put onto a CDM and we will put it on the CDM and it'll be, it'll be, it'll of course be referenced in the HTML sphere. Until then, the back-end guys don't have to interfere. The design guys don't have to interfere. You can separate your code out into separate modules but you can just start working the moment they say code. Move on. I love code. This is my example of how I try to organize my code. It might suck, but it's something I'm not sure. A lot of people don't do this until they actually see the benefit of it. People have a problem with putting stuff into different folders because they figure, oh, I got to write script tags again. That's what build systems are for. So once you get over that fear, I like to separate it off into modules, a small initialization and I split it into a model and a view. It could be different. I have a generic util.js. Keep only utilities into it. Stop putting jQuery, change this A color thing. I keep my templates down here. These are usually JavaScript templates. That's nice because if I'm using a new project, I can use them on both sides. That's a big one. I keep my libraries here. I keep my jQuery stuff here. Some plugins and so on and so forth. My point is that you have to get to a place where if you want to work on a particular component of your code, you should know exactly where to look without having to search through it or without having to do a higher search. Fixtures. How many people? Okay. Not a lot of people use unit tests, but fixtures are ways to mock your data that your application is going to expect. When you're testing code, an old boss of mine used to tell me, he's like, when you're writing tests for a networking program, if you're writing a web app or so on, if you pull out your LAN cable and you put your Wi-Fi off, at least 90% of your tests should still pass. In other words, you shouldn't be depending on outer sources of data to run your tests. So fixtures are great. Fixtures are essentially an idea that you mock a particular response that you're going to get for a login call. And when you're running your tests or when you're running the app itself, when you're developing it, instead of having to ping a login API which the backend guy still hasn't finished, it's been days. Instead of that, you're going to get a response back in the format that you choose. If it's going to be failed, it's going to be failed, if it's going to be true, it's going to be true. It's up to you to decide how it happens. It's a great way to mock all your backend data, and it's an incredible way to draw your reference to the backend test. There's something called, has anyone seen this framework called JavaScript MVC? It's called JavaScript MVC. It's by Jupiter Concert. They have a great jQuery plugin, and I'm good with it. It's awesome. All you do is $.fixyourmagic. I'll explain what the syntax is, but all you say is you dump what kind of data you're expecting and what URL point you're expecting. It overrides your $.ajax, $.get, $.put automatically and starts serving the data that you do. Please notice, zero effort. So you can still write your apps, but you don't have to put a little thing that if test mode, then push this data, and if this, no, no. You write your app, it's exactly where you want it to be. And all you do is $.ajax, you can do it in this format as well. You say whatever URL it is, and if a fixture of magic is available, it just loads that instead. You can simulate delays. You can throw 5,000 items if you want to performance test your JavaScript app, and you can think yourself, well, that's a great idea. Wish I'd come back to it. Here is a sample. This is actually from their site itself. You make a bunch of tools, which are random tools, and you define a fixture. I hope you guys can see this. But it's pretty cool. You say $.picture, I think get request for to-dos ID, and that's still a generic. It's not even an exact URL. For that, you return to-dos that you generated right there. And for every put, for example, if someone wants to update a particular thing, then you just take that and you overwrite it with whatever was sent into the thing. Now, with this file in your STML page, it will load your fixture data, and it's not really going to be pinging an Ajax endpoint to it. You remove the fixture, and it starts working directly on the actual URL. It actually tries to do an XHR request, which is really neat. And you know what, another example actually. This nice to-dos.picture also has something called make function. You guys are familiar with it. All it does is it takes a particular format that you want, and it generates a CRUD template. Do you know what CRUD is? It's a template. So you can just use that directly. So if it's going to be a GET request, it'll handle it in a GET way, but I will set a PUT request in the PUT way. You guys really have to check this out. My absolute favorite application for this is Backbone. It's fine. All, if you've gone through the Backbone.js, people who have worked with Backbone.js or CNI, Backbone.js is this great super lightweight MVC framework for JavaScript on the front end. People are trying to get it to work on the node side. That's excellent, but I'm talking specifically on the front end. It's also fine. There are a bunch of them, but my point is, every time you write code for Backbone, if you've written Backbone code, you'll know what I'm talking about. And the problem is, it's very difficult to write testable code, especially for asynchronous code and where you're getting data from another source. But this just makes it seamless. As soon as you start your application, instead of writing your models and all, just define all your URL endpoints. Say, $.fixure.get, and so on and so on. You can save it in .json files as well, and $fixure actually loads it from those files as it just etc. requests. And the Pack-in team has a reference point. So the moment somebody breaks something, you're not going to blame. You say, I had my spec here, man. It's right here, and you're not sending data in the format I expected, or that we had actually agreed upon. Or once you have those fixtures ready, you talk to them and you make your changes, Next. You write all your unit tests for your models using this data. If you guys have used something like Jasmine for testing asynchronous code, the entire idea is what it tries to do is it spies on the function, which is the handler for when an Ajax request returns. And it tries to pump data into that and it assumes that it's going to work that way. That's a very dirty way to write the code test. But the thing is that since you've been using this to mock your data anyway, you don't really have to do spying on handlers and all that anymore. Assume that the data that's coming in is spying. You don't have to send anything extra, because of course the picture is included in the page. Speaking of which, you guys have to write unit tests, man. This is a problem that I face whenever I'm talking to developers. They're like, well, you know, JavaScript isn't that big a thing. It is a big thing. You have to get to a place where the browser is yours and you have to be a professional about it. And I think the greatest analogy that I've heard from an old Khalid of mine, you know how people say unit tests are for testing your code and it will create little graphs for it? No, not really. It's you get fixtures and you get unit tests together and it creates a spec. It's like how the guy, I mean your friend and developers, you know how they give you a JVG and they say make an HTML of this and you know you're right or wrong by looking at the JVG. The JVG in itself isn't functional, but just by looking at it as a reference, you know that your output HTML and CSS is coming out right. It is exactly like that. You essentially try to make a reference point for what your code is going to be and you keep that in the source code. The moment somebody breaks something in another module, immediately your unit test will fail. If it doesn't fail and you find the bug, write another unit test for that bug. Every single bug gets a unit test. Am I going too fast or am I... You guys want to object and say you're full of shit. Okay, fine. Essentially the form of a test is quite simple. Your framework, your testing framework will give you some function for a test and you pass in a function that you wanted to do something. If it's an asynchronous test, you might want to pass in a parameter done. Moka framework uses this. I'll pass you all the links after this by the way, don't worry about it. But anyway, you do something and you get a value and you make sure that value is as expected. You're writing a little function to add two numbers and you say add two and two and make sure that the response is full. It's really that simple. You make sure that your function does something the right way and if you pass it in the wrong data, then it responds in the right way again. It responds how you wanted to. It throws an error or so on and so forth. So every new bug, every new feature, every new issue, every new 3 o'clock late night call from your CEO varies. Like, I was thinking I want to change this to do a drop-down instead of a fail. Every single of those requests gets a new test. Otherwise, absolutely nobody has any reason to believe that your code works. You might say, well, look, I'm clicking on it here, here, here. And they're like, well, that doesn't work in IE. And you're like, oh, my God, I have to start up IE then and then click, click, click and it works. No, you write your unit test and you run it out of shot. Depending on the size of your code base, it might last a minute, it might last 10. It doesn't matter. At the end of it, you are certain that everything that was planned is possible. My dad keeps saying that measure twice, cut once. I'll measure it twice, I'll cut you once. So here are the buzzwords for unit testing frameworks. You might want to write this down. And QUNit is actually used by jQuery. They have 199% code coverage with QUNit. Or they hit 100. I don't know how to say it. Keep going around. Anyway, jQuery uses QUNit for testing its own code. It's pretty good. Mocha actually works now on the browser as well. Otherwise, it's an offshoot of Express. So it came from, you know, JS JavaScript testing. JS test driver, I think I spread it. JS test driver is a module from Google, which automates all your tests. It'll open up four browsers for you, run all the tests, make a nice little graph saying how many tests passed, how many failed, and send it to you, and do a bunch of things. It's really great here. Just spend a little time making yourself a better developer by understanding what the stack could be. So, of course, uses YUI test as a module for testing, and uses Yeti or Jute, depends on which team you're on, for actually running all those tests, transfer it in the browser, and so forth. Jasmine is the new hotness. It's from Pivotal Labs, I think. It's really neat. It's a little verbose, but it's fine. A lot of people are moving towards Jasmine right now. It's quite strong as a library. Point is, start writing in a testful code. Write your tests before you write your code. You will not write tests after you write your code. You do not make the HTML and then make a Photoshop look something like it. That doesn't really work. Excuse me? Which of the tools is best suited to do cross-browser testing as well, not just the unit? So, cross-browser testing. This is a little mixture. Something like QL and Mocha Expresso is used to write your unit tests, and then you would use something like JS Test Driver or Jute or Yeti to actually run them. It will run your tests in... You can specify your browsers. You can actually choose which browsers. You want to open up an Opera instance, a Firefox instance, an IG instance. It just runs your tests, collects the data, puts it together and gives it to you. The number one complaint I'll give you here against unit tests is it takes time. You have better things to do. Your better things to do is two weeks later rewriting the entire code base because you didn't account for something. Your better thing to do is surfing on Reddit. Trust me, man. I'm not in F7. The rage comic section is incredibly productive. I'm sure if you write unit tests and you can prove that your code was fine, you're not going to be rewriting it later. You might be refactoring it, which the unit test will save you. It will give you a reference point and it will bring about unicorns. Templating. How many people use templating in the day-to-day work? Whether you're building a website or an application? That's not too bad actually. How many of you define your templates directly in JavaScript files? Do you compile them? Where do you define your templates? Separate templates like this. Yeah, but when? Do you make a .gst file and compile it? I do server-size. These are the templates that I compile. So templating is... Maybe I need to take a step back here. If I've gone to smallish firms, 10 people, 15 people, there are usually some guys who are the back-end guys. Then there are the front-end guys. And the new client shows up and he says, well, this site is going to be like Facebook and LinkedIn together but only for midgets. That's his request. Hello, Midgets. They need a little space as well. So... I don't think I have enough time I need to make sure. That's one thing. I've never used .gst or white... Yeah, I'm going to talk about templating. I'm just taking a step back. That's what it might be. Anyway, my point is that he comes to you, right? And the designer guys are making a bunch of mobs and that's great. Back-end guys are thinking to myself, okay, we are going to make it web-scale and we're going to use MongoDB and so on and so forth. The designer comes up to you with five jbgs. It's a user page, user page of update speed. Whatever it is. And he's like, make pages for this so that the back-end guys can integrate it into their app. And you tell yourself, okay, fine, I can do that. You download HTML5 boilerplate. How many people HTML5 boilerplate? It's quite good. But it leads to stuff like what I'm saying. You download it and you make the login page once and you put in dummy data. It's fine. You have dummy updates. And that's another page. And you make another page for the user profile. And then it seems you have absolutely no idea how this is modularized. How this can be broken down into chunks. Instead of starting top-down, what you have to do is you start bottom-up. You start out by asking yourself what an update is, for example. It's a Sunil Pai 8 ice-cream. Sunil mentioned that. Short word. He ate ice-cream and rated it four stars. Okay, so let's say that person did action and gave a rating. And you think to yourself, okay, that's actually a repeatable element. Pretty sure I... But you understand the concept and completing. The idea is that you take repeatable stuff that's repeatable or you want conditional constructs. Based on particular conditions and based on data, the output will be so and so. If there are 10 updates, then it'll make 10 little... You'll run the for loop 10 times and make little developments and so on. Okay. I'm not doing a very good job of explaining this, but my point is this. You have a problem. I have a problem. Thank you. Start using templating actively before it gets to the application stage where the back-end guys are trying to put it into their application. If you're using Node, you can use one of N JavaScript templating languages. You can use JST or EJS or so on. Or if you're using something like Django or ROR, try to see if you can convince the back-end guys to use a platform agnostic templating language like Mustache. Mustache is good. The reason that I say this is because then later on when you're doing cool tricks in your browser and you want to render HTML directly, you can take the template by yourself and manipulate it by yourself. This actually, when you start doing this, the point is that at some point of time your boss is going to come up to you and say, I don't like the format of the update. What I want is an image and just the stars. Instead of changing it 10 times in that one page and not exactly sure what CSS it broke, you change it in one place in your template that you wrote to repeat 10 times. Do you see what I'm doing with this? Please use templating a lot. Your HTML has a living breathing thing as an output for a particular request. Don't think of it as a, I made the HTML and the back-end guys are going to take it and put their special tags into it and it's all going to work. That is incredibly difficult. This is your responsibility. Sorry, that isn't part of my slide. This is what I do, for example. I make them, as JST excited, literally put a slide in the contents of it and I have a simple JavaScript template loader. Very simply, very simply, I have a small template object and if it doesn't exist, I do an HX request to pull it and once it's put, I just compile it using underscore templates. Figure out what your solution for this is. Ask people around you. Ask me. I'm going to talk to you about it. But my point is stop being the guy, stop being the HTML guy, stop being that CSS guy, be the guy who owns the browser. This is a module that I love. I've been using it so heavily. Everybody here knows what push state pop status? Wow, really? You use it on JS2.in? That's right. The idea is that you can change the URL in the browser without doing a reflection. Ajax was all about making a request without changing the URL. You change the URL and you can do it. In JS2.in, it's pretty cool. You push, for example, a schedule and it slides and you can do a pretty cool transition and you see the URL and it says that schedule and you're like, oh, I didn't see the reload app. You can do a lot of cool things this way. In essence, you have to understand that what is a URL and I'm going to mangle this definition. But try to understand it as pointing you to a resource. You say facebook.com. It's pointing you to the JS2 resource on Facebook. Now, the usual traditional way of getting yourself to that destination is a refresh or you load the page, but now you get to define what transition happens on the way to that destination and what the experience is for a user who's moving through your site. Not just on one page, not just where it does a roll over but actually you think of the entire application as a machine that you're showing in a particular way that you want. You can do a bunch of buzz word stuff. It's HTML5 and you can do CSS3 transitions and a whole bunch of things. It's pretty cool though. You should definitely check it out. Backmode.router is the module that I recommend because it's ridiculously simple and I don't want to talk about details but please, please, please check it out. Check out Backmode in general and related families of MVC players. Examples for this example, applications that I've used this, my two favorite right now are 37 Signals Mobile and LinkedIn Mobile. LinkedIn Mobile has done some stunning work with the mobile website. They use asynchronous translating and a whole bunch of crazy stuff. I mean, they've got great engineers. Don't get me wrong. But it's really great to see that this is now the main stream. This isn't an experiment anymore. This is now everywhere else and there are fallbacks for IE and they'll use hashbacks and Google won't have a problem with it. Google will actually render your page now even if it's being generated by JavaScript. Quick story. They even render SVG. Google renders the SVG on your page even if you are having animations. So don't worry about Google just losing just because you're using JavaScript and all that. I want to quickly talk about deployment. How many of you people package your scripts before they send it out to production? Awesome. So that's one. Actually two, three, four. All of this. It's kind of hard. I get it, right? Because it actually takes a bit of planning in the beginning. So I'm going to walk you through it. According to me, there are three different types of deployment. Personally to me, it could mean something else. There's development. When you're working on your laptop or on your machine. At this point of time, I don't want my scripts minified. I don't even want them concatenated. I want them loaded one by one. So when I find a bug, I can read the code that's doing that. I want my CSS also nice and big with comments. That's my development stage. Performance isn't really a priority right then. Performance. I can't have any reliable performance measures when I'm doing it on my laptop. Staging. Staging is everything that production is except in a very secluded sector. So when you might have minified your scripts and CSS and made your image sprites and all that, they're still on the same machine. They're not really loading it from a CDN. Your database is also probably on the same machine and you don't have a master slave system. My point is that staging is to see a slice of real life usage and to make sure that when you do deploy it, at least your basics are right. Production is where you go way hardcore. You might want to inline some configuration data into your HTML and your scripts get concatenated and sent as one package. You cheese up and send it. I'll talk about that later. You might want to include your CSS into your JavaScript files. Kind of a cool trick. Point is that you have to get to a place where this is automatic for you. There are many, many projects or modules that help you do this. If you work with Django, then you know about Django static files or Django compress. If you use ROR, there's something called Jamet. That's actually written by the same guy who wrote coffee script. Jamet is pretty good. On the node side, there are something like 40. If you go to the node modules page, you will see a whole lot of them for building, packaging, deploying and all that. See if you can spend an hour or two to download one of these based on the system of your choice and see if it will help you actually do this. Because then that means that the packet guys don't have to worry about packaging your scripts anymore. They're already uploaded. They don't have to worry about your referencing it from. They still are doing what they want to do. They are writing business logic that acts as a foundation for your app. Your thing is just a client on top of it. That's why you need to really use it. That's why development staging and production is very important. I'm going to quickly start going through this. These are tips. Automate as much as you can. You are engineers. The entire deal about engineering is that you don't want to repeat yourself. You want to reproduce as close to what the production system is going to be on your laptop. You want to write fixtures that bombard the client with 5,000 requests a second. That's a bit much. 100 requests a second. You want to see what will happen when your little JS animation that makes tech crunch. Again, do a performance test on it. Anything. Automate your stop generators. When you're writing models and views. Write a little script that actually generates one file that says x.view is equal to backbone.view.extending. My point is your after code that you write is boilerplate and you shouldn't really be writing it again and again. That's why you download HTML5 boilerplate. It doesn't contain anything new but it contains a bunch of good ideas set into one place and you're like oh it's pointing me put your code here put your CSS here and that's a great idea. My point is automate everything that you do. Automate your fixtures, your performances, your grids. Great idea and it's actually common knowledge but run all your unit tests once you do a commit so that the moment somebody breaks it you know immediately somebody gets an email and woken up. Develop boldly. Once you have unit tests in your system you will realize how freeing it is to not worry about how you're breaking anything at all. Because if you do the moment you refresh you'll know it. It's not going to be a hidden bug where it's I mean there will be bad bugs of course but bad bugs there will be bugs where you will spend the night debugging them but all the useless stupid ones where you're like oh shit I forgot to put a var variable and now it's global scope but all these have to go away. You have to test your code and run JS into it, you want to use copy script doesn't matter develop boldly and try to push what the browser can do. Refactor slowly. When somebody says well I want this a new feature or I want a feature to do this or I want to use a different URL structure You have your unit test. Do it very smartly. Don't just wipe out code and then start developing for those unit tests again. That's a really a couple of good books to read on this but just the Wikipedia page on refactoring software code is phenomenal. What are the books? What books? What books on refactoring? These are books that I was reading when I was in the US but let me see if I can remember. There's this fellow who wrote Principles of Software Engineering South Indian News published by Sean O'Reilly. I'll give back to you on that. I'll put it in the list for that. And you will notice that as soon as you start doing all this and you start getting your system all together, you are done with the days of having 10 templates one for users, one for I don't know new customers and want to see how your database is doing. Only thing the back end guys are doing are supplying your data which is what they do and you consume that data and that's it. At the end of the day you have a very well tested API performing to spec and you want to write an iPhone app for it, it's ready. You have your API ready, you want to write an Android app for it, go for it. You don't have to sit and, well we need to make an iPhone app now so we better restify our API and you're like but that's going to break the old API that I've built for this thing. You follow a decent standard and your stack is complete and these are just pieces that you drop in my drone. This is the shameless plug of my project Sangam. This is where I actually try personally to solve all these problems. It concatenates scripts, it compresses them it's a little buggy but it works just fine for a few things. A couple of cool tricks it does is you can even supply it with .jst files for example and compiles it and makes it a JavaScript object for you to use. You can supply it a CSS file and it wraps it in a little JavaScript. So I have gotten to the point where in my projects, my scripts, CSS and templates are in one file. Sometimes I want to break it up for a bunch of reasons, performance reasons and so on and so forth but ideally at the end of the day my HTML starts with one script tag and then I continue on with the rest of whatever I want to do. Which is essentially nothing because the view, my view objects will be manipulated. Have a look at it. It's kind of cool. It has no test cases right now so I do not guarantee you will get it. But the reason I actually said this is, when I said that there are 40 of them on Node right now, it could be 41st. It would be great if you guys go back and write your own. It's a great way to actually learn about how systems should be built and how performance, how these things are made to your performance. Even on a local machine. I'm done. Two questions. Why CSS and JS is together? Why CSS and JS together? I just want to remove one HTTP request and it just makes it simple for everyone else. For example, a couple of projects where I've done widget code, where you know like here's our widget, put two lines of JavaScript, put one line of JavaScript into your page and it will start working. When you have 100 lines of JavaScript and 100 lines of CSS. I see where you're going. So one thing is compression removes a lot of that flow. And I'm not saying that concatenating your scripts is the absolute way to do it. In fact we don't concatenate scripts. You use modules and you use script loaders that are based on definition of what the page wants. You load one module and another module and another module. So that way it actually gets a few parallel requests. But I have noticed for about four out of every five projects that I use. Just compressing it all into one thing just makes the damn thing so much simpler. I don't have to worry about whether I've forgotten to load any assets. And if I have, I have to go searching in HTML for it. I have a nice little configuration file where these are already defined. My main.js, v4.js and there will all be there. And that's why I can actually remember the little folder structure I did. I define all that down in my config file. In my development state it actually loads all the files one after the other. But in production for me, for Sangam I've made it so that it compresses everything. You guys might want to check out AMD. That's asynchronous module definition. It's a way of defining JavaScript files as modules that can be loaded asynchronously. It's pretty cool. It's called AMD. I think people like require.js and all require.js and yepnope.js uses but yahoo also uses a version of this. Slightly different. It doesn't conform to the spec but in yahoo that's what you do. You say yahoo.use event and then you write a function callback that once that event module has been loaded or if it's already loaded this pass a reference to so and so. What do you think about web is shifting to making websites with CMS rather than coding it? I'm sorry. Now people use CMS instead of just making a website for pure coding. So the JavaScript part of it is very poor. There are a bunch of modules coming together and it destroys the performance part of it. So what is the solution for that? Well because of CMS you load a whole bunch of JavaScript and there are multiple modules coming in from multiple developers. Oh okay so are you talking like third party JavaScript? Yeah. Like having one Facebook JavaScript other thing on Google plus thing and Teams and the different things that they come with. I guess if you use WordPress with a bunch of the team that somebody has made the team loads resources. What he's saying is that it's not your project anymore it's bunch of other things that you need to keep untouched because they need to be updated. So are you asking me what the solution for this? How do I improve my site performance? For one thing you should realize that stuffing a bunch of social buttons on your page isn't going to be to anyone trust me. I haven't seen one user study where actually I have seen a couple which do make it happen but I'm not talking about social buttons but rest of the thing like you have stuffing of modules and modules have their own JS. Do you see a problem in the entire process where it started happening? If you're saying that CMS the way your CMS loads resources is individually and in a very wild west kind of way I think you want to actually have a closer look at that instead of wondering about whether they should be allowed to load resources. A cleaner way would possibly be where your CMS I wouldn't say build script but the way you actually develop the CMS is your module defines requirements upwards. So by the time the page actually gets converted you get a hopefully cached version of all those resources together. I'm not exactly sure what you're asking but I hope it's somewhere in the general area. Do you all try to make CMS or something just start making a standard coding? Yeah, so of course there's a bunch of CMS stuff that happens in Yahoo. I mean that's essentially how news.yaho.com and yaho.com page works. You have frameworks which actually load I've just joined Yahoo by the way so I'm not exactly sure of the exact details but you don't specify these definitions of the modules in the HTML. You have these really ugly, I wouldn't say ugly but they serve a purpose. Where you specify the modules there you specify that I'm going to have a module saying this is going to be five hottest stories last week and these are a few resources that I need to load. When that page actually gets compiled into the HTML version, either for caching purpose or directly being sent to the client that page actually has those resources loaded properly and the modules all these rules that they need to follow for it to happen but that's how they do it it doesn't happen at the point of the client attack all the performance optimizations happen before it's even generated. What are single page apps? Yahoo made in the days of old when it was really popular and all the cool kids weren't using Ajax at that point of time they had one template on the left side that's going to be possibly a sidebar if the thing said slash inbox and it was going to load another template which had the other thing defined and all that when they call it a single page app they actually mean that it's loading multiple HTML resources if that helps like set more pages but single page apps have the new hotness I really like the word hotness single page apps have the new hotness where you can something like backbone.js you can define your views separately in JavaScript possibly in separate files possibly in the same file that doesn't matter and you load the resources required for that particular view on the client there's no different HTML as far as your HTML is concerned it's a bunch of script and CSS tags and a body placed where your JavaScript where your JavaScript can play it just gives you that's what I was saying at the end of the day your backend guys shouldn't need 10 templates for 10 different parts of your application it should be defined by you and as far as you're concerned you're just being given one canvas and you need to express yourself with that those are single page apps please feel free to google exactly that phrase single page app backbone or single page app spine it's crazy the kind of stuff people are doing with it nowadays like essentially jsfood.in is a single page app it's one template and you have little pieces developed separately it's still rendering HTML it's still rendering HTML not necessarily I barely do that now actually I use my HTML the server doesn't really need to generate HTML for you at that point yeah exactly that's what I'm saying it could be rendering it in a JSON format it could be sending you just data it could be saying it's written by ice cream 4 stars Athef Haider Biryani 2 stars he's kind of pricey that bit but it'll send you that and you have a template already loaded where you dump the data and it says single by 8 ice cream and give it 4 stars how awesome is that Athef Haider hated the Biryani 8 he gave it 2 stars the point is that it's still one HTML page even the output that you generate for it can be on the front end sometimes it's on the back end but I'm not such a big fan something like push tapes a lot of people use it in a very good way exactly they actually get HTML back something like on the GitHub page or PJAX PJAX does that very heavily again I'm not a huge fan of that but it actually makes sense for them because otherwise the amount of JavaScript and all that load is insane thankfully they just get the HTML and slap it into the middle of the page it works for them it works very well for them it could be a scenario where there are too many views and what would happen here would all the resources be loaded one go that is your fifth out of four out of five cases you don't really that doesn't really happen where it loads an md of JavaScript that doesn't really happen but once you do get that then you want to sink into loading modules on demand where you might have a definition which says x.100thview .load and once you say load it loads the entire definition of all that file and the resources that it needs perhaps even css and a few images that we want to keep cash so that's where you started adopting those strategies you just check out amd, JavaScript, require.js, fnop.js that's all am I out of time? am I out of time? thanks a lot guys don't forget to thank the Hasgeek guys they have been freaking awesome and cheers