 In the last couple of years, we've seen this community build. There was no such thing as Bangalore JS or JS Foo three years ago. There was no such thing. People tried. People miserably failed. And a big bravo to Hasgeek for coming along and fixing that for us. Big bravo to Bangalore JS, and a big bravo to every single person who was involved in making this happen. And more importantly, a big bravo to every single one of you who is here today to accept the fact that they're part of our community and want to do something more. So a round of applause for yourself. Before I start, I have a couple of small things to say. But before I do that, I'll probably slide through. You need to have slides for a conference. That's me, the small guy up there. That's my Twitter handle. That's my GitHub handle. Feel free to follow. I will introduce myself. Yeah, that's me. My name is Aditya. That's who I am on the internet. Right now, I build this app. It's called Wunderlist. It's a freaking-licy, amazing app. But I don't build it alone. I build with some really, really good people. And when I did this over the last one and a half years, I've learned a lot of good things about the way we build web apps. And more importantly, the way we put them on production. And I want to share those experiences here. They are not very specific to the way I did things with Wunderlist. But they're definitely very good learnings. And I would want you guys to make the mistakes that I did. Learn from my mistake. Learn from others' mistakes. Learn from the mistakes of the community. But before we start actual presentation, I have a few things to say. This is the third edition and the third year and the fifth edition of JSFoo. And this is awesome. I think the first edition was less than half of this. I remember it was. And whoever was there three years ago knows this is awesome. So thank you. Bravo to Hasgeek, Bangla JS, already said that. Bravo to yourself, already said that. And you have to say it with me. Everyone, we are JSFoo. Please. OK. We are awesome. We are JavaScript. And we are Open Web. So since we all said we are Open Web, can you please stop browser favoritism? Can you please stop just developing for one browser and then in a few years end up with a situation we had 10 years ago? Try to build for all browsers. Try to use all browsers. Give back feedback to them. Stop being this isolated community. Get involved. Get involved with the entire scene. Not just Bangla, the entire scene. You find an issue in a browser, go submit a bug request on, let's say, bugzilla for Mozilla or Google code for Chromium. Time to level up. Time to stop being individual programmers. Time to get becoming a community that others can look up to. Become probably the best front-end community or the JavaScript community in Asia. Let's just do it. Let's all get involved. Let's all create GitHub profiles. Let's all openly talk about the problems out there. Let's all get involved as much as we can besides our regular typist jobs. We are not typists. We are intellectual people who need to do more than just sit in front of a computer all day. So also the last point, a lot of us have come here from far. We have done a lot of work to share our experiences with you, to share a lot of good things with you. I think it would be respectful if you actually, at least, switch your phone to silent mode. Not just to us, but to the rest of the community that's sitting in this room. It's disruptive when the phone rings. It is. So please switch off your phones or switch to silent mode. And here we go. Who knows what is DevOps? So before we start, just let me give you a small hint of the way I present anywhere is I don't like a boring dull crowd. I want people to talk. Don't be shy. Have something to say. Say it. I'm not going to wait until the end for question answers. You have a question? Just say it. Let's make it interactive. There are a few people who know what DevOps is. How many people know what enterprise solutions are? How many of you have built an app locally? And once it's done, you ask a web master to take care of it for the deployment of the web app to production. And you never really touch the servers. How many of you have had that? So you mean all of you upload directly to servers? You work directly on production servers. Really? Yep. I'm quite shocked. Anyways, DevOps is this new culture where you don't need dedicated people handling servers. You, as a programmer, be the back-end guy or a front-end guy, you take responsibility of taking your own code to production. And every single person is involved. It's also not about the way we used to do things before by, oh, there we go. The way we used to do things before was we did everything quite manually. The web master's jobs were quite manual. DevOps is all about automating as much as possible, not just deployments, testing, code quality. Pretty much anything that involves not just writing code, you can automate it. Just try automating as much as possible. That's what DevOps is about. It's development operations. Why should you care? Well, you should care because you want to save time. We are all lazy programmers. And this is part of your daily job. You just sit there. You look at the servers like this doesn't work. Flip the table. Stop doing it live. To all of you who actually said that you do everything live on the servers, can you please start doing it? Because soon enough, you might become big enough and you might have 40 servers to deploy things on. Do you really want to do manually to all 40 places? Do you really want to do that? This is the keyword for today. Automate, automate, automate. Automate as much as you can. You are programmers. You are capable of automating more than you think you are. You are capable of building your own IDs. That's what you are capable of, accepted. Why do we need this? I mean, we've had these websites for ages and people never had to do any of this. We have the CMS as you just type and you have these fancy websites. You steal a template from some free template website and, yeah, you make money. Why do you really care? You can just borrow JavaScript snippets from all places on the internet and have fancy sliding menus and blinking clocks and things like those. Why do you need to worry about these things? Why do you need to care about deploying to server? Because you're not building those fancy pages with blinking icons on it anymore. You're building real apps. You're building apps for, let's say, Firefox OS. We're building an app that has to compete with a native app. It has to compete with a desktop app. It is an app that is as good as any other platform. You're no more building websites and when you build something that complicated, a lot of engineering kicks in and then the engineering kicks in. Things get messy if you don't automate. So, as I said, OpenWeb is a platform which is probably as capable as any other platforms you know of. You can see some really great, amazing apps written in HTML. How many of you know Facebook? Facebook? Never heard of it? Okay. How many of you know EXTJS or Centra? So, did you guys hear about how they did this mock of Facebook showing how when Mark Zuckerberg said that HTML5 is not ready for production, he was wrong. How many of you saw the Facebook app source code where they had 40 JavaScript tags and 70 style tags and they loaded everything and took ages to load. It wasn't HTML's fault that Facebook was, the old Facebook app was slow on different platform. It was a fact that they just didn't know how to build this thing and you can't blame them for it because this is such a new thing. We haven't been building web apps of this quality for a very long time. We've been doing this only for the last couple of years and not all of us are experienced enough for these things. I mean, the team I work with, so we have five people. One guy is a drummer who became a CSS programmer. One guy is a rapper who became a JavaScript programmer. One guy is a master in music who plays like a gazillion instruments and he became a JavaScript programmer and me, only guy who has any background in programming. So that's the kind of people who are getting involved today and they're building really good things but the problem is none of us have experience building this really complicated apps. So that's why we need to understand how to do it better. We need to share our experiences with each other to make this even better over time. How many of you use the internet back in the 90s? How many use the old Yahoo mail when there was no Ajax? Do you remember the era of web pages before Ajax? So you know the distinction when you use Gmail today versus what you used back. You can see this slide. This probably wasn't possible back in the day. Something so amazing just wasn't possible back in the day. The web has evolved but our development methodologies haven't. The way we take things production haven't. You're still thinking that we're deploying these web pages and we just assume yeah, we can just go on like this for years but that's not true. We're coming across these problems that a lot of people haven't come before and we're coming up with these really ad hoc solutions thinking that they will scale on long term but that's also not true. We need to come together as a community and find solutions that will work for all of us and in a best interest. Also we need to stop having the webmasters. We all of us have to become the people responsible for taking our code from our text editor to our development server to production. Everyone has to be responsible at least everyone has to understand how it works. So first requirement, which is not part of deployment but is really important when you're building such complicated apps and you're collaborating with a thousand people maybe. Write code that you would wanna read. Write code that, I'm not just talking about camel case versus whatever case you wanna use. I'm talking about code that makes sense. Code that's readable. Code that's broken down into legible parts. Code that's valid. Code that has specs against it. Limit your code. JS int your code as much as you can. Do you know that in JS int you can add such amazing options to improve your code quality. You can add a option to set a maximum complexity of a code or function. And you can say my function can never be more complex than let's say, a systematic complexity of five and JS int will force you to write smaller functions. When functions are smaller, you can read better. Do you guys remember writing programs that were thousands of lines in code and there was just one big void main? You do, right? Interact with me please. I beg. Yes, so you remember. So and I'm sure a lot of you have worked at a lot of places, a lot of companies and you had to touch legacy code and when you did, the first thing you said was who the hell wrote that code? Why are there no comments? Why do I not understand what's happening here? We need to understand that JavaScript, though amazing language has its words and it gets really ugly really soon if you don't manage it from the right start. So do these things. JS int your code, write comments, write specs and use a CI tool. Use something like Travis CI, use Jenkins, use Hudson. There are a thousand options available. Use something to make sure that every time you add something to your app the specs always pass. It's your responsibility to keep this code clean, not just write it clean. Be a jerk. If someone writes shitty code, tell them to go to hell. Tell them to come back when they can fix it. Don't say yes. This is one of the amazing things about being Indian. We just say yes to everything. Do you know where this road is? Yes, go straight all the way. You're in China, but yeah, it's there. Go straight all the way. Stop doing that. If you think something is not acceptable, say a big no. Tell them why. Be honest about it. Be frank about it. You don't have to accept crappy code. The moment you start accepting crappy code, your specs break. Once that happens, there's no coming back. Because once a specs break, everyone writes codes. That will probably break more specs, but no one cares because it's already breaking. Who cares? So again, automate, automate, automate. You don't have to do it manually. You don't have to read through the code and say this is bad JavaScript. You can automate all of this. You can use GitHub. Let me show you a small fancy demo, which is not rather fancy, but the hell are you, terminal? Okay. Mouse, mouse, mouse. I have a file, which is, ah, come back. You don't have to see the code and understand it. You just have to understand that I can just, let's say, mess up this bracket. Okay? I just messed it up. And you know what? I'm a douchebag. I don't care. I want my teammates to suffer, so I did it. The moment I have to come at this, a pre-commit hook says, you know what? Go to hell, man. You can't, you're not even allowed to come at this. Crappy, fix it. It will not even let the code go into the repo. Forget about merging into a central place. You just, you're not allowed to write. Enforce a culture like this, where you're just not even allowed to write Crappy code. It's pretty easy to start accepting bad code. And once you start doing that, there isn't a going back. Google for JSHint, gitprehook, and you'll find a million gitreppers doing it. So this is something I think a lot of you would be familiar with. When I mean a lot, a really a lot. You probably do minify, concatenate, build all your JavaScript together. And you've been doing it for more than a few years. You understand the purposes of it, right? Well, no, you're not doing it manually. You're using some build tools and you can build your own build tool if you want. The point is you know the purpose of it. You know you need to reduce it to your request. Let's take it to the next level. This has been great for the last couple of years, but let's improve it a lot. You know what, let's pre-compile our templates and make them in such a way that you can include them in the build. So when you serve the JavaScript, that includes all your templates. Some people also go ahead and include their style sheets at strengths. And the benefits it gives you is you can rewrite the style before you inject into DOM. You can use things like scope CSS if you want to use, or you can rewrite the image URLs because you might have uploaded the images to CDN. You can package language data, the JSON data containing key value pairs. What, if you want to localize your app, which I'm guessing a lot of people don't know, don't do, but you should localize your app and when you do, you can package that as well. You can even package SVG into your app. You can package everything into this one big JavaScript file, which in one of these cases is about 300 KB, but you can probably make it much smaller. The benefit of doing that is you just make one HTTP request and the entire app is right there. And there are many options available. You can make all of these wrapped as AMD module user-required.js compiler. You can, of course, if you're a Google Closure fan, then you can write the entire app in Google Closure and use a Closure compiler and get all the benefits of all the optimization that Google Closure compiler does. If you are a big fan of the way we write code and node, the common JS patterns, then you can use Browserify to translate your code from common JS to something that the browser can understand. And there are like a million options. If you go look for build tools on NPM or any of these keywords, minification, compilation, you'll find over a thousand modules and you can just pick the one you like and everyone's taste is different and there is an option available for everyone's taste. So, since you have done all of this, we have created this humongous JavaScript file. We have these images and we just wanna put it on a server which is good because you just have one server. So what you do is just create a zip file, upload it to the servers and then you say, yeah, just unzip it there and yeah, it's live. But then you realize that you have suddenly a spike of users and you have 10 million users and you want to serve them equally well. Only a option right now is you add more servers. But when you do that, every time you have to push an update, you put that zip file on every damn server and then you unzip it on every damn server. Or of course if you're using SFTP or SCP, you're doing the same thing exactly. You're uploading on every single server of very tiring job. We are lazy people. We should be automating this. We shouldn't be wasting our time. So, no, stop doing this, please. Have I said this already? Okay. This is a very quiet crowd. There are a million opinionated options of how you can do server deployments and there are a few things that I have tried. I have tried in the last one year. One of the things you can do is you can have this one master server you upload code the way you used to before and all the other new servers just rsync the changes to that machine. So, you always have all the machines sync between one single machine. The problem is that that machine fails. If it goes down, you have to go around and configure all of them to rsync from another machine and then you have to set up this alternate master. So, it's not very decentralized. It can be a little painful. You can use Twitter's murder. It's an amazing way of deploying things. What they do is they deploy to one server which acts as a seed for BitTorrent and then all other act as seed and leeches and they all get and upload the data across all the servers and within minutes, you have everything replicated across. I think it's a really beautiful idea but for something as simple as deploying web app which is still quite simple as compared to deploying a database service is an overkill. You can do something much simpler. You can deploy a code to a S3 bucket or a CDN and you can probably just send a trigger to all your servers to clone it. And if you're an EC2, this is super fast because they're always in the same availability zone. Or you can use something as complicated as building immutable infrastructure. This is a really great talk by a chat follower about how you can create immutable and repeatable infrastructure. What you can do is you create this master image of the way you want the server to be and you keep it as a backup and every time you have to launch a server, you use this image to launch new servers and you destroy the old servers. You don't update your servers ever. Your servers are immutable. You just launch them with the image and when you don't need them, you destroy and bring new ones. You don't have enough load. You come down to three servers, two servers, one server, suddenly get a spike at 20 more. So you can scale up and down very well if you have a way of creating a immutable system. There are a couple of really good ways. You should all at least look at Docker. It's an amazing container platform where you can have multiple servers running on a single server. It's kind of like virtualization but without virtualization, so it's really fast and when you need to destroy a container, you can just destroy a container, add a new one without rebooting the entire machine. So it's really quick. Have a look at it. How many of you have had bad experience with caching? Like you cache something and then like nothing works anymore? So I'm guessing a few. Caching is not, oh, where did the two come from? Anyways, I think I know where it come from. Anyways, this is what most of us did. We edited code, we deployed, we did a control, I find it's like, it works for me, I'm going home, I'm getting a beer, and then next morning you just find people complaining on Twitter saying nothing works. And maybe you want to think about why that happens and the reason that's happening is because you think that browsers don't cache or you think that browsers cache too much, you always estimate caching to be this very simple mechanism where it is not. There are proxy servers involved, there are different user preferences of caching involved. What you can do is you can bust that caching completely and you can use alternate ways of not caching. So one of the ways I think a lot of people did was they added a question mark, q equal to or version equal to five, six. How many of you ever did that? Append a random query parameter. So you know every time you had to deploy you had to add this number, right? Yeah, why not automate that as well? Be lazy, automate this. But why automate it based on the deployment version? Why not just use a Shah hash of the file or a MD5 hash of the file? So if the file changes only then the cache is invalidated. So the users don't download a new file every time you deploy, they only download the file when it changes. Use prefetching, load really less amount of code and render as fast as possible. And the rest of the code, use prefetching. Look for link prefetching on MDN and you'll find a lot of good documentation on how to do it. It's really simple. It's a one line HTML thing. Prefetch all your assets once you have the app loaded so when the user starts logging in you log the main app or something like that. This is something that I've been doing lately at Wunderlist. What you can do is you can buy like a million mechanism. You can make the clients understand the fact that they have old code and when they do you can use the page visibility API, which is a great API. So just reload the app whenever the user's not using the app. So you deploy a critical bug and the user's still using a buggy app. So use a mechanism like this. I'm probably gonna be open sourcing this in a month's time maybe. It's in the technical debt list. When I do, I'll tweet about it. So follow me. Okay. Track performance. A lot of you probably profile your app and the profiling tools have gone amazing but when you profile you only test the parts of the app that you're familiar with. What you don't test is the fact that you could have a lot of places in your code that you're never touching. What you can do is you can automate the way you collect performance data and you can send it to a central server and then you can analyze it afterwards. So there are really amazing performance APIs. Look for performance API on MDN. You have memory usage, how much the heap is being used. You have the page load timings, how much time it took, the page to load, what all components could be broken down into. You can see. So there is the API to measure the extra timings but XHR itself support events like XHR started or it's loading or it's loaded and using these you can break down the timings each of these events took and you can see what was the DNS resolution time, what was the time where the API was probably generating the data for you and what was the time that the client took to download the actual data. You can use these things to optimize your backend code as well to make it performant and track these things. And if you could then you also track user events. You can see if a user's clicking on certain thing and the heap usage is shooting up then you know that there's a memory leak. It could be a memory leak that you might have missed out but if you track these things you can actually fix memory leaks that the user's finding and not you. Track errors, use window.onerror. You window.onerror just got a fifth parameter that gives you the actual error object. You can get the stack of the error. You can get what's going wrong in your app on a user who's sitting in China. Use tri-catch. People say that tri-catch makes things slow. It makes things slow only when you are using tri-catch with a huge block of code inside it but if you tri-catch just a function call it doesn't make a difference. There's a JS perf to prove me. You can just go there and check yourself. I'll share the slides after that. You can have a look. And of course a huge shout to Rakesh's Airception. One of our fellow geeks here has a really nice platform for tracking all these errors called Airception. You guys should have a look at it if you really want to track your errors. Experiment, share, collaborate, create these new tools, share with each other because these things are so new that none of us are experts at it. The only way we can become experts at it in a shorter term is by sharing with each other. Do you have time for a small demo or should we queue it? Okay, we'll do a queue. Sorry I can't demo it. It wasn't really that great anyways. So you talked about flushing a user system remotely with the new code. Can you talk a little more about it? What are the ways? What are the softwares? We can... You don't need any complicated software. So you only need to notify the clients somehow. If you're using a very complicated app where you have servers involved, you can probably create a push mechanism. You can have a web socket server or socket ISO which could do that for you. Or if you're in a very simple system, you can just have a get hash file on the server, a static file with probably eight characters in it. And the clients can probably poll it once in a few hours which is not very expensive if you're doing it in a few hours. And when they poll for it, they'd see that the file has changed. And when they do that, they could just wait till the user's gone either away or it's on the next app with the page visibility API and you can just reload the app. You just do a location dot reload. Okay. It's pretty simple. It's not that complicated. Okay, thank you. Hello, yeah, hi. Nice talk. My question is about Wunderlist. You mentioned Facebook not doing the app, the proper HTML way and that's why they decided to go with native applications. So did Wunderlist? So I'm just wondering why Wunderlist had an HTML app then they moved to... So one of the things that happened with Wunderlist was that it was written by designers and non-web programmers initially, the Wunderlist one. And they wrapped it around titanium and a couple of other platforms to release it all as many platforms as possible. And it didn't work because they made the same mistakes or even worse mistakes than Facebook did. The web team, the people who are like me who got involved was much later stage and the pitch to the market was that you bring native apps and the users didn't care if you brought highly performed web apps. The users wanted native, the investors wanted native apps. So finally we made native app but when we built the web app, we built it in such a way that you could actually packages for any of the open web platforms, not just the browser. So it works on the Chrome package apps. It works amazingly well on Firefox OS. It works on... I've actually tested it on Ubuntu form on the browser. It works across everywhere and it's highly performant. So looking back now in the future, what do you think like an HTML... Oh no, sorry. Looking back in the future, would you think that an HTML app for Wunderlist would work? If you're a small team, I can't speak for the entire... If you're a small team, a small startup with not enough resources, HTML definitely will save you time and money. You can just be a bunch of guys building for all your platforms. You don't have to hire 50 people to build all native apps. Unless you really, really want to do that. It's also a cultural thing. Some people want to build native apps. Some people care about having native experience, consistent experience. You can't do that so much with the web because you're trying to build for the web. You can't really make a web app look like Android and iOS and Ubuntu and all the damn platforms out there. You'll make it for the web. So there's this thin line between where you should go. But definitely HTML5 is ready for these things. You did talk about the caching. So the client-side caching. So we can't use the STDP cache headers to... When you use the STDP cache headers and let's say you say it expires in a month, but you had to push bug fix overnight and now it still has 30 days left or 29 days left, what do you do? You can't force a caching validation on the client. The cache is just there and some browsers will just use the cache. What you can do is change the URL to something that user might have never downloaded and then the user gets a new file. So the new file is cached again. So when they open the app again, it's served from the cache. You have all the benefits of the cache, but only when you change the code, a new set of files are downloaded. We have time for one more question. I would just like to add to that. This is not a very new thing. A Rails asset pipeline does it. Yeoman build does it. And many other build tools do it. I wasn't trying to sell you a solution that I built for doing show and off your file while you upload it. I was just trying to sell you the idea that do that, automate it so that you don't have to ever deal with caching. As you said, do change the URL but there are different browser behavior. If you see the iOS, the iOS, if the post request is there and you see the URL is changing, you add certain parameters to the URL and if your data can- If you're adding parameters to the URL, it's actually in the URL itself. So show on shashfile.js. Hash something or Koshamax something. No hash, no question mark. No query parameters, no hashes. Hashes don't go to the server side. So you mean to say that, change the entire URL? Entire URL itself. Any more questions? All right, everybody, give it up for Aditya, aka Netroy. Thank you so much. Take back our love to Berlin. Thanks everyone for being so amazing.