 All right, so we are going to start our Flash Talks. How many of you have an understanding of what is Flash Talks? Raise your hands, please. That's it. All right, so each of the speakers are going to just get five minutes to talk about anything that they are passionate about, things that they have built. They want to share with this group. And we are out of, we got close to 10 or 15 submissions and we have selected five or six. So we are going to invite one of them, each of them one by one. They'll come here, just talk about something for five minutes, and you guys have to see what they are talking about. So the first one is Karan Thakkar. Hi guys, how are you doing? How was your day? Cool? It's going to be awesome now. All right, so I'm Karan Thakkar. I work at Crowdfire as a front-end dev. And I'm here to tell you how we decided and why we decided to move to Ember from AngularJS. So before I start, how many of you use AngularJS for production? Quite a lot. And how many of you use EmberJS? Oh, quite a few. Yes, cool. How many of you know EmberJS? Have heard of EmberJS? Great, great, great. So to give a quick background, back in January, Crowdfire started rebranding to, we started rebranding, and we wanted to revamp our website. The legacy code was in Backbone, and we had to make a decision whether to go with Angular or any of the frameworks. Most of us were comfortable in AngularJS, so we started coding in it. After like 10 days or so, we had a team meeting, and we decided to lay out points, which is better. Is this the right way to go? And we decided to switch from Angular to Ember. And I'll tell you why we did that pretty fast. So if you have used AngularJS, you know that it's a non-opinionated framework. So there is no directory structure that is defined by the core team of Angular. So most of the AngularJS projects that you see, each would have a different directory structure. So if there is a new team member that is coming to the team, joining the team, let's say he knows AngularJS and has worked on AngularJS before, it would still take him time to understand the structure, how the production build is made, the grant file, and all that stuff. But with Ember, that is not the case. I'll tell you why. Also, in AngularJS, in our application, we had to render a lot of list views. So we had a long list of 1,000, 5,000 items. And with AngularJS, because it uses dirty checking, it was after 2,000 bindings or so, it became slow. The actions and the clicks that it took a lot of time to execute. So that was one of the reasons. Also, the most important thing was the Angular 2.0 version was coming out by end of 2015 or something. And we were rewriting in January. We didn't want to rewrite again in a year or so. And so that was one of the reasons that we moved to Ember. Also, if most of you are into test-driven development, setting up your test infrastructure with Angular takes a lot of time. You have to figure things out for yourself. If you want to deploy to production, you have to write your own grant file and all that stuff. So a lot of things went into consideration. And that's why we chose Ember over Angular. And now I'll try to list out why Ember is a little superior over AngularJS in some aspects. So the biggest advantage is, Ember, if you have reused Ruby on Rails, so Ember moves along the same line. So there's a lot of convention over configuration. So let me give you an example. Let's say there is a PostsRoute. So in Angular, you would have to define a controller in your Angular Corouter. You'll have to tell this is a controller that would execute this route. This is the template that would be rendered for this route. Whereas in Ember, let's say you have a PostsRoute. It automatically assumes that the controller for that route would be in the controller's directory with the name Posts.js. Also, the template would be automatically resolved by looking into the directory called template slash post.hbs. It uses handlebars for templating. So there's a lot of convention involved. And you don't have to figure things out for yourself. The directory structure is already set for you. Also, if you are working on an Ember.js project, there's a command line tool called Ember.cli. It's like a full-fledged toolkit for building and deploying Ember.js projects. So you can use Ember.cli to generate your routes, generate your controllers, and you can use it to deploy over. All right. I didn't get to complete a lot of it. If you have any doubts about Ember.js, why you should use Ember.js, you can find me around. Thanks, Karan. I've come here to talk about HTTP2 and why the web needs it. So some of the best practices that we have followed over the years have actually become anti-patterns for HTTP2. And I'm going to show that why. So if you see over here, the last HTTP1, it's been 19 years since HTTP has been updated, and things have changed significantly over then. The web pages now have become more intensive than ever before, which means we are putting additional loads on the server as well as the client. And HTTP1 was not built to handle this kind of load. And also, HTTP does not use TCP optimally. So what that means is we are not able to take full advantage of the powers and processing of the TCP. So now what you've realized over the years is the requests are expensive. So developers have come with various workarounds. So one of them is Spriting. So in Spriting, what you do is basically merge all those small, small images into one large image. Then we started doing inlining. Inlining is instead of fetching separate files, fetching them separately, what you've done is embed one into the other. But this comes at a cost. Resources cannot be cached independently. Then we started conkineting all the small, small JavaScript files into one big file, which makes it more uglier. So every time you make one change, you have to download the entire file again. And this was actually an alliance for the developers. Then another workaround was domain sharding. This was one of the limitations of the browser, because browsers have this that they can use only six to eight connections per host. So then we started using alliance names to allow more connections. Here's one interesting chart I want to show you. The first one is just look at the top graph, the latency. If I move from one Mbps to five Mbps, you get a fairly significant wins. But if I move from five Mbps to six Mbps, I hardly get any percentage improvement. And what if I double my speed from five Mbps to 10 Mbps? I am hardly gaining anything. But look at the chart below it. This is about a latency. As you improve the latency, you are getting a linear moment of performance. So this is actually what the Google engineers try to attack. They try to identify from how we can decrease latency from the source. And that gave rise to the protocol which we call a speedy. So HTTP is nothing, but it's built on top of speedy. Here, we are using only one TCP connection, as against we open around 30 to 40 connections today. And it improves the speed. And as per the initial test that we have shown, it improves the speed around 30 to 40%. And what makes this faster is one of the examples over here. So what you see on top is HTTP one. You have the post, the header, along with the message into one component. But in HTTP two, these two are broken. What this means is you can send them independently to the client, as and when they are ready. And also, they can be interleaved. They don't need to be in sequence. This is one of the features of HTTP one. On the left-hand side is HTTP one, and this is HTTP two. HTTP one suffered from a major issue that is called a head-of-line blocking. If one request was taking a significant amount of time to respond, all the future requests, they were getting delayed. But this problem was solved in HTTP two. We need only one single TCP connection. And you can send in as many requests as you want. And as and when the responses are ready, the client sends it back to the server, sends it back to the client. Which means there's only one connection needed. The request can be out of order. They don't need to follow a particular order. And plus, they can be interleaved. So this was one of the major reasons why HTTP became fast. Another reason was header compression. So look at this example. Suppose you're making 100 different requests to the server. You are repeating this data. For example, user agent. So every time you're sending 100 different user agent which has the same value, that is Mozilla or something. Similarly for cookies. If the cookies don't change, we are sending the cookies again and again. So there's a lot of repetitive data over here. So what HPEC did is they not only compressed this data, then they came up with this very interesting concept over here. They formed a table. So say for example, user agent, they gave it an ID of 14 and another one cookie is 24. So this table is maintained both on the client side as well as the server side. So now what happens is if the browser knows that it's going to send the same user agent again, so instead of sending this full value of name and value, it is just going to send this ID. So you're saving a lot of space over there. Similarly for the next one, it's just going to send this ID 24. Third feature was server push. So say for example, the user request for HTML. What you get in return is not only the HTML, but also you get the CSS as well. This is similar to the inlining problem that we had request one thing. But you get its dependencies also. And the only problem is it's restricted to the single same origin resources. But this gave an opportunity for servers to become more smarter. The push was based on the traffic pattern. So what is the impact on the developers for HTTP2? HTTP2 does not modify any of the semantics. The semantics remain the same. The headers, the requests, the methods, everything's going to remain the same. The only thing that is going to change is the binary format. Instead of text, you're going to send data in the binary format, which means basically you will need time to debug applications. And one last thing is the workaround which you did in HTTP1 will be hurting in HTTP2. This is the last thing. Another thing was the 30 seconds, just 30 seconds. Can I use HTTP2 now? All the major browsers have shown support for HTTP2, including IEH. IEH has support. And you can see Chrome, Firefox, all have shown support to HTTP2. And these are the list of servers that have started showing support to HTTP2. So the takeaway over here is, as and when your favorite web server starts supporting HTTP2, I think you should give it a try to improve the web performance. We built a bot called NodeBot. The idea behind this was that we wanted to link. We wanted to see how IoT links with JavaScript. So what we did was we took NodeJS as a platform. And basically, we took Raspberry Pi, which is a Linux box. And we took Arduino, which is a microcontroller board. And a motor driver to control the motors. So we linked all three of them using NodeJS. So basically, how it works is this will be explained by everyone. So you're getting a lot of requests regarding how the bot actually works. So it has media technologies involved in it. So the basic thing is NodeJS running on the Raspberry Pi. Raspberry Pi is a small computer. That is actually a Linux box. So you can do whatever you do with your Mac at home, or any of the Linux machine that you have. So you're running a node server on there. So the Raspberry Pi runs a local node server. The user sends a get request to that server. How the get request is something like your IP, then followed by the bot, and then W, A, S, or D, as you have in the FPS games. So if I do a W get request, then it moves the bot forward, A moves it left, D right, and S moves it back. So the second thing is, based on the request, the server communicates with the Arduino. Now, this is the interesting part. There is this awesome module called Serial Node. What it does is it takes the signal from your Raspberry Pi from your node server, and it sends it to the Arduino. Now, actually communicating between these two has been a headache since a lot of years. But since last year, there has been this module called Serial Node that actually helps you to code in JavaScript and communicate with the Arduino. Or else, you have to write the whole Arduino code in C and you have to do a lot of RXT stuff. And that's a little into the electronic side. And the third thing is the Arduino interprets the signal and directs the motors accordingly. So we have the Arduino connected to a motor driver. The motor driver is actually a relay. The Arduino runs on five volts. The motor runs on 12 volts. So the Arduino signals the motor driver to provide the voltage to those motors if they are to move forward, backward, left or right. So the fourth thing is, if a camera request is encountered, the Pi invokes the attached webcam. So the webcam is directly attached to the Raspberry Pi. If that is encountered, it captures an image and tweets it as you would have been seeing on the JS channel Twitter handle. So that's about it regarding the presentation. And thanks a lot. So this is a small demo that we would like to give you. It's better if you guys smile, so. And here we have the controller on the JS channel Twitter handle, you can check that out. It tweeted. Yeah, it has tweeted now. So we can check it on the JS channel Twitter handle. OK, so it just took a bit of effort. We'll absolutely take one more. Yeah, this one is better. Thanks a lot. You can follow the JS mode God on the Twitter handle. That is JS mode God. So our title is using web components in production, best practices. So I'm not going to give any introduction of web components and what they are and how they are used. So I'm just going to give a brief description of our use case and our need to use components. So basically, in our form, we have a plethora of web apps ranging from built-in 2 hours to bit to manage. So previously, all of this was being used internally. Recently, we started serving external clients. For that, we needed a consistent look and feel. And along the lines of this, we needed a central place to control our code, which is being distributed throughout the firm. So basically, I mean, obvious question is why not use a framework? Because we didn't want to do a complete rewrite when some developers sitting miles away decide to change an API, Angular 2.0. So yeah, so for the same reason, we are not using Polymer. We are using the native implementation of web components. And so we did a survey, found out the survey throughout the firm and found out the common use cases and developed widgets based on that. So this infra will be used throughout the firm and it will be served as a platform. So what are the challenges we faced in productionizing web component? That's what we are going to share along with the solutions. So basic challenge we faced is ease of use. So basically, if you're developing a component and if you're developing a set of components, so basically the APIs and event generation, everything. So basically, if one developer is using an input element, other one is using a different input element, both of them should listen to the same event. So that's what I'm talking about when I'm saying ease of use. So component developed by a central team should be easy to use throughout the firm. Second is maintaining maintainability and reducing the footprint. And third would be obviously to tackle the lesser support across the browser. So we are going to take a look along the solutions. First solution, the solution to the problem for ease of use. So basically we wanted to get everyone on board with using our set of components. So we needed to show them that it's very easy to use a web component. So the first thing would be, so we set out deciding what element should go in some groups. So we created a bunch of elements like input elements, like the elements which interact with the server side and things like that. So the challenges we faced there were, so we basically needed some sort of standard practices across all our components. So the approach that we take while creating a component is we first design the API and that API needs to follow some standard conventions and the API of some set of elements should be close. Like for all input elements, you'll probably have setting of options or like getting out the selected value by the user. So that is something we put our thoughts into. Then for individual component, then this leads to a problem of code maintainability because we can make it easy for the users, but then for us, it becomes a little complicated to handle all the components. So we need to have a code structure around each of our component. So we followed standard JavaScript practices for writing the JS of those components and so we used module pattern, we used things like we used object freeze and seal APIs. So to avoid any malicious like addition or removal of functionality from our components, then we tried to follow the gold standards of web components. So things like keeping the declarative and imperative like both of the ways of using the component close, there shouldn't be any mismatches. Then so for that we used, we used private methods within our component design and we basically synced both of the implementations to one method call. So then other standards like you can attach or detach the component anytime you want and it should function well. So this is what we did for basically making it easy for the users and at the same time, keeping the code maintainability. So the second problem he mentioned was minimizing the footprint. So we built up, so we are using a basic grand build ecosystem. So with that what we get is we keep separate files for SCSS and our HTML and JS and finally we collate all of them to form one single component which can be used and then again, so we have a set of components and then we can merge them together to a single file basically which the user can import. So with that he just gets all the components and we have that file minified so it also minimizes the footprint. So the third problem that we talked, so there was another problem with our approach. So we needed consistency across all our applications because we wanted our platform to look like unified. So basically distributing the components, we chose an approach of CDN. So when we have a one minified, one single minified file which can be used for all the components, we just import that single file into all our applications. We distribute that using a CDN. So with this, so we are planning to use web components very much in production for our applications and so I would like to say that they're not a thing of the future anymore. Thank you guys, thank you. So I'll directly get to the meat of it. I wanted to share this tip with everybody. This is kind of a tip. When I kind of first came across Closer and Scopechains, the things were very cryptic and I couldn't understand them properly. Then I looked at the execution model of JavaScript and sort of like reason from that point of view and everything became very clear. So here I have an example. In fact, this is something I scribbled this morning and I will have a JSON example as well. So just follow along with me and see this code example, very simple example and how it is kind of structured in the execution model. So let's say you have this code of JavaScript which defines a function A, inside that you have a written function B and inside that you have another function C and so on and so forth. We kind of will come to how the execution happens for these things but first thing you should understand is JavaScript is a load and go system. It's a text by system. So the moment it kind of sees your script, it kind of tries to interpret it and execute it. So the first thing that happens is when it looks at the definition of A, what it does is basically it creates the object A for fe in the heap memory. You can see that and that's pretty much about it and then it just keeps it as a string. It doesn't go beyond that. It doesn't even know B and C exist at this point of time. When you actually make a call to A, it creates the execution context for A and that's what the block is. It's the execution context of A and all the variables that are there are actually defined there and that's when, when it's actually executing A, that's when it encounters the definition of B and that's when it actually makes another object called function B and then it kind of gets a pointer back to the execution of A which was already executing. This is ScopeChain basically and that's how JavaScript defines everything. This is what makes asynchronous programming even possible. Now, when I execute B and I have given explicit reference B1 here, so basically B1 is another variable which points to F of B. But then when I execute B1, that's when the execution context of B1 is in progress, it's in memory and when this code is trying to execute B, that's when it encounters the definition of C and that's when it will create the object for C. So you have to understand that all A, B, C are not actually created in memory whenever you try to execute this code as long as you don't execute the function and then whenever a new function definition is actually there, it kind of points back to the execution context of the previous function. Now, what happens here is as long as you have any reference to any of these objects which is actually a pure function, all these ScopeChains all the way up to the window actually holds true in the memory but then the moment you lose the reference, everything is gone. For example, over here if you see the function C gets defined here, called here and that's it, there is no reference back so C just gets created, execution context gets created and then it just gets destroyed immediately. But B1 is external variable which holds onto the execution context of F of B and then it kind of intern holds onto the execution context of A of B. Let's take a very simple example of closure to kind of understand how it exactly works. So for example, if I have to compose it a function called makeAdder and I want this function to be generic enough that you can pass a value and then I want kind of the other function to return a function and that I can execute over and over and over again to see the result. So here if you see I have a function makeAdder that takes a parameter number and I have initialized sum to zero and then I return a function add so when I call makeAdder that's when the add function is actually getting defined and whatever the context of INC and sum is it holds onto that. So you can see I have created two adders here adder three and adder two and I have passed two different parameters here. The moment I call these functions adder three and adder two, it kind of holds onto the execution context of the previous one so it runs as if those variables are hidden. So you see that the first one returns three, six, nine, 12 and the second one returns two, four, six, eight and you can just kind of keep on doing that make more composable functions. All only thing you need to know is as long as you can hold a reference to a function which is defined, the function itself holds all the references back to the execution context and that's how setTimeOut, your all event handlers everything works. In fact, this is one of the core functionalities of JavaScript. One quick thing I want to sort of like show as well. So if I just copy paste the same thing in console you can actually see the closure. Not a lot of people know about this but take any example if you just paste this out the same thing happens. But if I do console.dir of adder three for example, it shows me what this function definition is but if you just explore more you can actually see what the function scopes are and then you can see that it holds the reference to the closure and the closure has that state with the function as long as this reference exists this closure will exist and the only way to access this reference is through this function in location. So pretty much that's what I wanted to cover. It is not a lightning talk. It's a lightning quiz. So I'll ask a question you have to raise hand answer it and then you get this limited edition t-shirt the one that we are wearing. So not the like we are not going to remove it we'll give you brand new ones. First one, seven built in data types in JavaScript. What are they? Come on. Yeah I mean just stand up and speak up yeah. Function is not a type. Function is also an object. Last one I think. Yeah it's fine I mean you made six I guess. You can come over and collect the t-shirt. So these are the answers. First three are primitives and the remaining ones are object non-primitive ones. The symbol is what is added newly in year six. Next question a value which is not equal to itself. Come on come on come on. So we have around 25 t-shirts so maybe per question we can give two or three t-shirts at the most otherwise we'll have to remove ours. So it's man. When will this call me be called? At least come on. So it's at least can you explain why it is at least one millisecond? Yeah because it has single threaded and it is event-driven environment. Okay. So you can't guarantee it. Next question four ways to alter this in a function call. Four ways yeah bind. Okay. Fourth one. But again that is also call apply or whatever. Using dot operator. But then that is not altering the this. That is what you are giving before dot. Last one. Fourth one come on guys. New yeah come on. Who is it? So it's new. Yep. Who said new come on. Collect the t-shirt. All right what is this? Generator yeah come on. So this is so we covered basic JavaScript and this is now ES6 kind of questions. So even next one is from ES6. Alternative of arguments object in ES6. What is it? So it is getting deprecated in ES6. So there must be something using which you can do something similar to arguments. I hope you know what is arguments. It is array like object but not array. Triple dot yeah come on. So it's called rest parameter or spread operator. All right. Okay so what are these? Six to five Babel. But that is not the question okay. Question is six to five was renamed to Babel. That's the question why it was renamed to Babel. Come on yeah you got it. So it you know the world is moving so fast. It supports it converts seven to five as well. So it was it had to be renamed to something else from six to five. All right arrange this in chronological order. Like you are in KBC. Come on. And it's fastest finger chronological order oldest first newest last come on. So only person who is confident just stand up and say it okay. No yeah no dojo yeah I mean stand up someone stand up. Yeah. Dojo. Backbone no not not backbone angular came before backbone. So that's the wrong answer. Okay so anyone else want to try. So really I will go to the bottom meet your react would stay as it is it's dojo first. So it's 2004 dojo 2006 jQuery. EXTJS 2007 angular 2009 backbone came after angular. Okay so it was it was you know growing in in Google already then number meteor react. All right so I'll keep this t-shirts for me. Code name of angular 1.0 1.2 1.3 and 1.4. So there is some code names that are used inside Google to name these. So I'll give you a hint. It is two words with a hyphen in between. You know why hyphen because it is all you know hyphen in it thing. So come on 1.0 1.2 1.3 1.4 1.1 didn't had any name. No no so the first one it is like something super heroic okay. So this one is a very difficult one. Even I don't remember. So these are the names. Okay nice last one I don't want to even pronounce it. Okay I think I'll go I'll I'll I'll not be able to do it. All right so this is react.js era now query language that you can write directly in HTML in interview. JSX okay yeah come on I mean collect the t-shirt. How can we write HTML in JavaScript. So we used to write JavaScript inside HTML but now it is going the other way. We are writing but what is making it possible in react.js JSX come on. And this is a tough one. What is the new react.js app framework. Relay yeah relays the answer. It was simple I think okay. Okay so I'm from GBA I have to talk about GBA as well. So we are our office located within India outside India. Come on stand up. Gurgaon Gurgaon Bangalore come on. Amsterdam okay three four five come on two more. So it's a Dutch company. So Amsterdam it's located in Hilversum Netherlands Paris France Boston USA and Gurgaon Bangalore and now this is not JavaScript. So so why why this is here. Okay I mean there's some analogy that I'm going to build. So this Pluto but this is not the question. This is the question. Mission name the key date. It happened just few days back. Distance that it covered the duration it took and the number of moons it has come on. I mean just stand up I mean six years. No nine and a half years yeah okay. Now distance any guess distance these are the answers. So mission name is New Horizon. 14 July it reached or passed Pluto. It was called fly by three billion miles in 9.5 years. Five moons. So here is the analogy. JavaScript is like Pluto okay. Pluto lost its planetary status you know long back and same was the case with JavaScript. It didn't have you know status of programming language for a very long time and now people are so crazy. The way people are crazy about Pluto nowadays okay. So that's the idea. So what I feel is you should probe JavaScript like there are so many different flavors to it. Node.js, coffee script what not okay. So take any one of it and just you know probe it. All it takes is the plans okay. And then we are hiring all right. So just visit ZBR.com or ZBR.fr okay. Thank you. Thank you Pinneken.