 So, hi guys, my talk is all about going to be all around JavaScript, so how you guys use JavaScript on mobile platforms. So, let's look up to JavaScript, so you guys might be familiar with the word look up, right? You guys are been looking up, I have been looking up your Twitter tweets, so some might be seeing the fan above the ceiling and all. So it's basically an ideology of the firm, so I can't help with that, all right? So you can see some code stuff I have written, some scribbled one. So let's move forward with introduction, hi, I'm Dhruan Rathod. I work at Moorches and front end automation lead at housing.com. So, just being like there are two kinds of JavaScript developers. One are the Nazi JavaScript developers and the second one are the follower ones. So the Nazi ones develop all those frameworks and all, followers just follow them. So I just love to be at the Nazi part of it, because that is the way you get the good reach as what, how JavaScript actually works. So you have to clean up things, you got to create new stuff rather than just attaching the previous created one and just keep coding up. So my introduction itself shouldn't be in English, it should be in JavaScript, right? So yeah, if you can decrypt this one, it's great, you can apply at housing, all right? So this completely makes what I was saying about myself. And my task at housing.com is to pursue everyone to use JavaScript. I go to back end and I will say those guys will be having some problems at and they will say we want to do this, this, this thing. So let's do it in Node.js, like I'm Node.js, I should get projects into the Node.js. So I will say them, okay, you guys are doing it in a synchronous way. Let's do it into an asynchronous way, it would be faster. And they will be like Ruby is like Rails is quite good, we have a scaffold, we can do things very easily. Just a command and everything will be created. So my task is that and I love reading JavaScript, not the JavaScript that we read, but under the hood, how the compiler works, how it gets interpreted, how browser is attached to it. So all kind of geeky stuff all around. So I'll be discussing that part as this talk was more aligned towards JS foo. So I removed a lot of geeky parts. I left that with abstracts. So hope you guys like it. Let me, okay, these are my social handlers. If you want to tweet some questions after around the conference, you can, okay? I guess, okay, if one of the great anonymous speaker once said, if you don't start respecting the web, it's going to be doomed. And, okay, that are my initials down there. Okay, so I once said that. Let's move to mobile. So from mobile, what I think is it is a small device with less memory. You have very less memory. You have very less CPU. Like you have very less CPU cycles to do things. Like JavaScript is an abstract part. At application layer where you see that, okay, if I type console.log, blah. It's going to be console.log. But you never think about beneath the layer what is happening. If your code can totally make your app suck. So that are the points that you need to focus. So I am going to discuss those parts today. And less interaction area. Like this is the small screen at which you work. Plus all these guys are doing is every year, they are adding more pixel string like DPIs every year. So it's a trouble for front end mobile developers. Mobile web app developers that you don't see, but it is there. Like, yeah, you have to convert your images to a better resolution. So on mobile, what we guys do is previously we just scale it down and then just put it. So now we have to keep up the resolution of the images, right? On the mobile, on the devices. And sensors and web API, more events, like touch events you have. And web sensors, like web APIs are there for your navigation sensors and everything. So all these stuff clubbing together on the mobile web, it is a good thing, right? But there are consequences, like India is a growing country, right? Here no one won't, everyone dreams to buy an iPhone, but not everyone has an iPhone. We work out at a low edge devices, which works on like, recently I was previously here with Mozilla. So we promoted Firefox OS here, right? So Firefox OS devices are very low end devices. They don't work on much memory. They have 256 MB of RAM and very less RAM, very less CPU. So you don't have much of the CPU cycles to perform things. So if you're going to use that jQuery and everything big, big libraries on the mobile, your app is never going to work on Firefox devices or the similar kind of devices. But what I think is major problem, mobile web should be compact, right? It shouldn't be like whatever you have on the desktop, you just copy paste the whole code, you just add CSS media queries, just shrink it, make it look like there's, okay, this is going to work on mobile. So this is not the way you code your apps. You should be thinking a lot. You should meet with peoples who know things about mobile web. So the good news about from housing, coming from housing is we have moved to mobile first. Now, our first priority is going to be mobile. As you can see, we have changing things like moving user to the app if you come to mobile websites. And we pretty much reform our mobile web. We have changed many things, cleaned our JS codes that were ugly. So we're going to discuss all about that. So let's move. So browser design is basically UI is what you see, the front end, the mobile screen you are seeing at the web. That is UI. Next comes a channel. So basically, let me just put up all of these points. And there you see, there is your JavaScript. So your JavaScript is not going to actually react on the same moment things going to happen on the front end. So basically, your events or everything, your DOM changes, these flow like, sorry, my bad. I shouldn't have done animations. So UI is basically what you see. So that is another library that browsers use for painting your screens. And then they have a channel in between which connects to the actual browser engine. JavaScript is not in C++. It gets interpreted and it gets executed in a different environment. So you're not going to actually hooking that thing directly to your DOM or whatever which is beneath. So above that is JS. So your JS traverse this path to actually make things happen on the UI. We, as front end developers or mobile web developers, we don't think of this perspective. We just code. Who cares about these things? Some of my friends said, who cares about having an O1 complexity of accessing something or an ON of complexity? But it does make sense when you want to create an app that makes sense to the web audience. You're not going to flood the market with shitty apps that doesn't work. They sucks a lot. You add a JavaScript jQuery library. Then you have jQuery mobile. Then you have jQuery scroll. Then you have jQuery carousel. And jQuery x, jQuery y, jQuery z. Then you have a backbone. You have Angular. Why all these masks you have to create on mobile? Just keep it simple. You need not to put all those things on to the mobile. It is not made for that purpose. Let's move to actually JavaScript flow works. Whatever you write, how does it actually work? So it obviously compiles. So everyone says it is an interpreter based language. But still, interpreter has to compile, generate the graphs and trees and everything. After compiling, it tags them. Like binary opcodes is basically this clause. How does interpreter is going to understand that? So compiler, what it will do is it will just tag that place, like add a operant there. This is a if clause. It starts and it ends here. Next is interpret. Interpret the code, run through here, whatever you have written. Then execute it previously. Initialize a stack and context variable. That is the most important thing. So it's basically whatever the environment. In JavaScript, every function works in a different way. It's an object. It's a new object whenever you execute a function. So it has to be initialized with its own environment, stack, whatever, x, y, z. You don't have to worry about that. We will come to that later. So how can you optimize your JavaScript on mobile? I'm very much concerned about people using JavaScript very badly on mobile web. So that is the main purpose of my talk here. Why are we not using JavaScript the way it is meant to be? Why are we hooking things up that doesn't make sense on mobile web? So these are places where you can optimize your JavaScript. You can initialize, add the initialize, execution, compile point. Even monkeys know that. Prototypes can help you in building better JavaScript. So we can learn from them why you use JavaScript on mobile. Templating, we all do templating. We create Angular apps, and we do templating. We use React and stuff like that. So next is animations, events, XHR, and to show that you are a rock star. So we code whatever we feel like. It's just sitting there and just coding things. So it doesn't make sense when you can actually optimize things, but you're not doing that. So we might end up someday that with the holding, walking all around the street that I can code JavaScript. Just give me some money. So let's start with templating. Templating is basically you have a DOM string. You want to construct a DOM string, like a whole HTML part, with whatever data you have from your model, and you want to print it that on the front end, on the mobile web. So there were many ways of doing it. And previously at housing, what we were doing is we were using Hamel C. So this is what our template looks like. It is like a crap of JS return. It's an Hamel C template. So it gets required on the front end. What we do is previously what we used to do is call the API, and let's have the look. Previously, send API request, then JSON parsed the data. So if you have gone to housing.com, we have so many properties to list. So every property has so many fields, like rent, date added, x, y, z. So those are big chunks of JSON data. So on a list of 10 of pagination, like we were not doing pagination previously, but then later on we understand things and we moved on. So previously what we were doing is just calling the API, getting that 60 or 50 of results, and then we were just sending it to the template. JSON parsed that data, pass it to the template, get the DOM string, and attach it to the DOM. So what do you guys think? Is this process makes sense on the mobile? It does on desktop. Does it make sense on mobile? Why do you have to JSON parse the data on the mobile? That big amount of JSON doc you are parsing. Like Douglass Crockford written that thing doesn't mean that on everywhere you are going to use it. So pass it to the template. You saw the template previously, right? That big JS page. So that is basically a string concatenation, ifs, block, x, y, z. So that is creating a string concatenating string and making a big huge DOM string out of that. And then the last part is attach it to the DOM. Then later on, we figured out that this part isn't required. This is not the way of doing things on mobile, right? So we thought let's not make the user pay for it. Let's make it easier for the user to access our web app. So what we did is we just pass a flag to our API saying rendered through. So that is like our API is going to pick that JSON data, parse it, pass it to the Hamilton template, compile the whole DOM string, pass it back to the front end. So basically, it's like removing all those parts. You just have the HTML given back by the API itself. So you just have to do attaching it to it. So this is the output of the API now. Previously, it was like a JSON doc. So with the flag, we fixed that. Let's talk about events. Events are heavy if you haven't like deal with them a lot. How many of you have built canvas-based games on mobile? You guys might be facing trouble with events like too many events firing up. And then you have to manage. You have to fire all those callbacks onto it, right? So you have to make it very soft and very compact of the JS part so that it doesn't lag on, like canvas printing and everything doesn't lag. So what makes events heavy? Have you ever thought of it? Like why events are heavy that much? We previously saw that JS doesn't work on the lower end. There are channels through which data passes. So whatever event happens, that happens on the front end, on right on your canvas, not on the JavaScript. JavaScript gets to know that event after a while when a browser tells him, OK, this is the object. These are the nodes. This is the event. Just fire it. So this is how event propagation works. Everyone knows this. Does. Let me explain. Events work in three phases. The first one is the capture phase. So capture phase, basically, the actual event has happened from the top to the bottom. This is basically the flow of event. Event flows from the top to the node at which the event actually happened. So this is one. Second is target phase. Like you will get the event, not before that. After that, whatever you have to do in bubbling phase. So I gave a thought of it, like why should I be worried about so many things? Like it goes to capture, target phase, bubbling phase. I'm going to have this event at the target phase itself, right? Not before that. So how can I fix this thing? It was a weird thing for me to see. Like why? Why I have to do these things? Like why browser is made this way? But there are reasons. Those are smart guys who build it. I'm no one to judge them out. So how does actually events occur? Let me give you a brief. So the front end is basically a canvas. It's not like an HTML tag what you have written. It has been converted. So iskia skia is a library that every browser uses for printing front end. So basically it is a C++-based library which prints those 2D models, 2D boxes on the front end of your browser. So it is on Android also available. So they are ported that too. Now your event has occurred on the canvas, not on the JS. So it has to somehow propagate to the JS part, right? So in between, there comes a channel. So that is the DOM channel, like the canvas to the browser engine channel. What it does is it waits. It listens to whatever canvas is sending back. So whenever we have an event on the canvas, browser listens to it and then pass it back upwards. Then there is one result target. So you guys saw that chart of capturing face, right? So all those are the nodes. So those nodes has to be resolved. Like DOM doesn't knows where the event occurs. It has to somehow figure it out, OK, this is the DOM tree which has been actually had the event occurred on it. So in between, init of event property, these are the C++ functions if you go deeper into the browser's code. So these are the actual function that does occur beneath the hood, which we don't know. And then bailout handlers. Bailout is a concept that I will discuss later on. I'm not going into that. And the last is your handler, because this is how event acts. We guys think that the event is like directly propagating from front end to the JavaScript. So differentiating front end with JavaScript, it is a model on the front end itself of a back end. I guess it has some problem. So let's discuss about it. The faces. All right, sure, sure. Hello, hello. OK, so what we actually see is the JavaScript code that we execute. We don't understand the beneath layer. So I'm here to enlighten a little bit about that. What is beneath happening? So this is what actually happens when your touch event is fired, when your click event is fired, when your drag event is fired. Or all those events are happening on that small scale of device. So every event has a thread running, an observer running behind. So we are basically firing those threads up. So more the events are there, more all those traversals are there, the more memory it is going to eat up on the mobile. So do we have a problem right here? Do you guys think there is a problem in this flow? I once thought that this is a problem. So I went away with a solution. Like events has to do complete cycle. It has to go from capture phase, then to the target phase, then it goes back to the bubbling phase. So you guys might be doing event dot stop propagation. That's it, on the target itself. But still you are doing on the target. You still have the capture phase coming down. So too many events slow down things. If you have a game on the canvas and you are firing too many events, so that is going to cause mass. If you are going to fire too many things and you are creating objects into that function, you are doing some cool JavaScript stuff into that. It's not going to work for your web app. Trust me, it's not. So why I have to wait for an event to reach my target? Can I do it before? So do not let it bubble. First thought, capture it at the first place. So if I can somehow have my event listener on the window or the body itself and listen to all those events occurring, like what all event handlers I have beneath the body. So top hierarchy event handling and stop the propagation right at the body itself in the capture phase. So we all know the flag. So this is how an event object looks like. Doesn't it looks like so bad to it? Like this event object is sent to every node in the capture phase and then to the target phase, then to the bubbling phase. So it's not going to work, right? This is a big memory thing. Like, so what I thought is let me attach the events at the capture phase. I want to attach an event handler at the capture phase and I want to capture those events right at that moment. I don't want these mess to happen all around. So there we have the capture flag true. Document dot body dot add event listeners or attach event on the IE. So you set the attach capture true. Now, this is the path. This is the whole tree path you will get at the right moment when the event occurs, like when it was going down to the target at the body itself, you will get this. And there is your source element, like at which source this event actually occurred. So you got everything right here, right? Why do we want this to propagate down to the line there? So this is a workaround. Like I'm not saying this is the best idea, but it can help you, some of you guys in developing apps. So you guys might be thinking like, I can have inline events, React.js does it, right? Inline event on XYZ or you can write in HTML also, right? On click div into it, you write on click equals to this. So we read that it has the highest priority, right? The inline event handlers have highest priority, but let me correct you. Capture event listeners have the highest priority. No one will call that inline event handler. And why inline event handlers are mess? Look at this code. This is the source code snippet from the Firefox browser itself. And they clearly mentioned into the comment of their code that mtarget later and compile lazily. It's like you have written that on click of this JavaScript run XYZ function. So what it does it keeps that whatever the function name is and it will compile it lazily like, okay, fine. I don't care. I will compile it later when the upper layer gets it. So it is very, very slow. Trust me. It is slower than document like element dot on event handlers. It is slower than that because you have to pick that particular string then you have to look up into whole of your JavaScript. The engine does. You don't have to do it. But engine has to do all these things. So it's like, why? Why I had to do this? Like on click are very bad. Inside the DOM, you never have to do this. So I made a small library at github.com event man. So no racism or feminism or whatever. It's just a name, okay. And what I did is listen on the, sorry, I hate keys. Listen on the body tag. I'm listening all the event on the body tag. Now you might, you guys might be wondering like how I'm going to fire those events. Like how I'm going to know that this element at which the event occurred. How I'm going to know that, okay, this is the handler I have to fire. So it works in the similar way the jQuery works. Like you have dollar dot whatever on event or dollar element dot click on click and whatever event handler. So the same way it works. You just tell him, this is the node attach this listener to it. So basically what it does is assign unique ID to each node. Whatever node document node you gives him, he just assign a unique ID to it. And then it saves it into a map. So that later on when we call, we have like a faster execution of all those callbacks. And access the ID and lookup into map, execute the event listener and just stop the propagation. We don't want bubbling to happen. This is a workaround. I'm not saying that this is the best way. So you can actually increase the throughput of your events and how much you can improve is here. So it's a lot, right? This is the sample of thousand events. And jQuery 1.7 took 300 milliseconds to fire all those thousand events. And jQuery 2.1 did a little better. And event man, 33 milliseconds. I was stunned by seeing it, how can it be possible? And then I checked on every browser, every version, it was constant. It was 33 milliseconds, that's it. So that was a huge success for me. Okay, what is wrong in event man? Like till now I haven't coded, like added few more functionalities to it. The first one is I have to write my bubbling phase thing, right? I have to keep on, like these are the nodes that want to listen to the event in the bubble phase. And the next goes, event delegation is hard for me to do. Like jQuery still does in a dirty way. No one has done it like a perfect way. Like when at the runtime you change the DOM, you add few more nodes and you want to attach the event listener to it. So jQuery provide a delegation way, right? Through delegation, you can call those events. Anyone heard of delegation? Like jQuery.delegate, dollar.delegate, okay, few does. So you guys can check out. The use case of delegate is, let's say I have a list, okay? And you are making a XHR call at the back end. You are getting some data and you are just adding that up, okay? So to attach event listener on that, you can use jQuery delegate. So I don't have delegation onto it. Maintaining the sequence is another mess I have to clean up. You guys are welcome to code into it, contribute to that repository so we can make a better event listener library. Let's talk about JS performance. Like where can, like many times developers say is like JIO JavaScript, why doesn't work? Like it's mess creating things in JavaScript. But it's not because we are doing it the wrong way. We're doing it things in the wrong way. Let's have like dot call versus dot apply. Everyone knows dot call is faster, right? How many of know that call is faster than apply? Anyone? Okay, few does. All right, so actually dot call and apply are like calling some function you can call with arguments. So these are the two function, function D and E. So I can call with D dot call and I have to pass all those arguments. In the apply, I have to pass the array of all these arguments. So why call is faster than apply? So I go, I got into deeper into the JavaScript library like V8 engine and all those iron monkey engine and I got this snippet out of it. Like whenever you write D dot call, it's like it converted into an inline thing and it just passes that. You see those three dots written there? Have anyone coded in C language? Right, we all did. So in C, when we have to pass variable number of argument, what we use is like dot, dot, dot, three dots, right? So this is the same code that actually occurs in the JavaScript beneath when you call dot call. So next is let's have a look at this code. Do you think this code is okay? Like let's have a look at the above layer. Does it looks good? Right, it does, but there is a problem. This is an out of scope access. So whenever you access something out of the scope, the JavaScript engine has to bail out from there, go to another, create another stack, push it those things, whatever you are accessing onto it and then execute things. So that is the bad idea of doing things. Another is calling some function, that add some property. Again, this is not going to pay you a lot. What could be a solution is to these things is localizing variables. You need to localize things. Like do it into the this context itself. If you do things in this context, this keyword, everyone knows this, right? So if you do things in this keyword, it doesn't have to bail out, it doesn't have too many things to mess up around. It just execute very fastly. Let's move to another. This is an array in everything. You can read the array values if you want, okay? So accessing keys is optimized. Like accessing these key values or an object are optimized, it takes over complexity to access these things. Maybe this is a bad idea of changing something that is global into a local context. So you are in into some function, into some function, into some function and from there you're changing something that is above the layer. That is a bad idea because it changes the whole path of JavaScript to compile back things. So might be doing it into the global context will solve things. Return should be as the first statement. It optimizes things like the same stack can be used by all other functions. Like the same stack, whatever you're returning is passed to some other function, whatever you have. Ternary operators are fast, very fast. They are faster than if else clauses. If you see, this is the assembly code that looks like this. And I would rather promote you guys to, if you have one liners, then rather use ternary than if else, these are optimized beneath the layer. Don't block the code, please. Don't block it. Like if JavaScript is single threaded, if you block, do something stupid, like there's like traversing an array and all, this is not going to work, right? Your whole code will block away. And miscellaneous less timers, set interval and all those things, web workers. So set intervals are basically threads, basically get queued into the event. Queue, web workers make things faster. So if you want to do things very quickly into your app, like Canvas printing and everything, do it into web worker if you have something to compute. That will pay you for that. Document or fragment is a lie. Please don't rely on tweet. It is a lie. It's a big lie that has been coming back from these centuries. Never use document or fragment. It's not going to worth you. I will catch you guys later about this because I'm running out of the time, I guess. So maybe this, don't do animation on using JavaScript on mobile. I'm specifically talking about mobile. You're going to burn a lot of memory and a lot of heat will be generated out of your mobile because CPU has to do so many computation on your CSS. So why should you not do this? You see, Tanmay Bhatt, Khamba, Ashishakya, they all are like, they are, the event, the animation you are seeing, this is not going to worth you. Like you don't want to get roasted by these guys for not using the best animation way. Like you can do these things through CSS, right? This is not a good way of doing. Through JS, they are doing those things. It's messy, quite messy. So performance you can optimize by using all these points is around 200%, I can say. Because I have worked on to all those things. I have worked on using web workers, everything beneath, optimizing the JavaScript, converting, templating to the API response itself. So it all paid up a lot. And in housing, we are going to apply all those things. Like we have started and we are moving forward to implement all those things in next few months, I guess. And tips of the day, never mind to scroll events on mobile. Please don't do that. You can always use touch start and touch end. They are beautiful. They don't too much populate event queue. They just send you touch start and the end event, just two events. Lesson on the top most hierarchy, this is optional. I'm not saying that you should use this, but it might pay. Do not bind too many handlers onto events. This is heavy. Like if you have a thousand of listeners onto the same DOM node, then it's going to be lagging like a way too much. JavaScript is single threaded. Have some respect to the JavaScript. So yeah. Thank you guys. Questions? We'll have one question. Sorry, I can't. So you are saying that you'll explain something in the event propagation because it's an important concept. I cannot. Okay, event dot stop propagation. Basically what happened is event dot stop propagation cancels out all the faces. So the moment you call event dot stop propagation, it cancels out the whole path from coming where you were listening to the target, even the bubbling face. So if you capture things on the top most hierarchy on the body itself and you cancel the propagation, so browser will never ever interfere again into that event and that event will be like a stashed out. So event dot stop propagation is a better way if you don't want bubbling faces or all those faces to occur. Like let's say you have a DOM tree having 50 nodes and then onto the 50th node, an event is happening. Browser has to call all around the way to the 50th, then bubble it out all around the 50th. So if you stop the propagation, it cancels out all those faces to the 50th. Even like it will stop at the end edge where you will listen to the event. I guess you can catch him outside for your question. We are running out of time. Thank you very much.