We're testing the AV system. The actual talks will begin in about 20 minutes. And I will have proper announcements in about 10 minutes. But I wanted to remind you that if you wanted to do something in the on conference today, make sure that you go downstairs and write your activity on the whiteboard. We have a workshop going on, another VR workshop, different from yesterday's, I believe. George who gave the talk yesterday is also giving a workshop from 10.30 to noon as part of the on conference. And I've already been approached by lots of people saying, ooh, how do I schedule something? So the way to schedule something is to go downstairs to the whiteboard and write it on. To start a discussion or share your ideas, you can sit and code with friends or strangers, whatever you want to do, if that space is for you. Oh, sorry, I thought you were on. So good to see you all back here today. It is not so good to hear that. Turn my game down a little. Thanks. We'll be starting our first talk in just a few minutes, but of course, there are morning announcements. Today at 10.30, which is 10 minutes after this talk starts, George, who gave the midi talk yesterday, is doing a workshop in the on conference area from 10.30 to noon. George also lost a universal adapter yesterday. It's black, he can plug his American stuff into it. If you happen to see it, could you take it to the help desk so that he can get it back. We also have a VR workshop this afternoon, a different one than was yesterday. I think it's at three, I'll double check and let you know. And that also is in the workshop area downstairs in the banquet hall. We have flash talks today. At 4.30, we have slots for four people. So only four of you need to be brave today. Yesterday we had slots for six and there were absolutely no takers, which was very disappointing. So I hope that we'll have four people come up and get their names on this piece of paper so that they can give flash talks at 4.30. If you are sitting next to a pile of feedback forms, you are super extra lucky today because you get to fill them all in. Actually, I'd like you to pass them along the line, along your row to the people who don't have them. It's just like school, right? This is our last day to harass you about feedback forms. I think some of you turned them in yesterday. I think we got some through our email thing too. We can't make the conference better unless you tell us what to change. So please do tell us how we're doing. Coffee vendor was late this morning so I'm a little bit tired and I apologize if you can't hear me because I'm just really sleepy. We're gonna start our talks. You guys ready? All right. So the first talk of today is the dark arc, oh, see, I need that coffee. The dark art of webpack bundle tuning, which also sounds like it's a music talk. Vijay is the principal architect at Infosys. He's an open source evangelist and developer advocate within and outside of Infosys. He's been working on front end development for over four years now and especially likes webpack. It's becoming more popular these days but people keep having trouble getting it to work. Vijay is gonna simplify this for you. Thank you. Good morning, folks. I hope all of you slept nicely. Am I audible back there? So while all of you are still settling in, let me quickly introduce myself. My name is Vijay Tharab. I am from Pune. I worked for Infosys for last 14 years now as a principal architect. My Twitter handle is here and also if you want to follow along with these slides or run forward, before I go to the slides, you can actually look at the slides over here. You can open it in your browser. I mean, your mobile and you can follow along. If for any reason it is not visible here for you clearly. So I will be talking about webpack bundle tuning. So I hope all of you use webpack. So quick show off and do not use webpack. Do not use. Okay, I still see at least 10, 15 people, 10, 15% of people not using webpack. All right, nice. So I would like to take a minute to explain. So I recently heard a quote which said, every application becomes large enough that it should not be loaded at the start, the whole application. And you only need to load a very small part of your application at the start. And for doing that, you really need to split your application into a smaller bundle and then deliver one bundle at a time. And that is where things like webpack come into play. I mean, webpack is just one of the players. There are other players in the market as well. But webpack is one of the popular ones. And why is webpack popular? Why do developers love webpack? One of the reason is because it has a versatile loading system. Meaning it can load not only JavaScript, but it can load images, style sheets, fonts, PDF files, you name it. I mean, things that you cannot even imagine getting loaded and bundled, those things get loaded and bundled. That is one of the beautiful things that webpack has. Secondly, as I was saying, that we need to do bundling. So that is probably where the webpack has must react that it allows you to make as many number of bundles as you want, you have full control on what you want to do. Then next part that comes in in every JavaScript application delivery is, okay, now I have a new application and I want to deploy. But clients already have an old copy. So now I have to do cache busting somehow. So webpack gives you it in free. Of course, just one line of configuration and you have cache busting set in for you. Fourthly, it has a buzzword that a lot of people already have been talking about that is tree shaking. That is if you are using let's say one or two functions in say D3JS or low dashes, then in the erstwhile or even jQuery, right? I only wanted to use jQuery for $.ajx, but now I'm just getting the entire jQuery in. You should not be doing that. And you should not be doing manually something for it. So webpack gives you a help by doing a tree shaking so that it will shake out anything that you don't need. So it's like literally taking a tree which has connected nodes and then it will shake it. Whatever you don't use falls away. So that's the tree shaking. Beautiful feature that webpack offers. And lastly, webpack has a very big ecosystem of plugins. Probably there are about 200, 300 plugins right now and writing one yourself is not very difficult. It used to be, but they have improved documentation a lot in last three, four months and it has become actually quite manageable to anybody to write the plugin now. So you can go freak yourself out. So these are some of the key reasons why people like webpack. So those who raised their hands, I would definitely urge you to take one more look at webpack, it has been awesome. It has improved a lot in last one year and it's really, really useful nowadays. So but as I said that it has so many features and so many configurable options and there are so many plugins. Does that make it a smart AI system? It does.  That means if we do not configure it right, it is going to create these undesirable effects, right? So one of the key undesirable effects that I came across for webpack is very, very big bloated bundles. The thing for which I wanted to use webpack that it should create small, small application bundles for me so that my application's delivery to the browsers is very fast, it actually did exactly reverse. It created bundles, yes, it split my entire application code into bundles but all of them were really, really big because I did not tell him the right things. But today I learned and I'm going to teach you how do you fix that particular problem and make webpack understand what, how you can fix that thing. So I'll start off with my product experience in a summary, a very quick summary. So if you look at, this is one of the plugins output for webpack. It is showing that, you know, I had five, six, you can forget about service worker but I had six bundles and total size of all the bundles put together was 5.73 MB and it was when I did not tune it at all but when I tuned it, the bundles, number of bundles remained same but if you see the total size of all the bundles now it has become 2.6 MB, that means I saved overall at around 50% and it also, I mean, since I am already showing you a splitted version already so I mean, initial bundle size was not so much of a problem for me but yeah, if you do not configure by default that will be a problem for you to have everything will get bundled into a single chunk or single bundle and everything will get downloaded for you at the start which is not a very optimal scenario. Plus yeah, I mean, out of 2.6 MB maybe I'm going to say another 500 maybe because I still have the AOT compiler in it. I mean, this is my real actual production bundle experience that I'm showing. So how did I do? How did I go about, you know, having the 50% reduction in the bundle sizes? So the most important tool that you need for this particular, you know, activities built in into Webpack which is called as hyphen hyphen JSON option to the Webpack utility. Webpack has a command line, so Webpack CLI. If you pass a hyphen hyphen JSON to it it is going to output or emit a JSON file which will tell you everything about how Webpack did what Webpack did. So now, but obviously it is not very readable by humans. So you need to process it and there are these three tools. Webpack has its own analyzer tool or a website. There is another tool called Webpack visualizer and then there is one more tool called Webpack bundle analyzer. There are two of two tools by same name. So that's why I've written by Thor. If you search along with the keyword Thor on Google you will find it. Or you can simply use these three links at the bottom.   So those are the three tools that we can and I'm going to show you one of the tool in more detail. Resort tool tools I will not show. Each tool has some advantages, some disadvantages. So the Webpack's own analyzer is very good in order to identify the duplicates which is probably the most important thing which I've used it for because I saw all my bundles are bloated. I was like, okay, I don't have so much code. Why my bundles are bloated, right? And then I went about identifying the duplicates. So it gave me built in that the duplicates were given to me automatically. I didn't have to search for them. It directly showed, okay, this particular, you know, module seems to be appearing in bundle one, two and three. Are you sure you want to do that? Or you want to take it out in a common bundle? You know, that kind of help it offers. So, you know, using that kind of help I quickly try to move or tune my bundling and, you know, get rid of a lot of duplicates. It also gives another key reason why I like this particular analyzer is because it tells you as to why certain file is included in your bundle. You know, this happens a lot with me or used to happen a lot with me with low dash earlier. That, you know, I never asked you to get sort by then why are you including sort by in my bundle? I don't want that file. That is seven KBX, I don't want it. But sort by is used by some other, you know, file that I have requested, some other function from low dash that I have requested. So, it tells you the entire graph as to who is dependent on what and how is the whole tree is being built upon. So, that's a very good feature that the webpacks analyzer gives you and it looks something like this. So, this is the stat.js one that I was talking about. I already have it generated and this is how it looks like. This is how it shows the modules and chunks, assets, and if there are any, okay, so assets is where you will know every JS file and which chunk it is part of now, et cetera. And in the hints area, right now, there is no such duplications, but if there are any duplications, hints is where you will see those duplications being shown in. And this is the other visualizer that I am showing here. So, visualizer is also very good because it shows it in a visual format which is also something I really love. So, you just drop the JS one file over here. Okay, so this is the kind of sunburst chart it will create and it will also, if you hover on it, it will tell you that in my application, 99% of the code is coming from node modules. Only 1% is my application. That's all. So, that doesn't seem very good and it also tells me out of that 99%, 11% is by view and 19% by D3 and all that kind of stuff. So, we will be going through this little bit in little bit more detail. But that is the, visually I find it very good that I can easily spot, okay, who is the biggest culprit? That is one of the good thing that I like about it. But lastly, the webpack bundle analyzer is almost like combining both these upper tools and it's really good. And we will be using that tool in the rest of the session. So, I'll show you as we go along. Okay, so enough of talk. I'm going to show you now a demo. I created a small demo to showcase, you know, obviously all the bad things that I can do purposefully and then I'm going to fix it, right? So, here is a small demo. So, there is a bootstrap on the home page, usage of bootstrap.js. Then there is a tab for movement.js. Movement.js, I hope most of you would know it's a date formatting, parsing, manipulation library. So, I use that on one of the tab. I use open layers map. I just wanted to use some map library and I used to know open layers. So, I use that. I use load dash on another tab and then I use D3 where I just draw a small square using D3.select and then just fill it in, right? So, application is using right now Vue.js for MVC, right? But it need not be Vue.js. I just use something. I want to use something. So, I use Vue.js, a bootstrap CSS for styling, movement.js, load dash, open layers, D3, I covered all that. So, this is the application that I built in order to do this particular exercise and then I ran, I did the webpack hyphen hyphen.js so on out of it and then I created these reports, the ones which you saw earlier, the same ones that you saw earlier. And this is the actual third webpack bundle analyzer by Thor, that will create a bundle output like this.  The blue guy out here, that is your application code. And everything else on the screen that you see is all the libraries that I brought in. So much of libraries for such a small application, right? But thankfully this guy makes it very easy to clearly say, okay, who is the culprit? Boss OL.js is just way too much. You really cannot have OL.js for this big. I mean, for what are you using that? You have to find an alternative for this D3.js also, really big. Then there's a huge block of locale from movement.js for whatever reason. Then there is load dash.js also fairly big. Vue, ESM, you know, you need, you can't really do much about it, but yeah, if you can do something about it, it would be nice as well, right? So that is, you know, that's how, you know, we can identify our culprits, right? Sorry. And the most important culprit is that I only have one vendor.js file right now. I have static.js, vendor.js, that is this whole block. And then there is this small block here, which is my applications.js, only two.js files. And that is probably the worst culprit that I have right now. So I'm going to fix this particular culprit first that I have only single vendor file.  So I'm going to just do a hard refresh of this application, the application that I showed you earlier. And you can see here that I have a app CSS, a vendor.js and app.js. I only have app.js and vendor.js. And you can see that vendor.js was 324 KB, which is fairly high amount right now as compared to application.js, which is 3.2 KB. So it's like 99, 1% of the whole thing, right? And if I go across to movement.js or open layers, nothing is getting downloaded in, you know, all these PNG files are for the tiles for the open layer. So ignore that, but nothing from my application is now going, getting downloaded. So everything, even though I never went to load as JS or D3JS pages, all the logic and all the libraries that were required to show those pages were already downloaded on the first page, which is absolutely not very good experience. End user experience when you are talking about, you know, flaky mobile connections, et cetera. So there are a lot of things that that could be done better, right? So that's what we will go about now. And I will walk you through how do we do that? So first we are going to fix the bundles.  I'm going to load them only when I need them, right? So this is how my, you know, the landing.view file or the place where I was having all the other bundles loaded earlier. This is the original code, untuned. So as you can see here, on top I have a static imports of all the other components that I have written in Vue.js. I have a component called movement, not to confuse with movement.js library. This is my page which was showing some text, right? In movement.js. This is my low dash page. So these are all my components which use all these libraries internally. So I had statically imported all these components in my application and I was, you know, doing this routing here and I was giving reference to these components. So what I'm going to change now, very small change, not too much and that's why my title said that small tweaks can earn big. So you know, as you are going to see in this slide and next four, five slides, that I just tuned small, small items, but the rewards are very big, okay? So first of all, as you see, I removed all these static imports above and I also removed static references to the components and I did what is known as Webpack's dynamic import feature. So as you can see by dynamic import, I mean that instead of saying import here, the one static, I give import with a parenthesis and give the component name that should get loaded later. Now yesterday somebody was showing require.ensure. That is exactly same as this and only thing is that require.ensure is a Webpack 1.x version of the same construct. In Webpack 2.0, 3.0 now, you know, you use rather this import construct instead of require.ensure, okay? So what essentially I'm saying here is that, whenever I require movement, you import at that point in time. Right now you don't import anything. This is just a promise that I need movement component, I need load-component, et cetera, et cetera. Okay, so that is all the code change that you need to have to bring down that 900, sorry, 340 KB vendor.js to split into four, five bundles and the first bundle to come down to about 40 KB now. That's all you need and I'll show you that. How it changes. Secondly, I'm going to optimize the open layers component that I had written. This is my open layers component and you know, I was getting a reference to the variable oil from open layers library and then I was using to create a tile and a view and then I was creating a map out of that. So that was a very simple usage of open layers. Now this open layers library is not a ES 2015 compatible. So what open layers guys did was there was a lot of you and cry about their file size on their GitHub page and so they rewrote their library and now they have come up with a new library called OL with version 4.0, okay? So this slightly older code that I have, I wrote it about couple of months ago. So now it is definitely not in beta. So now what I'm going to do is I'm going to change the application to use OL instead of the open layers, the one which is below. So as you can see, I removed the from open layers line and now I'm importing specific things that I want from OL library. Now this is what will enable me to have a tree shaking going on. So instead of, you know, me saying that, okay, I want to use something from open layers and so give me the entire open layers.js one big library. I said, no, I only want tile layer. I only need map view and whatnot, right? So only give me that. I don't want anything else open layers because hundreds of features are very good for you. Just keep it with me. I don't need that, right? So by doing this, it is going to do a tree shaking and because of the tree shaking, your bundle is going to shrink and we will see how big or how small it is going to be, right? And in your code, the only changes were that I don't use now OL dot, et cetera, because I have imported the specific objects directly on top. So in your code, there was hardly any change in order to use the new library, right? So in last six, eight months, I have seen a lot of libraries going through similar transformation and another transformation that I'm going to show you is for D3. Again, if you remember, I was only using D3.select here, if you can see here on top, right? That I did import star as D3 from D3 and then I was using D3.select and then I was drawing a rectangle, that's all, right? But just to use D3.select, I got the whole library earlier. So again, in case of D3, similar changes happened that I went for a different version of D3, which is, and now with the version four, I think version 4.1, I guess. From version 4.1, they support ES2015 specific modules. So you can only import whatever you need. I mean, you can import D3 alone, but just for the sake of showing you that you don't even need to do that, you can always just say, okay, I am not interested in anything else from D3, just give me D3.selection. Then it will only import D3.selection, right? So that is what I did, D3.selection. And then here, the change that I brought was I removed the old line, which was importing the whole D3.select library and I imported just the select function from D3.selection. And you know, just the reference changes. Very small, small changes, not too much. I'm not re-transforming my modules and I am emphasizing on this for any folks who are not using bundling and code splitting, that it is not a very hard exercise and it is also an incremental thing that you can go about. So you don't have to set out, okay, I am going to just, for one string, I'm not going to do anything, I'm just going to do, no, you don't have to. While you are pushing out your code changes for your functionality, you can also push out these things, yeah? So next is, next online is the load-ash. Now load-ash, unfortunately, does not have half-truth statement, does not have a ES2015-based load-library yet. That is, if you go and get load-.js, it is common.js-based. Common.js-based library means that you cannot pre-shake it, okay? While I said it's a half-truth because there is a load--es-library now, which is actually compatible with ES2015, but very few people I have seen to be using it. So if you use that, great. Then you can go for pre-shaking. But if you don't, and for any reason you cannot because you are dependent on some library which uses load-, and there are like thousands of libraries which depend on load-, right? So then you don't have a scope of using load-es, right? So in that case, what are you going to do? There is no ES2015 modules in your hands to do pre-shaking, right? Then you have to now depend on something more, more than what you have been doing so far, whatever you have learned so far. And you have to now take help from some plug-ins. I talked about 200, 300 plug-ins, right? So one of the plug-in I'm going to make use of here. So here I only have one image. So this was my original code that I was importing underscore from load-. And I was using underscore.pick, one of the function just to give an example. So the change that I did was I said, okay, I'm going to use import pick from load- slash pick. Very similar to what I did in case of D3 and open layers. But if I do this much and if I try to see whether pre-shaking has happened, it has not happened. Because load- is not a ES2015 library, right? That's why I have to use this particular plug-in. Now this plug-in is, even though it's a webpack plug-in, it is written and maintained by load-team itself. So you can depend on it. It's not some developer in corner who is writing the plug-in. It is the load-team's own plug-in called load-webpack plug-in. And you just need to give reference to it, that's all. You don't have to do any configuration or anything. It will find out, so two things you need to do in order to get the pre-shaking going for load-. One is you have to do this kind of import and use it. And second is you have to refer this particular plug-in in your application code. And that's it. Then you have the load- as well pre-shaken or at least things that you don't need, they will not be part of your bundle. All right, next in line is movement.js. And on top, I just reproduced the image that I had shown you earlier. So in the movement.js, there are two parts. One is movement.js library itself. Again, movement.js has similar problems as that of load- that it is not a ES2015 library. It's a load- is a common JS format library. So you cannot re-shake it. And unfortunately at this point in time, I do not know any plug-in that will do the similar work for movement.  Now I'm not doing anything for Russian. My client base is not Russian, Armenian, Italian, none of it, but I still have all the files for movement.js in my code base. So how do I fix this? I particularly wanted to take movement.js because there's just so many people who use movement.js and so many people are bundling it without realizing it what to do about it, right? So the fix is very simple, oh, sorry. Fix is very simple. You just need to add a new plug-in reference called context replacement plug-in, which is a Webpack's own plug-in. And you tell him that, boss, whenever you come across a path movement slash locales, I only am interested in these languages, English, Hindi and Marathi. Those three languages, my client base only uses these three languages, so I only want those. I don't care about any other language. So please keep those, remove all the others. And once you give this instruction to Webpack, it will drop everything else. And that's why my talk's name is Tuning it. We are Tuning. So this is the default behavior. If you don't give this line here, Webpack will automatically bring everything. So we need to tune him here and there. We have to tell him, nudge him in the right direction. That's what I'm doing right now, by one by one, right? And nudging him, to fix how his default behavior is. Last and lastly, I also wanted to touch base upon the CSS usage that I was having. I purposefully had added bootstrap.css file in my first application code. And so as part of the optimization, I removed that. And I changed over to SCSS version of bootstrap. That is SAS version, right? And I added a customs SCSS file and custom SCSS is something like this. So I said, boss, I'm only interested in these modules from bootstrap.css. I'm only interested in scaffolding, types, grids and buttons. And I don't want anything else, okay? Just for reference, this is how the big file looks like and the whole thing, you know, the things that I did not include. Things that I did not include, right? Obviously, it is going to bring some optimization and some benefits to me. And we will show you how much benefit I got out of this. So here is a report. This report is created by the Webpack's own analyzer. So the screenshot is from the Webpack's own analyzer. So this is the before tuning application, the one which we have seen already. You can see that there were app vendor and manifest. Manifest is a default bundle that Webpack creates. You can ignore it. Yeah, it's anyway zero bytes. Yeah, vendor, there was only two bundles. So vendor and app. One was two MB. Yeah, it is before GZIP. So when I serve the application, GZIP was on. So it has converted to GZIP number. And application was seven KB. But you can see that they all had initial flag here, meaning when you hit the application, all of them are going to get down there, right? And this is the report afterwards now. So I have this app and vendor as is. And then I have bundles chunks created zero, one, two, and three. I haven't given them any names, but so they will be just referred by their ID, zero, one, two, three, which are additional chunks. But the initial flag now is only to these ones. And you can see two MB vendor has become 236 KB. So almost 90% smaller for my homepage load, right? And even if you combine all of them, your total, okay, sorry, that size I don't have here. Sorry. It doesn't matter anyways. I'm going to show you one more report wherein the comparison is given. Yeah, so the most important it is first, first thing is going to be much faster because earlier you were trying to download two MB of JavaScript. Now you're only downloading 241 KB of JavaScript, right? Let's quickly take a look how it looks like in the application. So here is the app. I'm going to do a hard refresh to show you. This is the tuned application. So even now I have only vendor and app, but the sizes are small, 29 KB now. And this was the old one just for your reference one more time. Three, three, 24 KB. These are GZIP sizes. The one which I have on the screen are, because that's how webpack reports without GZIPing. So I just kept it as it is, right? So a much smaller delivery total, only 41 KB transferred now, earlier 349 KB transferred. And now the magic is here. When I click on movement just, that's when the bundle for movement just got downloaded. When I click on low dash, that's when low dash bundles. When I click on D3, when D3. When I click on open layers. So that is the lazy loading that I was talking about, right? So, and this is how the webpack bundle analyzers output will now look like. So your application is somewhat bigger now. I'm just trying to search where it is. Okay, it is still not able to spot it here quickly. But you have a different outcome now. So you can see that, you know, open layers. I did not bring a single OL.js, but I rather brought only things that I needed, a small, small, small, small module. And you see that there are many more than what I requested. I requested only for four or five things, but obviously they had dependencies internally within OL. They figured it all out and brought whatever was required. Whatever minimal that was possible, they have brought in. They have not brought in anything more than that. On movement.js side, you can see that there is only one movement.js. The locale is so small that it is not even visible here on the corner. So that is the type of improvement that you can visually see in your own application. This is just a snapshot for you to compare. So first page, as I said, we had 350.  So 89% saving I had. So just because of open layers tree shaking, I saved about 41%. Because I was only using D3.select in real life, I know that we will use more than that. So you may not get like 88% as I am showing you here, but this is just to show you in this application, I was able to get 88% saving for D3 alone. Low dash, 86% view, 31% movement.js, 80% and in bootstrap CSS, I got almost 57% of improvement.  So just want to recap quickly whatever I showed you today. I showed you that it is very important to do lazy loading using the bootstraps, sorry, webpacks import function. So this import with this parenthesis, this function is not available elsewhere. It is available only because I'm using webpack. Then we should be making use of reshaking as much as possible. And that is not out of the box possible all the time. So we need to look out for every library's version which is ES 2015 compliant so that you can get help of reshaking for your application. Then wherever that is not possible, like the case of load.js, like the case of movement.js, try to find out plugins for webpack which will help you doing this particular specialized culling, low-cales. I don't want all the low-cales. So I want to cull them out. So something like that. And if you're using bootstrap which quite a few might be using, then also make use of SAS-based version of bootstrap so that you will only include whatever you need and rest will be dropped, could be dropped. So thank you. And I wish you the best for having your tuning journey. So if you like this particular session, please tweet and have a webpack hashtag in it so that all the other webpack users also can benefit out of this. You can find me on GitHub, Twitter, Medium, everywhere as a lot of people. Thank you. Oh, by the way, the code is here. If you have some questions, you can ask them now. There. In your first slide, I saw the two images. And in the second image, there was a file called app common which was taken on 1.2 MB. So I just wanted to know from where the file came. Oh, that is my own bundle that I separated out that in my application, right? Yeah. So, right. So here, the app common was a bundle that I created myself.  So by default, it will create a bundles in certain fashion. Okay, so most of the times the default is creating a vendor bundle out, okay, which will include everything from node modules. But in my application case, what I realized was that I don't want everything from vendor bundle to be, I mean from node modules to be included in one single vendor. Rather, I will create something that is required, absolutely required for my home page dashboard to come up. So which included a charting library and some of the other libraries like that, right? So those parts I picked out and created a separate and then there was, okay, and the polyfill was separate as well. Polyfill is there in the left side also. Okay. Oh, sorry. Just curious about the app common. Oh, I'm sorry. App common is something that I don't load at the start. I only load whatever I need as part of mean and moment my home page is loaded in the background, I load app common essentially. So basically I say 1.2 MB of load at this to render my page. That is the reason why I took out everything that I don't need and put it in a separate. Sorry. Yeah, I'm Pradeep, nice talk by the way. Thank you. So my question was with respect to the legacy application which users require JS. Yes. There is already a Glify.js compiler which way we do all the optimization stuff. Will Webpack suit for it? I tried many times, but I failed. I mean, it's like a lot of plugins are in Webpack, but some of the other it shows a pair saying that Webpack is not, it's throwing up and not many forums were there. Have you tried this scenario? Yes, I have extensively worked on the required JS. So I can give you more details. We probably offline, but there is a R.js which is a sister library along with require which I used for my purpose. So yeah, straight answer about Webpack. Can I go with back way? No, it is not that easy. But R.js pretty much does everything that, but it needs more configuration, more manual effort than Webpack.js. So, but yeah, using R.js, I achieved most of these things in my old application, not the years 2015 reshaking. That is not possible, but bundling, splitting, lazy loading, all that is possible using require plus R.js combination. Maybe I can give you more details of. Hello, thanks for the talk. That's it. How do you handle responsive design for like if you're creating an application, we to say a product which is for both desktop and mobile. So is it better strategy to have a separate code base and then bundling it separately or using this media queries and then having a single code base and then doing some kind of splitting using Webpack? Like how Webpack can help in that scenario? Okay. So it is, it depends frankly. Quick and thorough we depend on your context, but if you really want to split the code for the mobile and for the desktop, it is possible and you can have multiple entry points, for example, given in the Webpack, so that Webpack can create totally separate bundles and using those entry points, you can have totally different code rendered for different things. Right, yeah, I'm assuming that you have separate code base. That's what you said, right? Right, yeah. So yeah, absolutely. Sometimes it is just enough to use media queries and get going, but sometimes you are just bringing your way too many things for desktop which you do not need and client really, really needs super fast, you know, screen painting for mobile, then probably it is right idea to create a different code base. You know, or even in the same code base, you can have blocks and then using specialized Webpack blocks by which Webpack will only pick those parts for you, but it's very risky whatever I just said from testing perspective. Question here. Hi, so suppose I have a requirement of including a JS file, which I can't put inside the vendor thing, so I just want to use CDN to import this file in my index.sdnl page. Now, how is it going to impact my application? Am I abusing Webpack? So what happens in case of Webpack is that internally, as I said, there are a whole bunch of plugins and this view JS application used something called as HTML Webpack plugin to create an index.html for you. What it does is essentially see, it is going to create these bundles for you and I also said that it has cache busting built into it, right? So that means every time you re-run the Webpack, it is going to create a new name for your JS file.  So that's why it creates the index.js for you and by which what I mean is, it simply adds all these new files at the bottom of your body type, okay? For all, reference for all the JS files. So coming to your problem, so your CDN.js as long as it is sitting above these, since it is from CDN, it will get loaded first and then these files, so the order, from the order perspective, it will be already resolved for you. It will be resolved for you. We have a question in balcony. Hello? Yeah. So we usually have most of the application again on desktop web, so we have different screens which have around 50 JS files to 200 JS files for one screen and we have circular dependency also, like from one screen to other screen, we need to have all the live objects all the time. So what do you suggest we need to have all the JS downloaded together at one go or we should go for clicking and then download on demand? Like what would be the better way? Right. I'll transcribe from my experience perspective. So in Angular world, I had similar problems in Angular 4 for example, that I had two modules and both needing some common information. So what I did was I created a common module and kept the code outside in a separate bundle for it. So that both the libraries will just refer that bundle. I ensure that that bundle is getting loaded before. That way my bundle size is optimal, but yes, at the start only the first bundle and the common bundle, both will get downloaded. But second bundle will not have contain the code from common bundle, that's all. Does that help? Question there. Hi. Thank you for the talk. In your example, you had spoken about Lodash. And you also mentioned that Lodash might be used by other components as well. But you picked out, you had used only pick from that. So but the other components which are using Lodash may need more than that. Yes, I agree. Does it replace me? Oh yeah, that is taken care of by Webpack for you. So at the first slide when I said that, what Webpack does is it will parse your entire JS graph. So let's say that you are using, I don't know, D3. Okay, I know that D3 probably does not use Lodash, but let's say D3 depends on Lodash and uses Lodash. So movement it will see that you are importing D3. It will also go and see what all these D3 needs or D3's code that your referring needs. And then it will parse all that and it will pull in. And it will see that you have that Lodash Webpack plugin. So it knows now, okay, you yourself use underscore pick, but let's say the other guys use, you know, let's say sort by or map whatever from Lodash. So then it will take all those and it will put them in the respective appropriate bundles. And everything else that is not referenced will get filed off. Pretty much every library these days is at least common JS and he's able to parse and understand that part of the story. You know, as far as the graph creation in its mind is concerned. We can create the whole power graph. We have a question this side for a long time. Is it possible to use like some plugins to do that reshaking stuff? So as I was showing, reshaking is primarily dependent upon your modules, whichever you want to get reshaken to be written in years 2015, at least in 2015 first. So given that you have those, you don't have to do anything specialized as much as long as you're using Webpack 2. Webpack 2 will take care of reshaking for you. If your modules that you are concerning about are in years 2015 format and you are referencing in that question, no extra plugin is required. This is about the lazy loading feature that you spoke about. So I'm just curious to know, how does it work internally? So the moment it captures the first reference, that is the moment it loads that particular JS or how does it work? As I said, whenever it comes across this import block, it is going to create a split point. They call it split point. So it creates a split point. Meaning from that point onwards, it is not going to parse the, I mean it is going to parse whatever was the parameter that was given to the import because it knows that you want to load it sometime. But it is not going to include, so the parsing is one activity for Webpack which it is going to do, even continue to do, but it is going to not include that particular code content in your main module, where it found a import with a square bracket. It's going to create that part of the separate file. So it's going to parse at the time of building? Or it will be parsing at the time of building, it is going to parse everything and create bundles for you all of them separately. Okay, okay.  So I use whatever was possible in view.js, view.js uses that function. Maybe we can take this offline. I mean because for Angular, there is different way to do that. Yes, please, we would also recommend taking this offline, we're running out of time. I'm sure you must have a lot of questions since Webpack is an interesting technology, but we'll have to cut this. Maybe what I will do is I will just register for a, you may ask me anything session for the unconference area during the day and then whoever wants to discuss Webpack with me can just stop. Right, that's a great way to use the unconference area. Thank you, Vijay. The next three talks are not about JavaScript. They're about alternative languages to JavaScript. So if you are a JS Paris, you should probably go down to the Banquet Hall now. If you're not, you might want to stick around for the next talk. It's called TypeScript, all the things. Prashant is going to talk about TypeScript. He is a full stack software developer at equal experts. He's been writing JavaScript for years, but it was love at first sight when he first saw TypeScript. He's going to walk us through all the rich features of TypeScript and how to use it effectively. I'm an engineer at equal experts, and as you can tell I'm quite fascinated with TypeScript. So in case you haven't heard of it already, don't worry, because I am deeply aware this is 2017 and I'm not here to make your JavaScript fatigue any worse. But in fact, on the contrary, I want to show you how using TypeSystem like TypeScript can actually relieve you of said fatigue, which means that you can go back to doing what you love most, writing amazing code. So I've been working on and off with TypeScript for over one and a half years now, and in all this time I've seen it grow tremendously, like whether it be the incremental advances in its TypeSystem that just keeps on getting better and better every month, or the rich ecosystem around it that also keeps getting better and better, or the amazing developer option and the engagement on GitHub. In fact, Stack Offload had this to say about it as recently as last week. So they've had to omit TypeScript from their recent language rankings because its tremendous growth has kind of started to skew the numbers for the other languages out there. Is that crazy? But the point I really want to make over here is that there's something very interesting and important going on here in this space. And whether or not you end up choosing TypeScript for yourself, you should definitely be taking a very serious look at the state of TypeSystems in JavaScript today. It just happens that TypeScript is the oldest and therefore it has the most mature ecosystem and it also has the best in class tooling, all of which I'll be showing you later on today. So it should probably be your first obvious choice that you should definitely take a look at. Now for a quick intro, so it is two things roll into one. TypeScript is a static type checker for JavaScript and it's also a transpiler. More formally, the TypeScript language itself is a statically typed superset of JavaScript that compiles back down to JavaScript. It's an open source project by Microsoft and it comes with its own compiler which incidentally and interestingly enough is itself written in TypeScript. So the entire TypeScript code base compiles itself. So you know that JavaScript is a dynamic and weakly typed language. It has an implicit runtime type system but it's not really exposed to us as developers to take advantage of. So TypeScript, so basically because you don't have a strong type system in JavaScript, which means that there's nothing to prevent you from writing illegal programs. So that makes you run into all the known bugs that are so easy to make inside of JavaScript. So what TypeScript does is it introduces an explicit design time or compile time type system to JavaScript that not only prevents you from making those mistakes but it also comes with all these other benefits. Again, all of which I'll be showing you later on the examples. It's also transpiler. So you can compile all your ES6 plus code all the way back down to ES3. So in this respect, it's very similar to Babel except that it's much simpler to set up because there's just one configuration file that you need to think of to opt in and out of newer language features. So you don't even need to install any additional plugins once you have the TypeScript package installed in your project. So before I go further, I wanted to just quickly address some of these questions that people keep asking me about who are just getting introduced to TypeScript. So firstly, TypeScript is not something that you're forced to use with Angular because it works just as well with React or Vue or for that matter, any other third-party library or framework. Like I said in the previous slide, you're not really forced to choose any ES6 plus features or TypeScript because all those things are first-class citizens inside of TypeScript available to you. And just like all the newer language features that's coming up in ECMAScript, just like they get stripped down back to older versions of JavaScript, even the types, annotations that you will make in TypeScript get stripped away or rather called erased from the code that is generated inside of JavaScript. Lastly, you can use TypeScript in any environment that you use JavaScript today. So of course the web but also the also node or even mobile or native. It just works wherever JavaScript works. Also, I just wanted to leave this also in here to quickly let you know the things that TypeScript is not or the things that it does not intend to do. So it is not an academic language. It straddles a very fine balance between productivity and type safety. And all it intends to really do is to add a very strong, a very advanced type system on top of JavaScript and then it gets out of your way. Which means that if you're a professional JavaScript developer today, you can continue to build upon those skills and you can get started to take advantage of TypeScript's language features and you can be productive within a day or two at most. It's very simple and straightforward to get started with. To get started with it, you just need to install it like you would any other node module. And all these editors have first class support for TypeScript but Visual Studio Code which is also written in TypeScript has probably the best support so you should probably be checking that out first. Once you have the TypeScript compiler on your project, you can initialize a project with this command and when you do that, it spits out a TS-configure.json file which is the one single source of truth where you can configure everything about your project including opting in and out of ECMASTERX features. And you can have multiple copies of this. So in case you want to have a finer-grained control over how you want to structure your project, you can nest these files inside and you can change your settings according depending on what features you want to make available to different parts of your project. I guess that is it. So I was kind of low on slides and I have more things to show you in code. So let's begin with some examples and I have tons of them to show you here. Beginning with the simplest one which I think this is better, is this better? So this is an add function or so it seems because it takes in two arguments, A and B and it applies the plus operator to them. But the fact is that depending on the input types of A and B, the output of this function will vary. So if A and B are both numbers, the output will be numbers, yes, but if any of these is a string, for example, it actually becomes a concatenation function and the result will be a string, right? Let's see how we can express that fact inside of TypeScript. All I need to do is rename the JS file to .ts and when I do that, let me also give these things type annotations. So let me say that A and B are numbers. That's how you can specify the A and B and numbers in TypeScript and when you try to use this add function, it very helpfully tries to suggest to you that not only this function takes two arguments, but both of them have to be numbers and it's gonna be satisfied only when you give it the two numbers. Also, now because it knows that the result of this operation is a number, it has automatically inferred the return type of this function, so only the method applicable to numbers are available to you. So you could do this. If you wanted to try to pass it something that is not a number like this, it's gonna scream at you and it says that out explicitly that two is not assignable to a number, just do the string. By the way, in case you did not know, if you prefix a string in JavaScript and the plus or minus, it actually tries to coerce it to a number. Go figure, but TypeScript knows that. Similarly, we have a function called, I have a function called concat, which is different from the first one only in the terms of the second argument here. So it says the second argument B is actually a string. So that makes this function return a string and TypeScript is aware of that and so all the methods available to strings are available to me here as well. Remember I said it's easy to switch over or opt into new language features. So over here, I'm adding ES 2017 to it, like which came like some months ago, I guess. And when I do that and reload my project, this one onwards, the two methods introduced in ES 2017 are now available to me like this. It's that easy. All right, let's move on to something a little more advanced. Is it visible? All right, so I want to talk to you about interfaces. Interfaces in TypeScript let you describe the shape of your objects. They're like, they provide abstractions which act like a glue around which you can model some very complex type safe data structures and they also help unlock some very powerful design patterns. So let's see, here we have an object called blog post. It has a certain shape and structure to it. It has an ID property, a title, author and comments, which is an array. See the author itself is an object with a first and last name and comments is an array with author and body. You can note that the author object here and the author object in the blog post are the same. They're probably coming from the same data source. So I can express these relationships in TypeScript using interfaces that look like this. So I have an interface called post which has the ID title, author and comments properties. The author itself refers to an interface called author which has the first and last name and post comment is an array, which is again an interface which has the author and body properties and author of course refers to the same interface down there. Make sense? So I'm able to assert the fact that this object here actually conforms to the post interface. So it has all the properties from post except that doesn't quite because I can see an error here and the reason for that is that like I said the comments object is supposed to have both author and body properties and it is missing over here. So the moment I enter this back and comment it, it is available and from this point onwards, my code here is type safe. There's absolutely no bugs here in this piece of code. So which means that I can, and this is very type safe. So which means that if I change this body from a string to something else that is not a string like a Boolean is gonna complain again. All right and what this does is that it also enables some very powerful refactoring features inside of TypeScript. So from this point onwards, by the way, so these files could be spread across hundreds or thousands of files. It doesn't matter. If you wanted to rename your F name thing to more formally a first name, all the properties that refer to that, all the places where that first name is referred to get automatically refactored to the new name. That's amazing. Now I'll show you some methods that operate on these objects. So let's say I have a method called get full name which takes in an author and here I can annotate this object with the complex type that is author. And when I do that, let's sprint this thing and when I do that as well, I get autocomplete suggestions for the properties available on the author. So like this and this. Let me show you another example, a more complex one. So let's say I have a method function called get first commenter which can take in a post object and return the name of the first commenter on the post. So when I start doing that, I can inspect and see the things available to me on the complex object that is post. I can dig down deeper into comments because I'm looking for the first commenter, right? And it is an array because it shows all the methods available to arrays. I need the first commenter so I'll get the first element on that array and now I have the properties that are available to my comment which are author and body. I can dig further down and go as deeper as I want but I just wanna stop here because you'll notice that just up above I'm using the get full name function which kind of does the same I want to do at this point in time so I can just call get full name and this works again. The reason for that is that author here and the would get full name method here function here actually require author to be present. So the conditions are met and the code compiles. I'll actually show you how it runs to show you that it actually does work. I'll pass it the block post object that is up there. Run it. Is this visible? You see the first element grace hoppers name printed out there because that was the first commenter over here. So next I wanna show you some more features from the powerful type system available to us and over here I have an interface called player. It has some first name, last name scores and birthday properties and down there we have Tendulkar, who's a player? So he also has the same properties and these are his scores from the 1998 Sharjah Cup in the Australia New Zealand. Anybody old enough to remember that? So below that we have some other functions defined on the player object. So we have get full name as before get net score which actually sums up all the scores of the player and prints them out and age on the match day which is like the final day of the match of the series actually. So just wanna print out the players but age basically on that day and down here is the stats function that brings everything together to print out my series. Let's see what this prints first of all. So here we have Sachin Tendulkar his full name. He turned 25 the same day and he had a score of 435 throughout the tournament. He single handedly won us the match and the tournament by the way. So this is fine. This is great. Let's move on to Ganguly here because we also have Ganguly stats. Here we go. Up front we see that there's something wrong here and TechScript tells me what's the mistake because I have asserted in my post, sorry, in my player interface that birthdays are supposed to be dates but over here in Ganguly's case the birthday is actually a string. So of course we could change it here. We could fix it or even better still we can take advantage of what's called union types. So this birthday now means that my birthdays can be both of type date as well as string. So that satisfies the compiler for now and things look good except that down here I was assuming that birthdays are only dates so I could assume the get time method on the date object to be present but that's no longer the case because birthdays can be both dates as well as strings now. So I need to refactor this a bit and introduce another abstraction. So I have written this function differently so instead of passing the player I'm passing it the date object explicitly and I need to introduce another abstraction in the middle called I think get age, yeah, yeah. What it does is it actually checks if the player's birthday is a string type. If it is it converges it to a date using the date constructor otherwise it passes it on transparently. We also need to fix this thing down here now because we have replaced the abstraction with the get age function and let me replace the stats function with this one over here. Let's see if it works and it does. So we now also have sort of ganglis stats printed out there, awesome. But we also want to see how kumbe fared in that tournament which is like this. Again there's a problem over there let's see what it is. And here the problem is bigger because the statistician probably forgot to record his birthday at all. We don't have a birthday field for kumbe. So over here I want to introduce another feature of the TypeScript type system. It's called an optional property. So I've made the birthday property itself optional which means that you can have a string birthday or a date birthday or you may not have a birthday at all. Right, things apparently look good. So let's go ahead and print kumbe stats as well and let's see what we get. Well, no, boom. We get a crash and the reason for that is the reason for that is that over here I think it spoke about get time function over here. The time doesn't exist at all like this one. It doesn't exist at all in case of kumbe. So it's gonna crash. And I would have expected a strong type system a good type system to be able to catch these kind of errors. That's why I need to obtain to the strict mode of TypeScript which I had turned off to false by default. For you to be able to appreciate this more and I just reload my project and the moment I do that, it starts to show me more errors. Beginning with this one itself now. All right, so beginning with this one where now because I am expecting the age on match day method expects a date and the play dot birthday can be both a date as well as not available at all. So I need to refactor this as well which I do it this way. So I'm now explicitly checking if it is an instance of date and if it is, and if it is, I pass it along and if it is not, I should probably just turn something like not available or something, yeah? So that fixes one part of the bug but there's yet another and this one is slightly deeper. Over here, kumbe did not get to bat in the last two matches, unfortunately. So we don't have any scores to record for him but because now we are in the strict typing mode and we have a set that scores can be only numbers like an array of numbers. So we need to assure the type system that we are operating the right kind of data. And for that I want to introduce yet another instance of union types. So over here, I'm telling that the scores can be both numbers an array of both numbers or nulls. So here we are. So this gets fixed, but of course you'd expect that other things in the code will start to fail because over here, the reducer expects the scores to be available as numbers because now they can be nulls as well and it doesn't know what to reduce upon. So there is a simple way to fix that. Let me first give it an initial value of zero. So we begin our reduce function with a zero function, a zero value and we also assert that because we have initialized it as a zero, the aggregate or the value that keeps on getting summed up is a number as well. And now we have to deal with the score which can be both null as well as a proper value. So we just need to deal with this here. So in case it is a legal value that is not null, we keep it as it is, but if it is not, we use zero here. Make sense? And now if you print this out, everything should just work as it is. So you see at this point in time, my code is bug-free. I'm very sure of this fact that I have no mistakes in this piece of code. All right, I want to show you something else now, something a little more advanced, but I'll just briefly touch upon it. And they are generics. Anybody use them before? More strongly typed languages, yeah. So, generics are a very powerful programming construct and they help you write reusable abstractions. I'll show you by an example to make it more concrete. So here we have an ES6 map. And in this one, I'm setting it to a first, to a key value pair. The key is a number, the value is a string. And all right, so but there's nothing in JavaScript to prevent me from doing just the opposite, I could. I might as well set it a string too and a value of numeric too, right? Let's see how we can fix that and we can guarantee some more type safety in the kind of arguments that we can pass to it so that it's easier to deal with it, right? Otherwise you'll have to constantly check for the kind of data you're working upon and you have to make additional checks on it all the time. So we can make map generic by seeing this that the key can only be numbers and the values can only be strings. And the moment I do that, the second line starts to fail. Right? Prashant, can you increase the font size a little? Oh, sorry. Some of the people at the back are not here. All right, sure. Is this better? I don't want to increase it too much because I'll have to, but is it visible now? Cool? Similarly, we have the ES6 set, which looks like this and we can make it a generic as well so I can say that the set only accepts numbers. Yeah, fine. Set.add numbers, right? Everything good. But if I try to add anything else, there's not a number, so I can't say. It's very easy to write generics in your code so I think I have, yeah. So I have provided an implementation of generics I've taken a subset of the API available in the set interface. So I've added the add size here and delete functions and I've made it a generic. This is how you do it. You templateize it with something within these angular brackets and from this point onwards, whenever you instantiate it, you'll have to give it a concrete type of the kind of object that you're working upon. I'll show this to you with a more concrete example because I've written a test case here. So I have, wow, something's failing. All right, doesn't matter. I think I need to install Dave anyway, but yeah. So I have an interface called employee and it has a name and ID property. And so when I instantiate my simple set, I explicitly say that this set can only have instances of employee interface or employee objects. So from this point onwards, all the operations that I do will be type safe and they'll be restricted to the type of employee case and order, all right. I could show you that it works, but I guess you don't care. All right, so I think I have by now laid enough ground to be able to show you how you can do react in TypeScript. Sound interesting? So of course, you'll need to import the react module but there's a problem here. We are in TypeScript land and react was written in JavaScript. So what we need is a bridge between TypeScript and JavaScript and that bridge is called a type definition file. A type definition file is a collection of interfaces that describes the public API of the module that you're working with. So in case of react, what I'm looking for is a way to tell my TypeScript compiler that this is how the react API looks like. Let's see how we can do that. So there's a huge community effort around it called definitely typed. It's a repository that has over 3,500 type definitions that are maintained and created by the community and you need to plug one of these things if you want to use any module from JavaScript inside of your TypeScript projects. So how you can install them is this way. So when you install TypeScript, when you bring in react into your projects, you'll also have to install at types.react package. So this automatically pulls the type definition file for react as defined on definitely typed inside of your project. So there are some projects which are of course already written in TypeScript. For them, you don't need this because they're already first class citizens. But for react, you need to do this explicitly. And when you do that, and when you click on this one, you're actually taken to the type definition file of react. You can see it's a huge file, tons of interfaces and methods defined on them. And then most of these cases, if it is well maintained, yes, you also get a good amount of documentation around the interface, around the methods and the properties available to you inside of react. So this is also going to give you a complete intelligence whenever you try to use the react API inside of your own project. So now that once we have that in place, take a moment to see what's going on here. So this is how we define, declare a react component. And the more astute of you, we'll see that we're using something akin to generics here that we saw in the previous section. And you'd be right. So what we have here is that we've defined the interfaces for the components, props and state here and here, which we pass on as generics to the react component declaration. And when we do that, you can even begin to imagine the possibilities that then unlocks. When I try to access that this dot props from here, I get a type safe intelligence on the props that I have to define this component to have. I can't set it to any other props that are not already defined by the contract. Similarly for state, this dot state has something over here and this is what I get to see. As well as, so I have also this other component that I'm trying to compose from my main component. So this is called list item and has its own props over here. It has two properties, value and highlighted. I highlighted it as Boolean. So at the call site, when you're trying to use this component, when you're composing it, you also get intelligence for the props available to use for that component. So like this. And here, this is a Boolean, highlighted as a Boolean. So it is satisfied only if I pass it a Boolean. But if I try to pass it anything that is not, it's gonna complain again. Also, because over here, value is not an optional property. So if I omit it from passing it around to list item, it's gonna complain again. And let me show you something even cooler. So here we have, we are destructuring on this dot props, right? So when you inspect this, you get intelligence for all the properties available to you. And as you start using them, the list starts to shrink smaller and smaller. Of course, you can use the spread operator to store all of that in some other variable called other. So when you do that, when you get to see the three properties that are not values that has already been extracted. So I don't know about you, but the first time I saw this, my mind was blown. But there's one more thing. If you're a fan of inline size and react, you're in for a treat. I just want to show you something and leave it there. See what these are. And if I want to some text, some text property that had more intelligence that I wanted to value with, but let's just forget about it. Okay. So that was react. Next, I want to show you some more advanced features of the TypeScript type system and the language itself that can help you design better software. So here we have something called Mixins. One of the card rules of software design, a good design, is that you should prefer composition over inheritance, right? Everybody knows that. Mixins let you do just that. So they're kind of a higher order function that can dynamically modify the behavior of an object or a class they're working upon. So here I have an interface called animal with its methods defined eat and move methods on it. So here we have a class P line, the cat family that implements that animal. And so it also has to provide its own version of eat and move methods, right? Similarly, we have a bovine class, the cat or family, which also implements the animal interface and therefore it also has to provide its own implementation of eat and move methods. In fact, I want to take a moment here to show you the tooling around it. So let's say if I have another class called canine, the dog family, right? So when I do that, touch script can go ahead and give me some default implementation of the eat and move methods automatically. And when I try to use this, like this, not only the two methods are available to me, but if I want to define another one like this, which does not already exist, it can even go ahead and add it back to my class. One more thing, yeah. So for instance, if I, for any weird reason, I want to reduce the merge function from load dash and it's not already imported up here, it can even go ahead. No, I think I'm missing load dash right now. All right, so I think this is a good example of how live coding works. I install load dash as well as the types slash load dash because I also want the type definitions to come along with it. Let me see if I have it now or I just reload my project for a minute and see if anything works now. Yeah. Now I see an option to even import load dash, the module load dash, and all I need to do is this and I can start working with this thing. One more feature that I want to show you, which is great for quick refactorings, is this. So if you have a bunch of lines that you want to quickly refactor into a method of its own, you can select them and you can extract them into a private function of its own. And then from that, you can, of course, you can, you know, rename it or refactor it to your heart's content. All right, so back to, back to Mixins, right? So here I have some stuff going on. Let me just remove this piece of code. Some ceremony, which I'd recommend you to just ignore for now, but Mixins takes, Mixins take advantage of a very lesser known feature in ESX called class expressions, which looks like this, but I'll just suggest you ignore that and just focus on these two methods that are defined here. One is the outer function called moor, which has the move function defined inside of it. And similarly, we have rower, which has roar, we have meower, which has meow and hunter, which has move, okay? So let's see how we can make use of this. Over here, I'm mixing in the moor Mixin on my bovine class, which we defined up there. And then you do that. And when you instantiate that, you remember that we only had eat and move methods available to me, but because I'm mixing in the moor, I also have the move function on it. You see what we did there? Without even touching the original bovine class, we've added a new functionality, a new behavior to our class. Similarly, we have, we are mixing in the meower to the feline family. So we're making the cats go meow. And when you do that, we again get an additional method on it, courtesy of the meower Mixin. So that gives us the meow function available to us as well. And this is even more interesting because these are Mixins and they compose linearly. So you can have any number of them apply to on top of each other and the outermost will have precedence. So in case it defines a property or a method that is already existing in any of the inner ones, it will override that behavior. So here we have the feline, which can draw, so I'm kind of trying to make a lion, I guess. But I'm also mixing in with the hunter and hunter comes with its own version of the move function, right? So let's see what happens. Feline has the move function is daintily walking, right? We add this roar function to it so it can make, we can now roar. And now the hunter function, I think it's not visible over here, yeah. The lines doesn't just walk, it chases, right? And when I run this piece of code, I see that those changes have actually applied. What? I guess I left something there and I shouldn't have, fine, forget it. Just trust me that it works. Too much of life going. All right, so I want to come to my last example, which is also the most complex, but it tries to cover everything that, I wanna show you everything that we've covered so far. Just to wrap it up. And it's an exercise in design. So first I wanna show you this class, which is the basic player controller. What it does is it defines some crowd operations on the session storage. And so here we have the create, read, delete operations. And we have two utility methods called serialize and deserialize, which read data to inform the session storage. So they parse adjacent data coming in and out of it. So this thing works. This works pretty well, but it's so terribly designed for many reasons. For instance, we have here hard dependency on session storage, right? So in case you are interested in writing isomorphic apps, this is gonna bomb inside of Node because Node doesn't have session storage. All right, but even in case you want to make it reusable, or for instance, if you wanted to switch to using local storage, or you want to also have that facility available to do you tomorrow, this is absolutely not reusable and you have to rewrite the whole thing again. Thirdly, we have these utility methods here. They do their job, but the controller need not really be aware of how I'm massaging my data. It just needs to have the data available to it and it should just move on from there, right? So let's see how we can improve on this design using everything that we've learned so far. And the linchpin that makes it all possible is interfaces. In case I did not say it before, I'm gonna say it now. Interfaces are probably the biggest reason you should be using TypeScript. So we have a few interfaces defined here. The controller interface with the familiar crowd operations on it, a serializable interface with a serialized method, deserlizable with a deserlized method and storage provider with save, get, update and delete methods on it. So let's see how we can use all this knowledge to improve to write a better version of a player controller. So this player controller seems slightly longer in length, but it's so lightweight because it doesn't depend on anything concrete at all. I mean, it doesn't have a hard dependency on it. So we are seeing that the player controller implements the controller. It implements serializable and deserlizable. So that means that you have to have the create, read, update and delete methods defined on it as well as the serialize and deserlize methods that are coming from the other two interfaces. Over here also, we are doing dependency injection. So in the constructor itself, I'm asserting that I need to construct this controller. I need a concrete implementation of a storage provider. I don't care how it comes. All I need is to depend on the interface and not on a concrete implementation at all. So that means that I can, from this point onwards, assume that because I've been given something that is a storage provider, I can call methods on it like the save, get and the delete methods, right? And it becomes very flexible. Similarly, over here you'll see that I have let these serialize and deserlize methods unimplemented because I don't really care right now, but I'll show you how we can make these things available when we are actually composing the whole software together, the whole program together. All right, so let me show you an example of how we can implement a storage provider. So this is an implementation of the storage provider interface, so we have to have the save, get, update and delete methods. And over here, I'm not ashamed to depend, have a hard dependency on social session storage because there's a very specific implementation of a storage provider, right? All right, and similarly, I have yet another implementation of the storage provider which is a memory storage provider. So in case you're not to have an access to session storage, you can default back to this one. And over here, I'm replacing the session storage with an actual in-memory map, all right? So it has very similar interface and it has to have that because it has to implement the storage providers from the outside, it looks just the same, but inside it is dealing entirely on maps instead of the session storage, okay? Does it seem like it's getting somewhere? One more important point is the mix-in. So you remember that we had left the serialize and deserialize methods and our new improved player controller unimplemented? Let's see how this works. So I have two mix-ins, the serializer and the deserializer, which has concrete implementations of the JSON, Stringify and JSON parse methods. Let me just do them all together. This is where we do that. So over here, I take the base player controller, I mix in the serializer and the deserializer, mix-ins to it, and I get something called a serialized player controller, right? So at this point, even though I do not have any serializer or deserializer methods, we have them available at runtime using these mix-ins. Okay, the last piece of the puzzle is where it all comes alive. So I have a test here, right here, where we are initializing this and you remember that we promised that we need to pass in an instance of a storage provider when we construct the player controller, right? So that's what we are trying to do here. At this method, what it does is it tests if session storage is available. If it is, it immediately returns the session storage provider, the concrete implementation and if it is not present, it'll get an instance of the memory storage provider. Doesn't look cool. Let me show you how this actually works. So now, talking of isomorphic apps, this is as isomorphic as it gets. Let me show you how this works inside of Node first. I'm trying to run the tests. All right, so when I run the tests, we come here and we are in the middle of a, we have a debugger breakpoint and what do you expect the player controller to be provided as a storage provider? Remember we have the session storage and the memory storage. What do you expect over here? Memory, and that's what we have. We have an instance injected into it of the memory storage provider, which has, as you'd expect, one of the objects added already to it. So it has a size of one. The next step in our, the next, the very next step over here is something that deletes, tries to delete that entry. So if I go ahead and step over the next line, I would expect this to have gone. That's what happens. All right, so this is how it works in Node. Let's see how the same code, without changing a single line of code, will even work in the browser. So all the tests ran, they passed. Okay, let's go to the same point, the same line in the breakpoint. We have the same, how can I get rid of this? I've zoomed in in too much. All right, so here we are, the same exact same TS file and let me add a breakpoint over here and let me refresh this. All right, so now we are in browser land and what do you expect the lay controller to be injected with session storage, right? Let's see what we have near a session storage provider. All right, in fact, we can even go to the application tab and see that we indeed have an object created over here and the moment I go to the next line, we'd expect it to disappear as well. And it does isn't that cool? All right, so I guess that was a very breezy introduction to a lot of typescript in a very short time, but I hope I've shown you enough to convince you of the enormous value that you get out of using typescript. The larger your code base, the larger your teams, the more complex your projects, the more value you can derive out of using typescript. So I guess what else can I say? Let's go ahead and touch with other things. Thank you. Before we start with the questions, there's an announcement. Somebody left their Royal Enfield Bullet key in the parking lot. It's with the security guards. The bike number is KA51ER1581. If it's yours, please go take it from the security guard. And now we'll move to questions. Hi. Hello. Hi. So thanks for the nice presentation, but I had a lot of deja vu after seeing your presentation because I did a lot of work in GWT back in the day. And this seems like GWT. So in many ways, because it had static fact checking, it had tree shaking, it had generics and all that. And it was basically taking Java code and compiling it to JavaScript. So, but you know where GWT ended up. So it is good. The problem with GWT is I have to begin to answer your question. GWT is for Java developers who don't know how to write JavaScript. This is for JavaScript developers who want to up their game and start writing better JavaScript. But just one thing is, you know, I mean, if there is ES 2016, ES6, why would I invest in HypeScript? Yeah, like I showed on one of the slides earlier, you don't really have to make that choice because ES 2016, 17, 18 and everything that's going to come after that is going to be first class in the inside of JavaScript itself. So they intend to be fully compliant to the TS39 recommendations. So you are pretty much in safe hands. Don't worry about that. Gentleman in the same room. Hi, here. Great demo and it was very engaging and informative. I have one question. So this was a very small application that we showed of how to use TypeScript on the React site. Angular we all know. So let's see if I have to use it in my actual real world project. Have you used it in React? And if so, what are the problems we have seen of using TypeScript with React? Yeah, so TypeScript, the more recent version has started to shift with the JS compatibility mode, which means that you can incrementally migrate your existing code bases or legacy code bases to TypeScript. So you don't really need to go all out in at first. You can all the newer files that you write from this point onwards could be TypeScript. And you can also add something like a directive, directive at the top called TS check in your JavaScript files that also can begin to give you a good amount of intelligence even in your inside your JavaScript files. But anything that you see will work with the regular React but not with TypeScript with. No, there's nothing like that. It is fully compliant with JavaScript as we know today and tomorrow and also with JSX and also with JSX because of the type systems that they have. Sorry, JSX, of course. Yeah, I showed you JSX in full in school glory. Thank you so much. It sounds like you're going to have a lot of people coming up to talk to you later. All right, cool. Thank you. So it's break time. This is the flash talk sheet. Notice how empty it is. There's a man over there who has a flash talk so it's going to have one. Don't let him be the only flash talk this afternoon. Please come see me. I will be down where the coffee is because I've gotten word from my colleagues that the coffee is set up now. So if you want to find me for a flash talk, please find me down in the coffee area and I will remind you, please turn off your phones or at least turn them to mute. I heard a lot of notifications and I'm really glad you're popular but it's kind of irritating to everyone around you. That's it for announcements. We will be back at 1210 for the next of our talks on JavaScript alternatives. Shiva Kumar, please report here. Welcome back. Hope you had a great morning tea and yeah. So yesterday we heard a lot of complaints around screen visibility. You would like to get some feedback on is the screen visible today? Were you able to look at the slides properly?  Anything feedback? Yes. No better. Cool. Moving on. Please remember to put your phones on silent. It's slightly disrespectful to the speaker. If your phone rings in between, you start getting notifications messages, whatever let's put them on silent and if you need to take a call go outside the conference hall. The next talk is by Nihar Venugopal on reason reason is a new rapper on a venerable old functional language or camel with fantastic type inferences and a blazing fast compiler. It has trivial interoperability with JS code and yeah reason is worth a look guys. Nihar is a CTO at insider.in. So he would definitely know we're good to do this. Is everyone back after Chai Pani coffee? Everyone's feeling up for this or a cool. So my name is Nihar. Thanks Akshay for the intro. We're going to talk a little bit about something. That's a little bit on the bleeding edge, but at the same time is also really really old and it's reason. What are my objectives with this talk? My objectives with this talk is to convince all of you to write functional code are the objectives of my talk to make sure that all of you leave here as converts to the cult of the reason programming language actually not as you might have guessed from the title of my talk. I actually want to convert all of you into who was tank fans. How many of you have heard and the reason is you back in college my stated objective is really simple.  So let's go through what reason is reason is not a new programming language. That's a distinction. I want to make upfront very very clearly reason happens to be a new rapper a new syntax a new sort of tool chain around this slightly academic programming language called OCaml. How many of you have heard of OCaml? It's been around for a really really long time, but no one's ever used it for front-end development before, but there's been a couple of recent developments that have happened which have allowed this. Let's see what those are. So first of all, there wasn't very old programming language called camel, which a bunch of people sort of sitting in France decided to work on then it got changed into this language called camel light which had a bite code interpreter. It had a VM pretty straightforward stuff then it changed to camel special light which also had a compiler that could spit out native code and not just bite code for the VM and we all know compiling to native code was much faster, but then something very interesting happened along came this language built on top of all of this called OCaml and OCaml actually stands for objective camel and one of the thoughts behind it was what if we don't what if we take this functional language of camel and allow people to write some object oriented coordinate as well be a little bit more pragmatic. Let's not be sort of these priests of functional purity, right? So along came OCaml which lets you sort of dig into the imperative parts if you want to while still giving you all of the benefits of a statically typed a strongly typed functional programming language and then 20 years later there was this project that was open schools called Buckle script by Bloomberg and Buckle script is very interesting because Buckle script enabled this 25 year old programming language which could do all sorts of interesting things to actually emit JavaScript pretty neat, right? And then in 2017 Facebook open source reason and what reason essentially is is take the OCaml language. We can have it spit out JavaScript, but hang on this sort of 25 year old functional programming language.  We like the way our JavaScript is written. We like our brackets. We like seeing things in a certain way, right? So why don't we take this old functional programming language and make the syntax a little easier for JS devs to understand because that's always been the difficult part, right? We can bike shed indefinitely over this language has referential transparency. This language has why but at the end of the day if it looks like garbage, I'm not going to write in it. That's the truth. That's what it all boils down to. Does it look pretty enough for me? Does it look readable enough for me? So that's what reason does very simply OCaml can can spit out bytecode or it can spit out native code. We replace the OCaml compiler or the back end of the OCaml compiler with Buckle script, which takes the OCaml syntax constructs an abstract syntax tree out of it and then spits out bytecode native. We make it instead generate JavaScript. And then we update the syntax. So we've taken this old way of doing things and got a brand new way where you've got a functional programming language giving you JavaScript. But this is the how let's get into the why so reason and Buckle script are sort of evil twin sisters working in tandem together while you can use reason with other OCaml back ends as well. It's by far the best ways to use Buckle script because it's just amazing. So quick recap reason is a new syntax for a very old programming language OCaml. You can use both the entire JavaScript ecosystem as well as the OCaml ecosystem, right? You're talking about a 25 year old programming language in the plethora of libraries that have been developed for many many decades that you can use in your front end code or your server side code today and you're talking about the entire npm ecosystem. Bring those two together get functional sort of the advantages of a functional language and you get reason. Who remembers the chorus of the song? And the reason is you this is pretty much what it is, right?  So essentially that is what it is, right? I found a reason for me and blah, blah, blah. And what is the reason? Right? First of all, the reason is type safety. The reason you want to use a functional programming language or you want to use strongly type programming languages, you want type safety but I shan't did an excellent talk on type script and I'm pretty sure he sold you on types and how important they are for your front end development. Types aren't meant to make writing your initial code easy as far as we know types are meant to make your code easy to refactor. That's been the case always one of the biggest reasons why we haven't jumped into writing type so much is because it's so verbose writing it out. But reason solves that in a very intuitive way because it has a world-class type inference system. You actually need to write very few types with reason and we're going to see how that works. The reason is performance. One of the advantages that you get with having the compiler itself written in OCaml the compiler that converts reason into JavaScript is that it's actually compiled to native code. So you have a native binary which is compiling your functional language into your JavaScript code which is blazingly fast. In fact, some of the times when I run it on about say a few thousand lines of code you're looking at sub second compile times and this is not even in watch mode and for those of us who are used to you know, Babel and Webpack and just you know sort of staring at a computer screens while we go get a coffee while our build is running. This is a God said one of the other aspects of performance will also discuss is the fact that because of the deep static analysis the compiler can do it actually ends up emitting very optimized JavaScript. It's also pragmatic. Remember what I said that OCaml is objective camel. So if you as a JavaScript developer don't want to drink the school aid of I need to write functional code anywhere and everywhere, but you actually want to say you know what? I may not feel and I may not sleep well at night, but I do want to write some like hacky imperative code. Go ahead and do that. The compiler's got your back. It's also phenomenal tooling. We'll see some examples of that where one of the advantages of reason is it brings together several different tools from the OCaml ecosystem for you to get a great type system. Great editor integration and stuff like that. It's also interop for any compiled to JavaScript language. One of the most important things has to be what wait. I already have an existing project. How do I sort of use this new goodness with my existing code right and one of the ways that you end up being able to do that is because reason gives you a way to interop with your existing JavaScript code. And all of this put together ends up giving you really good developer experience. One of the biggest points that I want you to take away from this entire talk is that if you use reason, you will be more productive while at the same time not sacrificing any of the developer experience that you're accustomed to. So let's go through the type system in a bit more detail. I won't go into it as much detail as sort of the type script talk because there's a lot more to talk about here as well. Firstly, it's sound. What do you mean by a sound type system? It simply means that you're not the compiler when it's sort of checking your types. It's not trying its best. If the compiler says that your program compiled successfully, all the type checks have passed. It is bug free. You've covered everything. It's sound. It is not going to make a mistake. It's inferred which means a lot of common patterns that you'd see in other sort of languages with types where you explicitly have to write a lot of types. You don't need to do that in reason. The compiler is sort of almost like a pair programmer with you and it automatically infers a lot of very interesting things. There's 100% coverage. So if you ever used flow or type script, you also have to that's the term that we use in reason which is strongly type. So you define your record type over here. I'm saying type talk has a title and a length now. Usually what you would assume is that if you had to write any functions that deal with this type or if you had to write any code that deals with this type everywhere in your code, you would have to say, okay, this thing that I'm doing, it's of type talk, right? You don't need to do that in reason. You just write it just like you would any other just object. It automatically looks at the shape of your object and figures out that the type it corresponds to is talk. That's it. You don't have to annotate it at all. And this is beautiful. This is the way it should be, right? Why should we sort of obviously there are a few edge cases with this where if you have types which are very similar, you still need to annotate it. But in my experience, the vast majority of code that you're writing, the compiler just gets out of the way. And let's say you write a function. So here I have a really simple function called trim talk length. Now look at the syntax. How many of you think this looks very similar to JavaScript? The function is equal to it. Just we've just used f u n instead of function, right? That's about it and I'm doing a spread operator over here and there's no return statement because in the functional language, everything is an expression. The last line is your return statement, right? And look at the type signature of this function. It's automatically inferred without me annotating a single thing that this takes in a talk, a value of type talk modifies it slightly and returns it. So you get all the goodness of types that we saw in the earlier talk and we generally know types are good for us without the verbosity of writing it out, which is the holy grail. Let's look at something interesting that is born out of the type system and other interesting things in the language pattern matching. How much of a JavaScript code ends up being switches and offenses pretty much most of it, right? Any conditional branching logic that we need to do it ends up being that how can we have the compiler help us with that? So this is a pretty simple recursive factorial function. This is how most of us learned. It's really bad way to write it because you'll get a stack overflow, but still this is how you'll do a recursive function here. I've used a slightly different syntax, which is a little just to sort of illustrate that there are two ways to write functions in reason. So here this is the name of the function. This is the this is the value that we're passing notation to write it. You can also write it in the more JavaScript similar way. If you feel more comfortable with that again, it's completely up to you and here I switch the value, right? And I say if it's zero return one, if it's n to n into factorial n minus one pretty straightforward. This is how you do a simple factorial function. How does the compiler help us with this? What if I forget the case where if it's n multiply n into factorial n minus one, right? I get a warning here. Okay, fair enough. Maybe the compiler can figure out that there's something wrong with the switch that you're doing. And remember here we're switching on the value of the thing that we're passing into the function, but here's what's really cool when you run this, right? The warning that the compiler gives you is not that there's something wrong with your program. This is the part that I want to highlight the compiler actually tells you you forgot to handle a possible value here for example one. It's actually giving you a value that you can input into your function which you haven't covered in your code. This is literally the example of someone sitting next to you and saying bro, you forgot in this case. This is what compilers are meant to do, but somewhere along the line they became these monstrosities that only serve very obscure error messages, right? The first time I saw this it blew my mind and I was like agile what where program what I just need a really good compiler, right? So pattern matching is cool, right? You know what's cooler is pattern matching with types. What if we can take these types and we can do interesting things with pattern matching with them? Here's a slightly this is an example from a thing that I've been working on it's a little verbose but where with me so huge line of amount of code will go through it very quickly. The first is I have a simple phone number right which says that I can have three types of phone numbers. There is no phone number. There's a phone number stored in the international e164 format which is just a string plus 9 1 something something something or in some legacy system of ours we actually stored country code and phone number separately. All of us have been in this situation.  You have to write a huge amount of if I says to handle all of this. So what do we do here? We define a type right? This is known as a variant and we say that our phone number can be none or this or this and the two sort of inputs that you see to the variant are called this is like a constructor. We're saying that e164 takes in a string does something with it. The legacy phone number takes an int and a float and does something with it. So here I'm just going to define the three new phone number just takes in a string legacy phone number takes an int and a float because it's going to be pretty big and no phone number is just none right? It's just that this person doesn't have a phone number now we let's say you need to write a function to format this phone number right and displayed very nicely to the user in a standardized way. This is how I'd write something like this. We switch on the value or we switch on the type and we say when it's when he doesn't have a phone number we send him a really nice message when he has the legacy one if you notice we are able to take the intent of load that we are passing to legacy format and rename them as prefix and number so we can we can have nice looking names there as well string of it is a very simple function to convert string to an end and string to float and this is how we end up formatting the whole thing and if it's e164 it's already a string just display that as is we log it this is what the output looks like right this pretty cool we've just taken a bunch of our if else logic written it a bit more concisely that's nice not too different from javascript. How can the compiler help us imagine I remove the case where I don't handle the case where there is no phone number here the compiler really gonna tell you forgot to handle a possible value when there is no phone that's it now I know that I need to sort of handle that case as well. Why is this useful as well for refactoring imagine tomorrow your back-end comes to you and says we have decided on our own custom in-house phone number because we know better than the rest of the world right we all work with back-end like that and that they come up with a brand new spanking format which is unlike anything anyone has ever seen right now you need to handle that case everywhere in your code how do you do that you just have to update your initial type definition for phone number the compiler will tell you every single place whether that's format phone number whether that is add phone number whether that is take phone number and display it in emoji whatever are the functions that you've written the compiler knows all those places it will tell you that you haven't handled this new format right we need now let's get into performance really quickly so one of the obvious things that I talked about is how fast it is also because it's able to do a lot of very complex static analysis it does dead code elimination and more importantly it pulls in very very little runtime most compiled to JS languages to prevent to preserve the semantics of the original language pool in a huge amount of runtime JavaScript to sort of keep the environment the same but one of the reasons that reason was invented see what I live there is the fact that OCaml and JavaScript in a lot of cases have a one is to one similarity right whether that switches whether that's objects whether that's arrays whether that's like binding so in a lot of places you're able to very simply translate things over without needing to pull in any of the runtime let's take a look at how that looks I'm looking at our factorial function again the similar one that we saw earlier when I compile this what does the output look like as a compiler if any of you are doing and this is the output but hang on a second I just sold you on how there's minimal runtime but why is the code so big right does anyone know just doesn't have integers right so we're still when it compiles that code it wraps all of that code with sort of integer multiplication and stuff like that to preserve the semantics of integer code right so it ensures that safety but what if you were to rewrite our factorial function using floats because JavaScript only has floats right so I've done a bunch of float operations over here you just have to annotate it with a dot your multiplication and negation or whatever this is the compiled output if you remove the top comment and the bottom comment I can guarantee to you none of you would realize this has been spat out by a compiler this is exactly like any of us would write the code right and this scales to thousands of lines of code not just a simple factorial example so one of the biggest selling points of reason and on the coolest things about it is that you don't have to treat the compiled JavaScript as some sort of build artifact write your code in reason let it spit out JavaScript check the JavaScript into your source folder and have the other people in your team who don't know functional languages use that JavaScript because they can look at this file and understand what it is without knowing to know reason and understand that so this makes it very easy in large teams for you to start adopting it incrementally right I mean this first time just like what the hell is going on right all right it's also very pragmatic in terms of it gives you a lot of escape hatches to interrupt with JavaScript to write imperative code I'm going to skip over some of this stuff because it's a little dense and also because we have a lack of time because there's one very important thing I want to talk about right how do you do interrupt pretty straightforward if you want to use reason from your existing JavaScript just compile reason to JavaScript use it if you want to use existing JavaScript in your reason code you basically have to summon the old gods perform an arcane ritual and sort of pray for the best but essentially there's a way to do it using something as a foreign function interface one quick note about reason is that it was invented or put together by Jordan walk who is also the inventor of react when originally react was written it was written in language called sml but they very quickly realized that react wouldn't be adopted very widely if it was written in obscure ml language so it was converted into or you could write it in JavaScript but now we have the tooling with buckle script and stuff like that to actually use react the way the authors of it originally intended which is using reason ml so it's the same team that's built both so if you're getting into react development I definitely check out reason react it has a beautiful api which you can sort of quickly see here where everything is sort of pure functions to be able to do it and that's something that you can dive into right this is ffi which is how do you deal with existing JavaScript this looks super historic and complicated but what I want to point out to you is this is the just if that's generated right reason doesn't understand what document is or what get element by ideas but you can write an interface that compiles to this JavaScript which again looks completely handwritten right pretty cool. Now the thing that I'm most excited about for reason is not the fact that I can write type safe pattern matching I can do all these cool things today the reason I'm most excited about it is the future what happens so currently this is how reason works right? We compile to JavaScript which we can run in a browser we can run it and note but remember at the very beginning of my talk I said that OCaml has a brilliant native compile to native sort of process as well and the Buckle script compiler itself is all is also written in native code so what if we could take the reason compiler or the OCaml compiler and have it on the server side generate a binary for us imagine you're writing isomorphic web applications where you're sending client side JavaScript but your server isn't absolutely completely optimized tiny binary OCaml code when compiled to native I have seen servers that start up in six milliseconds right imagine the kind of performance we can get out of that and imagine the future where the same compiler is giving you binary for the front end and binary for your server so you write type safe code which compiles to JavaScript if you so feel like it or actually compiles to all of the possible places it can be deployed in binary basically what I'm trying to tell you is we have reinvented Java after all these years right once run anywhere except not in bytecode but in binary there are still a few things left for wasm to be ready there's a garbage collection and tail called recursion optimization stuff like that left but we're very very close to this and we as JavaScript developers now have access to writing code in a functional language where the types are inferred for you where the syntax isn't that different and feels familiar to us and to actually deploy native code right you don't have to feel like the rust guys of the C++ guys are better anymore or doing some sort of restoring magic right we can do this and that's why most I'm most excited for reason that was my talk couple of quick shoutouts to a few friends uncle and Sanders fees from Twitter for helping me with feedback from this and thanks to the organizers and all of you for listening to this and I hope I've got the song stuck in you in your head and I hope I've given you a reason to try out reason thank you so much for just one question which is can the question just not be on the patents the act reason. Yes, right and it gets compiled to like drama. Let's say you get a run time error correct so how do I accept that error back into reason code? How good is it that there's a couple of there's a couple of things there if you ever if because of the fact that your code is strongly typed if it's going to be entirely reason code you're not going to get a runtime error that's just not going to happen if you ever written code or any of that sort you just don't get runtime error because you've covered every single possible case as long as you model your types correctly right and you say that this value can not be present as well you will never get undefined is not a function you will forget that phrase even existed right but if you do end up getting a runtime error because you're mixing your strongly typed reason code with sort of some of your untyped JavaScript code because of the nature of how reason compiles to JavaScript right and it doesn't spit out sort of code that looks very obscured stuff like that in my practical experience is very easy to go back and just do a one is to one mapping because I know exactly where this is come from because it looks very similar because the variable names are preserved firstly right the file names are also exactly preserved and it even tries to make sure that you know if you're if you're using a particular data structure try to preserve the same data structure and the compiled code also has extensive comments on what is the equivalent name of the thing in reason so it becomes pretty easy for you to figure out what where did it come from thank you thank you okay any other questions happy to meet you guys outside come fight me on this thank you we announced in the morning that we are going to be looking at three alternative languages which are coming up in place of JavaScript we learned about typescript then we had reason which is based on OCaml and the third language is pure script we have Vimal with us who's the CEO of just pay and they build and maintain large scale payment apps he will talk a bit more about the framework they've built and then dive into rationale for choosing pure script as their language a quick intro about myself I love for the front end and business logic came after I got introduced to this and Closure so I've been programming in Closure for five to seven years and the real art of the form of code and introduction to functional programming for me happened through Closure so this talk is about some of the things that we have learned over the last five years in just pay so the biggest problem in a company like us is so so managing managing the ever increasing complexity of like a lot of vertical solutions if you look at a company like us we power payments for most of the top large enterprise companies and that needs a lot of vertical solutions we call ourselves a micro app platform so we are a small app inside many other apps like Flipkart Amazon make my book my show etc etc and all these need customization and ability to manage and control complexity and we also develop apps like beam which many of you might be aware of UPI app and how a company which is a small company which is almost running like a bootstrap company like us can actually manage such kind of large complex apps with a very small and young team and half of our company is composed of almost pressures and interns so this is the problem that I wanted to kind of attack head on right how do I get like 100 interns and like give the kind of experience that I built over 10 years in one year so this was a very very exciting problem that I wanted to address and being a closure programmer my immediate approach was like pushing for closure right and you guys get into arts like closure is like the art of programming and once you get it you are going to become amazing programmer and the whole conflict of closure versus Haskell and but my team wanted Haskell and how did we end up into Haskell and pure script in fact so that is that is going to be the story of my talk and focused on the kind of apps that we have been building and the learnings so let's start with why are apps hard so this is something very experientially that we have figured out that most of the models which are in the industry are not suitable for transactional apps most of the most of the apps that you use right 80% or 90% of those apps are transactional take a flip cut after you have done your search the rest of them your conversion funnel take a payments app it's a conversion funnel take even a travel app most of the parts is like the entire product team is thinking about conversions right the even based model is not something suitable for modeling the conversion funnel or modeling the modeling the user experience of a flow or a business business logic right just not that even if you make a DSL in a language like JavaScript and like have mashed it up through like a JSON like structure and create a workflow there are lots of workflow systems which tried to model the business logic but they are not composable so the whole point of like taking your business logic as reusable building blocks and putting them together is not is not at all solved in the industry the second thing I think I think all of you relate to this and this I since I have had the experience of the early days of how system engineering works and how deep it was compared to how the JavaScript ecosystem works it feels a lot to me like a pop culture everything is like getting started first like how do I get that excitement today and like the next week it's going to be something else right so there is no focus on really looking at going deep and investing time in going deep and learning the fundamentals and kind of looking at really the ever increasing complexity that we are getting and decreasing the complication so complexity is good the world moves towards complexity but the thing is the complication is moving like multiple times forward than the amount of complexity that is going on right that that we need to control so there is no theoretical approach except for let's say if you can get into Haskell you can really get there but there is no path towards getting into Haskell so this is something that we wanted to solve the third thing is kind of related to my previous point there is a lot of fragmentation what we see is that most of the things like front end back end persistence services integration analytics infrastructure all these can be unified with very few primitives and the focus of the mathematicians are the ones who think like this right look at lots of things around the world and say like all these are nothing but numbers all these are nothing but changes this is nothing but calculus will model everything right such an approach is not there so we wanted to bring that to the industry and make it practical so yes so these problems are there and as I said we took on a mission saying the me being a technology person and also business and the product guy I always see all of them as the same thing and why can't we unify why can't product managers designers and technology people work together and all of them can understand the code if we make that happen we can really make it 10x better right so how do we end up solving it we focused on user experience or UX as the primary abstraction that we wanted to extract there are lots of ways in which you can abstract things out but like we wanted user experience is something that developers relate to product managers relate to designers relate to so how do we get something as designer type as user experience and merge it with the math of Haskell and like make it practical right and a product managers are extremely interested in conversion funnels and business flows we wanted to model as gold gold trees which I will get to and we wanted to get into your script or a dialect of Haskell which is based a lot on category theory and make it practical and as I said how do we unify and figure out the building blocks and there are only three building blocks I'm going to get into the details of this so what is meant by UX as conversational flows so imagine any app an app is nothing but somebody who is sitting in the middle between a system and a user and just doing a conversation imagine an app in which you can just say like okay welcome the user tell the user this ask the user for these things thank the user delight the user crosses this to the user notified to the user sounds very familiar right anybody a non-tech person will be able to understand so this is the primary abstraction that we wanted to anchor on for app development that use user experience becoming the vocabulary for our framework right so the other side of the equation is like the language to talk to the system like while talking to the system we talk about like okay detect whether there is a sim present in the phone so there is like verbs and nouns which again relate to a normal person which we can create and make it a DSL and make it very very intuitive right the next is even after you create a DSL or a domain specific language the next thing is to how do we kind of make them into modules and make them composable so it's easy to come up with a flowchart like approach or a or a way in which you can write like a long essay and but but the thing is it goes out of control or program will become like big big narratives which are not reusable so that's where the problem of problems that functional programming really really addresses come into picture so for us to really make the UX or the UX DSL and the system DSL as a narrative at the same time make them into Lego blocks and compose as a hierarchy right needs us to solve state management it needs us to solve control flow control flow like how you kind of do asynchronous computing versus error try catch etc versus like retries etc making them all as like very intuitive modular I would say annotations that you can put in your DSL and anybody should be able to understand right that's where functional programming shines and we were able to create a flow monad how many of you know about monads heard about monads right so that's the scary M term so what we have really done here is like we have created a custom monad which which actually models the flow structure and state and and and also how do you kind of mash up the computations together it's called a continuation monad which you can email me I will I want to take a separate lecture on it sometime right and if you look at this slide take something like for app like beam for onboarding it's very easy to think like okay onboarding is composed of maybe an introduction then mobile verification and creating a virtual private address understandable right and introduction is composed of like maybe three screens three welcome screens three welcome screen and like help screen couple of help screens mobile verification is composed of two types of verification one is like by sending an OTP and verifying but if some of them SMS is not reaching then like there is another way of like sending one SMS from the phone right so this is like two goals and this is like this or this if you look at the first set of goals is like introduction and verification and create VPA in verify mobile it is a goal a which is like verify mobile with OTP or verify mobile sending SMS and again verify mobile with OTP is composed of a UI goal versus API goal versus a module which is like a poll and wait for the OTP etc. right so if you look at this anybody our product managers understand and even people whom is not introduced to this way of programming understand so how can we make something which is as intuitive as this and as composable in fact the interesting part is I can take parts of this and put it between different apps like the UI is completely abstracted out of this and like lots of different solutions that we built in our company use the same code and that's the that's the beauty even base programming model will not allow us to reuse all the components which are like spread out like spaghetti right this is extremely tight. I can hold my UPI onboarding goal and have it everything is like tightly composed right. I can take this thing and like take it out put it back in so that's the beauty of it and things like retries etc. very hierarchically handled like a retry within mobile verification will happen inside that itself if it doesn't happen it will go to the parent and that will have a strategy for retry all of that becomes extremely we have a formal way of doing all this still being very very practical and user friendly so this is another way of looking at the same goal tree which is looking like a narrative welcome ask and ask is this ask which is a goal tree or a function which is composed of couple of other things etc. and the subflow this is again another sub function which is being called which is I think when you look at the slide it is pretty intuitive and the code exactly looks like that this is what we were able to achieve. So so the the story behind how we entered here is as a product guy I was actually one year before really looking for this and I was starting to write closure macros and like going to my team saying hey guys I want something like this learn closure I I want the shape of code to be like this right and we ended up into Haskell which the next slide is in a few slides. I'm gonna go to but the interesting thing is we are actually this is embedding things like monads alternative operators types and all in fact types and functional programming has been the theme today right and I am going to again be the strong advocate of the same philosophy of the previous talks and the beauty is it is giving you something like this and it's again fully typed pure script is fully typed and a small mistake it will catch it. Yeah, so that that is about talked about pure script. In fact, most of the talks before have been covering many of the good parts the one thing that I want to cover maybe which is unique here is like the the model of programming we chose something called continuation passing style this is again something that scheme and list and all have been having it Haskell also has it by the way a quick intuition for continuation is nothing but taking computation blocks and having the ability to control the control flow right having something like a function returns a promise but the way in which you resolve that promise looks like it's a synchronous call rather than making it look like a synchronous call which if you really look at it in this code I am doing a show UI which is like a UI screen is shown and the return value of that is what the user entered which is being piped into my API which is being piped into my another UI and so on right and if I can show you a little bit more code here like this code has a little bit more complex thing where I am showing a UI and like it is the return value of the UI I got it as a user choice and I am able to kind of look at all the different types of user choice and handle it and like why fork it the flow into few other part the lower parts of the gold right cool. So we looked at our DSL and why functional programming the third is in app development itself using all these theory and the tools we still need to unify we need to actually think creatively about what are the commonness in fact for us the inspiration for that came from just going into category the level at which mathematicians are thinking if we put that kind of a thought if you bring that culture we started thinking why not find commonness between everything and unify what we ended up doing is just say that app is nothing but three kinds of building blocks one which is obvious which the react world has done it which is the UI structure being like a like a hierarchy and like clearly taken as a bunch of components that we can make and reuse the thing that we really innovated on is the goal tree which I talked about the third building block is data as types in fact algebraic data types and all the great things that you heard your script also has it. So in fact what we have achieved here is make all the make something like maybe there is a directory structure in your app which actually puts up all kinds of types you are all your interfaces all your data models everything is algebra algebraic types and like don't repeat don't copy between types your entire back and front end everything is unified and they are all captured in the same set of types because we control our front end and back and we are able to do similarly the goal trees also the back end is nothing but extension of the goal tree. So why do we need a concept called back end so that is what in our company we do like there is no back end you just has have flows or goal trees the code which runs in the front end will have effects in which it can manage the UI etc the one which runs in the server can maybe manage your red is database etc it's just like the difference in a little bit of effects but like it's just extension of your the DSL or the code that I showed in fact you can call one function there which will run in the back end and your concept of API is back end front end everything is gone right. So why pure script so this is in fact a big debate and still we do sometimes debate here I really like closure but given that we are a team in which we have like 100 people who are like almost precious closure needed or list needed a lot of experience from other fields in my opinion maybe there are great musicians there would be great closure programmers they would have understood the world through many other ways and closure is like a canvas in which you can make whatever you want it's like clay right rather Haskell has a math approach maybe initially it is like a little bit of a path of thorns but if you can cross certain level right I think you can so what I was looking for is like what am I maybe learned from my Bach music right is there a way in which programming itself is there a path Haskell has path it has like something like okay this is how you learn calculus in your school this is how you learn your tables there is a path closure I was wasn't able to find a path closure was like art school this is like the math school right so we were able to put it to practice and make it into a math school and the architecture wise considering we are a very transactional system and not like a game kind of system Elma arc