 Good evening. My name is Tushar. I want to talk about web components and more more in line with reactive web components. So just to give you a brief idea of what web components are, web components is a W3C compliant way of creating components. So you heard of react components and element cycle and a lot of Angler and they all help you make components and with web components, you can actually without using any external library trade components and start using it. So that way you get a feature of, you know, just not using Angler, which is 566 KB or react and then, but still get the best of those components. So the best part about web components is it's encapsulated at component level. What that means is if I want to make an optimization for a particular component, I can just go and do that. I don't need to architect my application. For instance, if I'm using react and if I have a performance issue, I'll have to actually re architect the whole application, use a different version of the react or maybe move to a different version of virtual DOM libraries. For instance, we have react, which is much faster and smaller. And, but I have to do it at application level here with this approach, you can just do it at a component level and you can just migrate component after component. So it helps refactoring. It's much easier and plus there are RFC combined. So you don't have these observables or signals to help to communicate between components. So, and they can do a lot more than just styles and layouts. So for example, react components gives you that functionality of writing routers. But what if you could create a component to make an HTTP request? So that's something you can do with web components very easily. So reactive web components is just a simple library, which I created. It's not, it's not a framework. What it does is gives you a way to write a better, it basically gives you a better way of writing web components. So it's reactive by nature. What that means is you create functions which are pure and they have no side effects. And by side effects, I mean you just give him data and they give you data, give you some other data and they are referentially transparent. So if you give him X and if it's a function, it just does multiply it by two, it'll always do that. It'll always give you that value. So you can just replace that function with a variable or a constant and just use that constant instead of moving on. So RFC is basically a way to write these components in a more functionally pure way. And so because the current API, which W3C provides is very imperative in nature. And it's inspired by element cycles, very small footprint, 110 lines. And the concept is simple. You have actions, you have an update function updates the state and it re-renders. So what we have essentially doing is we are re-rendering shadow DOM using virtual DOM. So, um, and you can use any virtual DOM implementation. You can use react, react, snap DOM, and just work. So if you want to tomorrow migrate a particular component, which is slow because it's using react can just plug in snap DOM and just that component migrates to snap DOM and it's much faster. And you don't have to migrate the whole app and it's pretty simple. So you can use JSX if you want, but it works otherwise also. So this is our standard component looks. For example, if you want to make a component, you give an init function, give it a state update function, like a duct makes the changes, updates the state and you re-render. So, and you can then register component, which is pretty standard way of registering web components. So what, what are the advantages? First advantage is architecturally it's simpler. It's easier to understand. It's testable because all these functions are pure. They have no side effects. So for example, another advantage is performance. So if you use react as a big library, the performance that you get isn't that great. For instance, this is a swipeable card example that is made by Google people. Very good. And if you see the profile here, it's almost flat. And this is actually throttled to 5X. And this is what is the equivalent in react. And if you see this, it's got all this yellow JavaScript running all the time. And if you use web content, what you can do is you can optimize this and you can find a middle part somewhere here. This, this, this application uses web components and is built using snapdom. So the, and if you see what it does is actually is a, the application itself is a web component. So you have a app FG app, which is just a prefix and you, the app itself is a web component and you can have a lot of things inside it. For instance, you have this HTTP component that automatically makes HTTP requests. So I can show an example. For example, you are searching for a song and you just see as I type, it's making HTTP requests and it's automatically canceling the previous request. It also debounces. So you can do a lot more with web components and write it, also write it in a good way using RwC. So yeah, that's it. Thanks. There are no questions after the flash talks. Please meet the speakers outside. Up next is Sunil Pai. Can you guys hear me? This is the first time I'm doing this when I'm unemployed. So if you guys, I'm open to a job office, I guess. So what's happening? Why is this not? Okay. So anyone here build user interfaces? I guess pretty much everyone. Yeah. I'd look something like this. This is Mintra spent a bunch of my life here. Maybe Insta Mojo Parkash is around. I spent half my life here on my Twitter page. Yeah, and it's quite nice, right? And you guys use one of these frameworks or one of your own or homegrown, even the guys who say that they don't use frameworks. Cool. And you guys make a little diagram of all the pieces of your framework and I copied this from Google. This isn't the way I would build it, of course. And then you compose them into components. This is how React would show it, right? And then like you'll use a little tool that that you mess with the components. And this is how you build user interfaces. Cool. Awesome. So now what about the tools that you actually use? What did they look like? You have a terminal with four tabs open, one for your database, one for your app, like a webpack thing running somewhere, a node app in another one. Any time you want to make a change, you have to make a change in your webpack config or your browserify config, you have to edit JSON, you have to Google what the API is. Maybe you run a bunch of tests and this is what your test config would look like, your different configurations for production or what not. Kind of shit. How do you hold these things together? Do you every time you start up the app, do you have to run a few commands? Do some of you guys use Docker? That's kind of useful, I guess you can start up some things in a VM. Stop tweeting at me please. Okay. What about your build systems? Do you use npm scripts, something like grunt, gulp, grunch, some variant of it? You write a whole bunch more scripts and it's more code that the next person who comes in has to see. Maybe we should think differently. We are of course UI developers. We spend hours and weeks and months and years building pixel perfect interfaces for our users to use. Whereas the interfaces we look are kind of crappy. What if I could do this with my workspace? Like, I really want, I mean, I have a composition structure with react or web components or whatever. What if I could mount all my stuff like this? People use normon to like restart on every file change, no? But react gives me like hot loading. So I should be able to change the port there and just have the server change. Why can't I make a menu with my scripts? I'd go and find out in my package.json what the scripts are available. Why can't I have a little page that says that has three menu links that let me do this or whatever you want with little buttons to restart your server or whatever? What if I could use a router, one of 5000 routers or the very controversial react router launch, the new thing that just came out? Why can't I use that? Because that's a way to route my actions to different places, no? Why do I have to write gulp tasks for it? What if I could start up my app with a URL? Like fundamentally, I say different tasks in my thing, a point to different URLs and I can pass query parameters. Why do I have to learn what command line flags you have decided for your thing? URLs are a pretty generic, well known way of building stuff. Why can't I put a browser into this directly or a terminal into my workspace? Like these are questions that I've been asking about my workspace while I've been building it. Any respectable mad scientist doesn't run around five different tables, right? You try to get everything together in one place for your tools. It doesn't have to be neat, but it just has to be something that you're comfortable with. This isn't a talk about react at all. It barely has to do with JavaScript really. But it strikes me that we are in the job of building great interfaces between humans and computers. So this is a talk on human computer interaction for our own jobs or for your own projects or side projects. Stuff that I showed you isn't really new. We have the tools for it right now. You guys watch the electron talk, I'm sure. Cool. You guys watch the electron talk. These are things that are already possible. In fact, the code that I just showed you is working right here. See, I have a little shell thing that's spitting out what my list is. I have a little server running. This is just an electron app with a react app running inside it. These are the things that we should be building now. This is what the road to minority report where you're doing all those cool things is incremental. We should start looking at the pieces that we have and be able to compose them in ways that we are already comfortable with. Use web components, use react who cares. Just move away from a command line that has was outdated about 50 years ago. Thought leader called it abstraction abuse and he thought he was insulting me online. But I happen to think it's a great punk rock band name. So abstraction abuse for them. Look at the tools that you're already using for other people and build your own tools with it. Thanks. Next up, so big muscle. Is it audible? Yes. Okay. Hello, everybody. My name is so big, but I'm a freelance full stack JavaScript developer. Sorry. I don't have any slides with me like with my previous company. We used to have a card for all type of communication and that's kind of stuck to me. So I think we'll do the same thing. And this is going to be more about a discussion with you rather than, you know, showing some syntax on slide. So what I'm going to talk about today is a component based approach in AngularJS 1.x, 1.5 specifically. So what exactly are components? Notice we hear about components in all our frameworks and standards in JavaScript, right? Not just the script, in fact, in all the languages, we hear about web components, we hear about Angular 2, the components in languages. So everybody is actually going towards a component based approach. And so why exactly this sudden change? This is not really a sudden change actually, because in any other language also, if you would have seen, there is always a natural progression of going from a procedural way of doing things to an object oriented way of doing things. How does it differ? For example, let's say if I have to tell my friend who is new to Bangalore and he's staying in Koramangala, I have to tell him to go to forum and buy a movie ticket. I'll have to tell him step by step. I'll have to tell him go out of the house, take the right turn towards BDA main road, then go towards Jyothiniwa college road, then take the left turn and then right turn and then you reach forum. So I have to tell him every step in detail. But when my friend is there in the city for more than a year, I know he already is aware of forum. I just tell him, you just go to forum and buy me a ticket. So that's the difference. That's the key thing. The thing of handling complexity. When the things are smaller in size, you tend to have a procedural way of doing things. But when your complexity of your application increases, you want to look at things more from the object oriented way, which is the component based way. So Angler.js, although in 2.0 is totally component based in 1.0, 1.5.x, they introduce the concept of components, wherein you can actually create components as a Timel tag and using your application. But wait a minute, aren't these already there in Angler.js 1.4 and before like using directives, but not really because directives. If you look at it, I can create an HTML tag, say my foo and then I can have my own custom logic over there. But that is not all. I can just create an attribute with the name as my few. So for example, if I want to create an input box and I want to have the behavior of it to be a currency. So I say that, okay, you know what this input box is supposed to take on the currency values, which means it should have two digits after the dot. If I try to enter any alphabets, numeric characters do not allow it, maybe show a red color at the background. So these kinds of things are behaviors. So basically we are adding extra behavior on the existing HTML. And that was the purpose of a directive to actually enhance their DOM. But the concept of a component is actually not to enhance DOM, but to create a component. And that mindset difference is what makes all the difference. Component is actually just a sugar coating over directives. But then so it basically it says that, you know what, scopes, it will always be true in that case of a component, bind to controller will be the default. You don't have to specify your controller names. You can just use the dollar CTRL by default. And then there will be a good on init and on destroy methods that we'll have over there. So these kinds of things is kind of you're restricting your directive to say that, you know what, you have to do just this way to behave as a component. Why this is important is I'll give you an example from my gym. Earlier I should do a lot of bicep exercises, and I should try to live as heavy as I can. But I would see that while I'm doing that, suddenly I will move all my body around to try to live that way. Then one day my friend came to me and told me that, you know what, this is the wrong way you're doing it. You have to just sit down and then do it because now I'm restricting you to just move your bicep. So this is what we are trying to do with components. We are restricting the directive. We are saying that, okay, you know what, you're gonna just be a general purpose thing. You have to behave this way so that you can behave like a component. So that's the main thing about, you know, moving from directives to components. And okay, so now quickly about how to move into a component. First of all, your application, if it has directives, angle of this application, try to divide it between components and behaviors. Like the current example I told you, that was actually a behavior. So move all those things into a folder name as behaviors and move all your other directives, convert them, refactor them into components. Try to have immutability in your components. Try to have one way binding and then try to have all your CSS, HTML and JavaScript of a component together within the one folder itself. So that way it gives you a very clean picture that this is the component that I can use all across my application. So yeah, so that's about it. I guess, and the one last point that I want to just make, I want to say is that if you go this way, moving from AngularJS 1.x to AngularJS 2 will be much easier. Maybe not syntactically, there might not be tools to direct imported that way. But because you have structured your application this way, it will be much easier for you to, you know, just change one component at a time and move to an AngularJS 2.0 framework tomorrow. Okay, thank you. Thanks, Ovik. Next is Roshan. Check, check. Hello everyone. So this is my, I mean, I've been hearing all the talks, especially around performance. We have had a lot of talks on web performance and people really asking, how do we do real user monitoring, Google Analytics gives, you know, all the metrics with respect to your conversion rates and other things. So I've been doing this, my passion project turned into a serious thing. You know, there's a website called ironmycard.com which I developed. And it was like, you know, one man army, you know, I did the whole thing. So I'm a software engineer. So user experience design, user interface design, all these things were new to me. So when I started it, so I did use Google Analytics, but I realized that beyond a point, there were limitations to it. I was not able to really feel what the user is doing. And if you really look at the UI practices, the typical user designer would do huge, the lean UX and other practices, people follow, they'll actually interview the users, talk to users and see how they're doing it. So sometimes this gives much more information than what a typical tabular data would give. So one of the critical things when it comes to real user monitoring or to see what the real user is doing, it's basically it would be best to see what the user is actually doing. So when I was doing this, I did show it to a couple of my friends, you know, people whom I know to say, okay, you use the site and I will just watch over and, you know, see what you're doing. But the problem with that is people will turn around and ask you, okay, what do I do next? You know, you just cannot avoid that. So then I was talking to many people. And I came across this nice tool. Surprisingly, I didn't have any. It's a pretty old and it's been there for some time. It's called hard job. So what you can do with this is you can actually record your entire users session and it will replay it to you whenever you want. So and when I use this, this gave really beautiful insights. One with respect to your design as well, you know, what the user is clicking, where is going, what is trying to do. And second, sometimes you also get to know how much he's waiting. It also sort of captures the wait times and other things. So I'll just quickly show you. So this is the dashboard. And it comes with a simple, you know, small script. You just have to add it just like your Google script and all. And then you can further control, you know, how many users, you know, how many, whether you want to capture all 100% of your users or you want only a slice of it. Okay. So this is the dashboard. So and it's a freemium model. So basic 300 recordings and all you can do it for free. So if you're just a startup, if you're just experimenting, you can just go ahead and try it for free, right? There are heat maps, recordings and funnels. I think recording is the most interesting thing that I saw. And you could tag it also, like, for example, I have tagged it here. Let's say some of the UI success is sort of, you know, what I saw. Okay. Right. So let's say on 12th August, something was there here. I just click what happened here. So see, the user came, checked the homepage, trying to, you know, this is a recommendation thing that we do. So it's answering the questionnaire. He again went and then it really gives, you know, critical information. See, he tried to set the error mark. So one is the user design. And then you know, I'll show you quickly. And you can, you know, increase the speed also here. If you don't have patience. So this is one, I'll show you the one where we're talking about. So this one captures, you know, here the user is frustrated, because maybe he was on a bad network or something. And you know, it didn't. Yeah, this is the other one. See, this is what had happened is we had done a cyclic carousel. So the user didn't realize actually, you know, he kept clicking and said, why is it coming? You know, you can see the number of clicks. And then here when they are searching, it was taking really long time. I think it was at this point. It's not coming. And you know, in some cases, the order was doing. So basically, so it gives, it sort of gives a view of, you know, how what actually the user experienced. And you know, with respect to security, yes, it does take care of sensitive fields. If you're marked your fields as password or any secret fields, it will do that. And you can further instrument the code to you know, customize it for your needs. And you also have this heat maps view, which you will get to see where the user was scrolling most, which part, you know, of the entire screen, especially if it's a single page application, if it is too much of scroll, you can see the click and even the move and the scroll. And you could even track the conversion rates. See it is. And then once it read is hot, green means cold, which means they are not doing it. And then there are funnels to see the conversion rates. They came to one of the pages and then they go to the other page. And along with it, of course, you can do other polls and other things. If you are in on the page here, you'll get it, you know, some of the polls you can do other, you know, nice here and there things. Okay. So that's it. Hope this helps. Snake Anju. Not here. Akhil Agarwal. Snake Anju. Akhil Agarwal. Okay. Supreet Palsing. You're the tweeter. Yeah. So very quickly in five, but like I now in 15 minutes, I will very comfortably show you how to build a JavaScript transpiler. It sounds very fancy, but it's really not. So what we need to do is we need to convert JavaScript into any other language. So transpiling means one high level language to some other high level language. But now I'm going to demonstrate how to convert JavaScript into any language. So I had to pick a language, which language would I pick? So I'm going to pick English. I'm going to convert JavaScript into English. We are going to do it in five minutes. So let's do it very quickly. Some things which I'm not going to explain is NPM, Babel, ECMAScript, some basic JavaScript latest technologies. So yeah, so this is an NPM package. It includes Babel and it includes Babeltrovers and it includes Babelon. So the last two is something which you probably don't know. And that's what I'm going to explain. Babelon is a parser which takes in JavaScript and gives you abstract syntax tree. It sounds very fancy. It's not it's just a JSON. Okay. For all intents and purposes, an abstract syntax tree is just a JSON which you can traverse, which you can pick up elements from and consume them. And Babelt reverse will kind of help you traverse that abstract syntax tree. Okay. So let's go into the code. This tiny piece of code. We start from the top. So I'm include including everything I need. Babelon is the parser. Babeltrovers will help me traverse the abstract syntax tree and effect FS will just help me write to a file, read from a file, write to a file. Okay. So input file, output file, input file is basically going to take an argument from your command line, which is the file which I need to read the code from output file will tell you which is the file I need to write the code to. Okay. And this is where I read the file. Input file, FS read file saying the code is over here. Okay. It is in utf it. I use Babylon pars. Whatever was in that file will now be parsed over here into an abstract syntax tree. It's nothing. It's just a JSON. Okay. It's just a JSON. And I'm going to traverse it using the traverse function. Now there are two parts of it. One is entered. The other is exit. So if there is, if there's a code block, right? For example, there's an if statement, you will enter it and you will exit it. If there's a for loop, you will enter it and you will exit it. Right. So that's what this does. It will enter and it will exit. Every time it enters something, this enter will get called. Every time it exits something, this exit will get called. Okay. And now it has an argument which is path, which is the JSON, which that is that you're going to consume, right? And how does that look like it looks? It looks like this. Okay. So for my piece of code, I'm just right going to declare a variable. So it says it's a variable declarator. It tells me which where does it start? Where does it end in the file? But I don't have to care all about all of that. You can get really fancy, do really fancy stuff. All I'm going to do is take this is what's important to me. What is the name of the variable and what is the value of the variable, right? Name and value. How do I get it? I go into path.id.name and path.init.value. So that's what I'm going to pick over here. And you should ideally use template strings, but to make it look simple and easy to read, I'm just going to use normal string. So I'm going to create a string which I'm going to eventually write to a file. So so string is that string which I'm going to create. So what am I saying? I'm saying variable space. What's the name of the variable? Is equal to what's the value of the variable? All right. Following variable name of the variable is equal to what's the value of the variable. So this is my code, right? Variable A is equal to five. Now I have to go convert it into English. And this is all I need to convert it into English, right? So I call npm test. So npm test does nothing, but it just calls the node process. This is what npm does. It it calls bevel to convert into normal JavaScript. And then it gives an example, input and output file. It provides the file path name where to pick it up from and where to give it, where to output it. So this gets converted into this. Variable A is equal to five as simple as that. But let me do write another one. Maybe start good, right? Equal to 10. I save it. I call npm test again. Variable B is equal to 10. Done. Thanks. I'm also going to put this code on GitHub. So you can. This is me everywhere. So reparked. This is me everywhere on all of the internet, GitHub, Twitter, Facebook, whatever. And I'm going to put this code. You can clone it and you can actually expand it to do a lot of things. You can use it to optimize your production code by converting one type of loops to another type of loops. You can do all sorts of fancy stuff. Everything that you see in the model build system like bevel webpack uses abstract syntax trees to compile everything. Okay. Thank you. Check. Thanks. Next is Shreeter. Hello, everyone. So I myself Shreeter. I work at Practor and today I'll be giving a flashback on a life after a page load. So since morning, we have been seeing a lot of talks, talks about like initial page load time and then kind of a time to first date and then time it takes to you know, let the user to have a first interaction something like that. Right. So now I'll be talking about what happens after the page load. So cool. So I am actually I'm part of Practor Ray. So Ray is a software for doctors where doctor can actually manage manage their appointments and then reminders, follow up and their patient health records to billing and then follow up something like that. So as I mentioned, so calendar is one of the important application at Practor, Practor Ray, where doctor can manage their appointments with the patients. They can actually have a look at the day schedule and then they can have a look at they can apply filters on the doctors and like receptionist can also create appointments for doctors something like that. So here doctor can actually doctor or receptionist can go to next month or come back to previous month or something like that and check the appointments book for book for I mean each doctor. Right. So here the problem is there are two problems. One is as and when I move to the next next view, I keep on pitching the appointments from server and then whenever I go back to the previous month, again, I keep on fetching the appointments. So here there are two problems, right? So one is there are a lot of data to be to be fetched from server. And the second second thing is not so good Internet at Practor in India, right? So these are the two things. And this is the kind of after the initial page load, page load. So this is what network time is somewhere around three seconds and then application and application time is even though it's less than one second. Network time is taking too much time and then making the so making the side slower, right? Imagine if you have databases and in your browsers. So thanks to our HTML file and then all the browsers who have support to it. So we have index DB wherein you can store some data in your in your client side that we in browser and then you can have a synchronization. It provides asynchronous APIs. And then it also lets you access the domain. I mean data stored in the same domain. And then you can actually create or open the database database store. And then you can you can actually put the data into the data store by passing the data and then the success callback and error error callback. And if you want to query the data from index DB, you can pass the like you can pass the index and then the key range between lower and upper. And then as usual, like a success callback and error callback. So this is the browser support for index DB. So Chrome right after 49 version 49 and then Safari all those browsers have support to index index DB. So even after this, so if you see all these appointments, now all of them are stored in the index DB and as an end users keep moving to moving to next month or previous month. So we are not making API calls, but we we do have one more problem here, right. So imagine if no appointment, no appointments are stored in index DB. And then if you if you start fetching appointments for future and then past couple of months, it would block the thread for some time for users to I mean not do any interaction, right. So then comes our web worker. Web worker is a kind of chunk of code where we which can run on on a different trade. And it can also make API I mean it can make Ajax calls and then send back the message message to the code which initiated this, which pass this message. And now I keep on, I mean like I keep I keep a check off till when I have a data and then I keep fetching the appointments in a batches and then I keep storing them in the index DB. And now if you look at the load time, right. So with index DB, it would I can I can I can say somewhere around 2.2 seconds. So that's it. Thank you. Thanks, reader and keep many up next. Mike testing one, two, three, one, two, three, Mike testing, check, check, demand off, net banking, COD. Okay. Hi, welcome, guys. So so I feel that there's a little low energy hanging in the room. I checked outside for a rain check. It was still raining. So I was happy that more people can't go out of out of this room. Okay. So I am ankit many and I work at flipkart. And why is my laptop not powering up? Okay. Yeah. With a lack of don't go by the title with the because I lack a great vocabulary, I couldn't find an exciting, intriguing topic for today's talk. So today's talk is about the what the fuck moments which I have while I write code and some gotchas, which like make me lose a lot of time. And we'll be going over that. So the first thing is I heard like reactors all over the park, like everybody knows react and people are writing react. Good, good. So you write a lot of components. And so how many use of you use this dot props in constructor? Okay. So congratulations. You've just broken your port on IE. Please remove this just use prop. Okay. Next, I also heard that people use redux like like crazy. So how many people are few? How many of you guys use redux? Okay. And most of the people have left. So, okay. So the thing with redux is we have all the data in our application right in front end. Okay. And there are there's so many ways we can use that data to have the perceived performance in a lot better way than then like anything put together. So you have heard fancy techniques of PRPL and I don't remember the full form now, but but data in your application can long way in making the perceived performance a lot, lot better. So like when you open a flipkart homepage of search browse page there are tons of products. Similarly, your application might have a list of products for which the API might be different. You might have a different action creator, different reducer, and you might have a different reducer for your normal item like detailed view. But what you can do is you can populate your different store based on the same action using redux. So you can handle a different type of action in a different reducer function, which you can then have a background process in which your data is in sync. So by the time user clicks on your detailed product, you can reuse the browse page data and show him a glimpse of the product. So he's like, wow, my image has been loaded. And like you get so much performance gain. Okay. And like we see a crazy pattern. People use redux and most of you have like async status to check whether you have fired the API call or not. So in your company, you check like if my async status equals to equals pending. What I do, I show a fancy loader, right? And when the data comes back, I show that data. Now, we can do better. So what we will do is instead of showing a loader all the time, we do not do this check. Instead, we check whether the data is empty or not. Okay. And then we show an overlay and and when the new data comes, it just updates in place. Okay. So this is a great tip which has been given to given to me by colleague of enough he gave the first talk. Okay. And and since I work at tip cut, like we are not allowed to do things simply. And you know, I'm a very simple guy. So suppose you have to do you have to do some some interaction and we try to fit in some animation so that we can put more goodness in it for the user. So I'll try to show a simple example. Okay. I have some time left. If only my password was small. Okay. So one second. So I just concentrate on the things which I'm showing you. So this is so this is a image. Right. And like you can see a little bit transition which is going in there. Right. So earlier when I was asked to do some transition, I was always kept confused whether to use CSS transaction, CSS transition or just transition. So after a lot of times what I felt is if your transition is like constant. So suppose your transition, you're trying to transition a drop down box, like when you click and your drop down needs to fall down. Okay. Now this transaction is transition is fixed. Okay. So you can use a CSS transition. Right. But whereas if you are trying to move a card and swipe it, your transition depends upon the user interaction. In that case, you need to use the JavaScript transition and like you can use ease out functions. And what I will show you is, is another thing that suppose you are trying to buy this awesome shoes on this awesome website. So you try click and can you see a little wiggle there? So this is also done via CSS transition because this wiggle is constant no matter how many times user clicks or not. So it does not depend upon my input. And as we all know Paul Lewis and that's what we know that anytime you want to do any transition, use transforms and opacity and do not remember to do will change transform. Okay. But when you do will change transform, you also need to keep in mind the stacking context it creates. And I think all of you know that Zindex works only if you have an element position or if it has a different stacking index. So can you see the problem here? We have these tooltips. We have a tooltip there and and this awesome image zoomer will come on top of it. So you have to keep in control all the Zindex otherwise your application will break. So what thing we do at Flipkart, we try to store the Zindex as part of variable. So we can clearly know which layer comes on top of it. Okay. And last but not the least, how many of you put keys on your web page? React JSX in the map function. Do you use indexes? Please do not do that because it is an anti pattern and react has to suppose you remove an element and add one back in the middle react has no way of telling because keys is the only source of truth. So we had one bug the key was a string and no matter what I did, no matter what I did, I could not find that the image could not update and my code could not go to production for three days. Okay. So never put strings as your keys or or numbers have a unique ID of your object. If it's not possible or write a unique ID generator which generates a unique number every time you require it like it stores it in a closure or something. Okay. I have I okay. Okay. I still have some time. No. Okay. Thank you. Thank you so much. I hope you enjoyed my talk. Thank you so much. Thanks. Thank you. Trashan Sani is next. Hello. Okay. A very good evening guys. So my topic for today is reengineering JavaScript animations. And I would say why the designer why should the designers have all the fun. Okay. So I read a book by the name creative confidence and the book says that anyone can be a creative person. Creativity is all about using whatever problem that you have. You know, finding a innovative and creative solution and implementing it in your code or in your profession and you know. So that got me thinking as a JavaScript developer how can I be a creative person. So I explored on one of the most interesting creative aspects of JavaScript the animations. So I'll briefly just talk about one of my favorite DOM animation libraries. It's called green sock. I would say green sock is a jQuery of animations. And I'll also guide you guys with some of the basics of animations on the way. So I'll be just hand coding some of the stuff. So please show some love. Hello. Yeah, thank you. Very dry audience. Sorry. So we have a very basic HTML here. Hello. So I'll just open this HTML. Oops, you saw something. Okay. Okay. So we have some very basic HTML here. And you know, we have the body tag. I'm just commenting out this thing as of now. Okay. We have a wrapper and we have an image and we have a heading which says welcome to JS. This is how it looks. Okay. Very simple basic stuff. So the first thing that you need to include is the tween max which in I mean a lot of greens green sock includes a lot of plugins which says tween max tween tween max light. I mean, I'm tween light timeline max and timeline light tween. You can include tween max that pretty much includes everything you can know more about the stuff on the green sock website. So I'll I'll just start typing my code here. Since we are on a very limited time, I'll just copy paste some stuff from here and I'll explain the code as I go. So it says tween max. This is the library. Now, this is the element. You can pass on a CSS selector here and you can this is the duration. So you say, okay, for 0.2 seconds, do something. Now, one of the most interesting things greens all these animation libraries have they have all the performance stuff already in place. So you don't need to worry about will change property as the as the previous speakers said and you don't need to worry too much if this is using a 3D transformer or just using something else. So I'm just saying, okay, just go. So there are two things from and to. So I'm saying from 100 pixels on the Y axis come to the current position. So this is the current position. So you'll see this image moving from 100 pixels down to its current position. Very simple animation. Okay, so how about adding one more to into this? I would say, okay, animate the H1 tag as well. But I made it for maybe around three seconds and do it for around. I mean, do it at 200 pixels from its current position. So you can use to my 200. You can use minus 200 and it goes something like this. Okay. So there are three things with when it comes to animation, there are three things without absolutely you have to keep in your mind. One is the duration. This thing, this absolutely matters. Then it's obviously the animation and the third thing is this easing. There are a lot of easing. There are a lot of articles that you can read on a lot of easing that are available on all the libraries. But these are the three things that you should absolutely keep in mind while coding animations. Okay. So how about using a timeline for this? Maybe I'm having two animations. How about, you know, you know, keep creating a timeline for whole animation? So I'm just copy painting pasting this code here. I'm adding it here. Okay. So this code says create a timeline by timeline. I mean a storyboard or something like that. I say, okay, do this and do this and do this. So I have three timelines and I'm saying just two minutes. I'll be done. Sorry. Okay. Okay. So, so I'm saying instead of having two tweens, I'm saying first animate the image, then animate the H1 tag and first create. This is a constructor function. Obviously, then add your timelines here, this. Okay. So I was supposed to include a library called stroll magic. If you would have heard of this, it's a very, very simple library. But unfortunately the time there's no time. So I'll be actually writing an article on this. You can follow me on. You can follow on my blog, which is fresh and sunny spider. You can even there's no internet and deliberately have kept it off so that nobody disturbs me. And this is the last the very simple last demo that I would wanted to show you. So this is how it goes. Thank you. Thank you, Prashant. Up next is Captain Nemo. Hey, still on. Can everyone hear me? There's the DP one. Okay. So I'll still start. Uh, the title of my talk. Yeah, it will take time because I don't have a connector. The title of my talk is All Software Sucks. Oh, no. So the title of my talk is All Software Sucks. How many people agree with the premise? All Software Sucks. Wow, very few. Hopefully by the end of the talk, you will be convinced. Otherwise. Okay. So the talk came about because I realized a while back that, uh, the issues that I was facing on my Mac system were exactly were not even not similar to the system that I faced on my Linux system. But every damn system has its own issues. You know, if I try to. Wow. Projector stuff, by the way. So if I try to play music on my Linux laptop, it doesn't work on Bluetooth. If I try to read NTFS drives on my Mac system, it doesn't work. Uh, Google slides also doesn't work. Uh, not just operating systems, programming languages, you know, CSS often doesn't work. Uh, hardware. You know why we invented TCP? Because routers kept on dropping a package. Hardware also sucks. And now you guys are wondering what's the point of this talk. This is a light heart talk. I should have warned you before. This is I'm not going to teach you guys anything here. Okay, for example, this is my memory usage on my Chrome these days. 25% Gmail, lots of it slacks, lots of it other parts of slacks and the remaining tiny bit is given to my operating system. So, yeah, let's actually try to define suck. What exactly does it mean when a software sucks? A, more very often the definition of B, it doesn't work. B, maybe it's slow. C, it's confusing. And the user experience is bad. I'm trying to do something, but you gave me a form that's really, really bad and terrible to fill out, which is why I don't want to do it. For example, if you're trying to pay, why do you want to know my billing address and my shipping address? If I'm trying to buy, let's say an online ebook. Don't do it. Software crashes. Why? It sucks. So now that we know of this hypothetical quantity called suck, how can we actually use it to build better software? So what I want to think I realized while making up these slides is all of this suckiness comes from complexity in code. So, you know, there's a magical wizard programmer who is trying to tame this complexity. And that's essentially what we do as part of our jobs each and every day. We try to tame complexity by writing pieces of code. Unfortunately, complexity doesn't want to be tamed. Each and every time you write code, you're increasing the complexity of the system itself. So I did some research and it turns out complexity does not correlate well with suckiness. I don't have a better word. People have researched about it and the complexity of a code, if you've measured it properly using metrics like cyclometric complexity, which tell you how many branches your code path may take, it, while it correlates with the number of bugs that people have found in your code, it also correlates exactly the same way with the number of lines in your code. So it doesn't it is a correlation, but there's not a causation. So if you write a longer piece of code, it will have more bugs, obviously. But reducing the piece complexity of a code will not give you better software. So what can we do? My suggestion is to erase the suck. By this, I mean, design is offered in such a way that it behaves performantly. For example, write piece of, write whenever if you're writing a writing process in and think of Erlang, if a process crashes, you let it crash, you work around it. Assume that your software will crash. Assume that will break when you're writing software development as in if you're writing the release cycle of a program, make sure that you leave out time, shipping is not the end part of a release cycle. You ship the program and then you make sure that you fix bugs in it because they're going to be bugs. And that's the end of my talk. Embrace this up. That's my message for you today. I hope you I managed to wake you guys up. Thank you. We have two last talks left. Next is Vivek. And there is one other person after that. So I'll try to make my talk short, but fun. Okay. So how many guys have heard of Noot? Ronald Noot. Okay. How many of you guys have read his books? Okay. How many of you guys understood his books? Okay. No liars in the audience. Okay. So he said a very famous thing. We've been talking about performance all day and I've been doing performance all my life. So it's like premature optimizations, the root of all evil. But you know, for every truth, if you reverse all the things, you should get another awesome truth. So delayed pessimization is the fruit of all good. So what I mean by that, I mean that while you should not consider optimizing so fast and you initially write your code, you should also not be so eager to pessimize your code saying, abhi thik hai, baad mein thik kar lunga. That doesn't work. So let's define optimal. What's optimal? How should your code be? How many of you agree that your code should be maintainable? Okay. Good. How many of you agree that your code should be performant fast? Okay. How many of you agree that, you know, your code should be correct? Look, how many of you write correct code? Okay. One liar spotted. So, so the thing is that correctness is something that, you know, despite all the Haskell programmers telling us that, you know, your programs are proof and code theory and all that. Elephant poaching is illegal India. So those ivory towers should be burnt. Okay. So it doesn't work that way. You cannot predict how a program is going to run. You can never prove a program correct. That's a turing heart problem. So what we got to aim for instead is try to be as correct as possible while not making it so sucky that it's slow because while a crash is bad, a slow thing that works is even bad because the person wants some result to happen. It's not happening fast enough. So what you should do is you should develop some habits in your right code, just like you develop the habit of committing a code and make it maintainable and writing in a verbose in clear fashion and similarly you write your unit test or whatever stuff you used to make sure the code is correct. You must also develop habits that make a code fast. Okay. So the first thing, there are six things that I want to tell you about. They're very short. Habituate optimization, which means that by default, use practices in your language in your framework, which are optimal. Like for example, if you're a C plus programmer, you never use post increment. You use pre increment wherever is possible because it's just a reflex action. You know that at some point of time, post increment is going to take more time. So you to use pre increment or depending on your language, like for example, in JavaScript or in any language, if you have a conditional inside a loop, it's going to be slow. Put the conditional out, make two loops. Fine. Look, before you leave, before you decide that some way of doing things is better, you have to measure. You have to look at other people's work who's done the same thing. Everybody knows that, you know, link lists are awesome for inserting in the middle and all that, but when you measure it, you'll find that actually arrays are faster. That's the way it rolls. These days. So, you know, the computer science says that, OK, order of N and order of one and all that shit. When you measure it, you're going to find that on today's architectures with caches and memory and all that stuff, the arrays actually faster than link list. So always measure. Look before you leave. Don't just blindly trust some intuition. Write the code, write an alternative measure and then progress. Right one to throw away. This is not so much optimization of performance, but optimization of your development process, because you might start out with certain fixer ideas in your mind. You might go down a path and if you get to attach that code, you're going to be led down path that's going to get more and more complex and you'll find yourself conscious. Instead, treat code as something that is consumed and then thrown away. If it gets in a production cool, it doesn't get into production cool. You can just write more of it. None of us here who's a professional programmer will be so bad that you cannot recreate a program which you've created. Even if the source code is gone, you can do it. We all can do it. That's what we're paid for. So don't this one. Fourth point. Just two minutes more. Fourth point is copying is good. Not at runtime, but at compile time. Okay. It's cool to copy stuff which others are invented, but don't do copying at runtime. Okay. Whenever you copy stuff and run it, if you see two blocks of code in your source, which are similar. It's time for an abstraction. You should not be writing the same thing twice, right? Because it's going to execute twice or whatever is processing that HTML or GSX or whatever is going to do it twice. Abstraction means avoid repetition. Never repeat yourself, whether it's functional or whether it's objects or whatever reuse. Okay. Simple as fast. This is a basic thing that's been there from the time of the 80s. The less code you have, less bugs faster. Barring the case that you find a much better algorithm for doing your code, it's always a case that when you remove code stuff gets faster, stuff gets simpler with the deleted code, bugs also get deleted. So that's the way. And then finally, don't reinvent wheels, but also do a reinvent wheels because you need to know how a wheel works. You reinvent a wheel to understand how it works and see what are the challenges that are required to implement a good wheel. But once you learned it, right, then you don't go trying to make the best wheel in the world because a lot of people have done it before. So unless you have infinite free time on your hands and you have some like an awesome, you know, top-class programmer, don't try to reinvent wheels. Do it afterwards in your side project. Do it once you're done with the production. So that's about it. So thanks. Last speaker is Siddharth. All right. All right. I'm sorry I grabbed the last point. I know a lot of you are like waiting, like when can we go home? When is this thing over? Awesome. All right. So, uh, Sinil Pai talked a little about how we really care about how our UI is and how our content strategy is and how it should look and feel like, like they've gone overblown on UX, right? But when it comes to developer tools, we kind of really suck, right? So I'll give you this example, right? This is something that I've done a thousand times, right? So I sometimes write in Node, right? And I'll do something very simple, like express, require, express, right? And now after I've written this, what I have to do is I have to leave my sublime, I have to go to my terminal, I have to NPM install express save. Let me just, right? And I find this very annoying. Like I'm in between my code. I have to quit this and go to my terminal, install something, come back and carry on, right? So just to solve this simple thing, I created a tiny thing, which is, I call it auto install. So you just run up, run it in your terminal. And now everything I do in my code, for example, I install, say YARG. And you see, like, in the background, it's starting installing it, right? So now I can actually move on and use my code rather than worry about jumping between my terminal and this, right? And of course, when you remove it, it will also uninstall and all of that, right? And so naturally after creating this, I did what any developer would do, right? I put it in a, I basically put it on GitHub and shared it on Hacker News, right? And this, this is the best part, right? This is the part I enjoyed. The moment I shared it, this was a blast, right? Like people started on, oh my God, why do people still use npm? And what is this joke? And like, let me just go, right? So it was like amazing. And this is my favorite comment, right? Just when you thought dependency hell couldn't get worse, it became automatic, right? Like, awesome. And so like, so there is something though that I learned. So there is an interesting concept called typo squatting, which is effectively people's weight till you make a typo, right? So for example, instead of, say, express, if I make a mistake of saying, say, express with a single S or a triple S, right? And this could be another module, which is not actually expressed, right? It's some actual malicious module, right? And somebody could totally use it. So for example, face, if you say faceboo.com, right, which is a totally legit way to hack someone, it actually goes to Facebook, like Facebook has bought faceboo.com, Facebook.com, Facebook.com, right? Same with Google. Google, right? As many ease as you want, right? It's going to find its way back to some Google domain. Even if it doesn't open Google.com, it will open a 404 page of Google, right? So this is something I learned. It was pretty interesting to learn. And naturally, I had to, like, add something. So I added a secure mode, which only installs stuff, which is popular, right? Otherwise, like, I'll also do this mistake and get into trouble, right? So just something I created over the weekend, you can get it at GitHub, Siddharth KB, which is me slash auto install. Another thing that I'm working on right now is called cron duty. Again, same concept, kind of tired with ugly tools that we have. This is basically cron monitoring. You log in with GitHub and you set up your crons and basically it gives you pretty stuff, like it's same old chronitor, no more of those stuff, but pretty, right? So I'm kind of spending a lot of my time in making our dev tools prettier. If you're interested in the same topic, ping me on, say, Twitter at the same Siddharth KB handle. Let's talk about it. It's something that I'm really interested in. Cool. That's all. Thank you, everyone. We're done for the day. See you tomorrow.