 So I'm here to talk about asynchronous JavaScript patterns, this is going to be the most boring presentation because I'm going to just keep reading from the slides. I'm joking, why would I do that? Anyway, so I'm talking about this because I have been a client-side developer for almost all of my career. Unlike the Ranjay, I have not been a polyglot, I have been a one-track pony. So that's the only thing I can do, I can only write JavaScript, that's all I can do. But being a client-side developer and I've lived through all of the cycles that he was talking about, so I was sort of feeling all the nostalgic and stuff. But romantic times with Dojo and Prototype and stuff like that. Finally the hatred that I have for Jack very, I hate Jack very, but that's just me. And then Node comes along and then Node changes. Suddenly there's this mind-share that Node gets, which clients at JavaScript did not get. There was just not enough smart people, people like me doing clients at JavaScript. Not enough smart people doing clients at JavaScript. So there had to be something big that happened in JavaScript and Node was that, where then people could then jump in with ideas about how to make things better. And that has sort of started influencing client-side development as well. So what I'm talking about is about how to deal with async patterns and how sort of Node has taught the client-side how to do async patterns well. And that's roughly the talk, the summary of the talk. About me, already Kiran's made the pitch, I didn't have to do this. I've been doing JavaScript for about nine plus years. Sadly that's almost like 80% of the lifetime which I was doing it itself, that's pretty sad. And I've been doing that for so long. I'm obsessed with clean code. I take a lot of pride in my code being clean. And I like robots. I've not been able to add lasers to them yet, but I've been able to work with robots, it's good fun. We should check up later if you want about how we can build robots with JavaScript. I'll be in fact showing this off at JSFOO in Bangalore, so maybe if anyone is coming along there then we could have a look at that. Have you put a robot on a shark yet? No, not a robot on a shark yet. But I'm thinking of putting a cat that could fly. So I want to sort of backtrack and I know that I've just done this as well. But I want to just step back and go over a couple of points really quick before I jump into Async. And the first thing I want to talk about is JavaScript itself, JavaScript the language. So JavaScript is a very small language. And by small I mean the amount of keywords, the amount of constructs, the amount of syntax you have to deal with, stuff like that. It's a rather small language. There are languages that are much, much faster than JavaScript in terms of its keywords and constructs, but JavaScript is not that very small. Contrary to popular belief, JavaScript is actually a sequential programming language. A lot of people think it's an asynchronous programming language. There's nothing about JavaScript that makes it asynchronous. This is a controversial statement because everybody else seems to think that JavaScript is asynchronous. It is not. It's a synchronous programming language. It goes, you know, statement after statement after statement. That's how it works. And doing that, you know, there's nothing else that can do that. That's how JavaScript works, right? So it's a single thread. It's single thread. And there is no multi-pressing at all. There is no multi-pressing at all. It's a small language. Let's just say that's the beauty of it, right? The only time when, of course, it does not go sequentially is when something breaks the control flow and that would be something like, you know, an if statement or a for loop or, you know, a function call or something. It was just as you would expect in any typical language. So that is, that is how JavaScript is. It's not very hard to understand. In fact, it's comparable to anything else like, you know, Python or what have you in terms of the flow of code, right? It just flows from top to bottom unless there is somewhere to branch out that. So, you know, yeah, so control flow could break the sequence. This is a very popular photograph. I don't know if you guys have seen this JavaScript, the definitive guide, which is the fact book at the bottom. JavaScript, the good parts. I will admit JavaScript is not very, not very, you know, cool. But then, fortunately, there is also a Brenda Mike, who is our Messiah, the creator of JavaScript. He also fortunately has a very good sense of humor. So at the top that he was giving recently, he put up a slide as a joke to counter this and to counter Douglas Crawford. He put up a slide saying JavaScript the best parts, right? And so this is what he listed out. And he said that, you know, this is what JavaScript is, basically three bullet points. That's all that is required to make JavaScript work. And that's the only thing exciting about JavaScript, right? And so functions as first class objects, closures and prototypical inheritance. I will not be diving into closures and prototypical inheritance. Already, you know, he's gone over prototypical inheritance in some amount already. But I will be looking at functions in some amount of detail. Though, you know, I don't think half an hour I'll be able to justice to it. I can count at least seven different ways of using functions in JavaScript. Functions are very, very powerful in JavaScript. But before we come to that, remember I told you JavaScript is sequential. It is the host environment that JavaScript is running in. I want to distinguish the two, right? There is the language and then there is the environment that the language runs in. The environment that the language runs in is usually interesting with JavaScript if it has an event loop. Though it is not necessary for the host environment to have an event loop, right? So most interesting host environments, for example, the browser and Node.js which are the two most popular environments for JavaScript actually have an event loop in them. That's what makes JavaScript interesting in those places. Though, of course, it's not necessary. You know, JAXER used to be a programming language that was a programming environment that had JavaScript as its host. I've actually programmed in this on, you know, printing something that never really took off. But that did not have an event loop working in it. You can also script Photoshop if you didn't know. And, you know, Vishal who was supposed to be with us today but had to go on a personal engagement. That guy is doing some crazy stuff with his Photoshop. He scripted the... I should not be using these words here. But he scripted that thing very, very well. To the extent that he can save something in his editor and then that will update something in Photoshop, cut that up into images which then will be exported onto his file system and then cause a browser reload to happen just by hitting save in his editor. So he's just scripted this thing out so beautifully. It's amazing. I hope that we could... He's coming down to Bangalore again because he pitched a reception for me, I'm going to pitch Bangalore for him. So he's coming down to Bangalore so you should probably catch him if you can. Vishal, Vishal. Alright, so... Alright, let me talk about one more thing. Now, a lot of people mistakenly think that set time... Everyone's familiar with set time what I'm sure. A lot of people think set time out is something that JavaScript gives them. It is not. Set time out is something that the host environment gives them. It's actually the browser that is providing set time out. JavaScript does not because set time out has to work with the event loop whereas JavaScript is not aware of the event loop. There is no such concept of an event loop in JavaScript. It's the browser that's providing it. So set time out is an example that is so intertwined with JavaScript because we're so used to it in the browser that we think it's part of JavaScript. So set time out has something that has to do with the event loop. Now, you know, I'm sure you could probably figure out what this code does. It prints hello, it waits for five seconds and then it prints word. Right, and we could probably just give it a spin right here. If this works. Right, so it says hello, waits for a little time. And then word. Right, so... Now, this is expected. What I want to impress upon you though is the fact that by calling set time out what I have done is I have essentially passed this block of code, that function that says word. I have pasted this block of code and I have told it to put this code on the event loop to be executed five seconds later to roughly, you know, this is not absolutely accurate but roughly speaking this is what I'm doing. Right, so I'm saying take this block of code which is power number one of JavaScript. You are passing it blocks of code as opposed to passing it strings or numbers or whatever. You're passing it blocks of code and you're telling it take this and put this on the event loop to be run five seconds later. Now, it does not actually go out to the event loop right now because your code is executing sequentially so your processor is busy. It's going sequentially. It does not actually go out to the event loop. It's after it alerts hello, does it then go to the event loop, it builds it over there, waits for five seconds and then comes back, right? With me so far, lost, okay? Why after alerts hello, does it go to the event loop? Sorry? If it goes sequentially, the set time out should happen first and then... Right, but it has to go out to the event loop. So it depends on environments and in most environments what happens is that since it has to go out to the event loop that process is also scheduled on the event loop itself. So in this case it has to wait for five seconds so that process is actually scheduled on the event loop for that to happen. So an easy way to test this is for example, let's say you want to make an AJAX call and AJAX call is something that has to go to an event loop, right? So you, let's say, fire off an AJAX call and then you keep the browser stuck for some time. Just keep it in a loop. You will see the AJAX call does not even reach your server because it does not actually schedule on the event loop yet. It's when your event loop is free, when your JavaScript runtime is not doing anything is when it will actually get time to play with the event loop. So that's how the browser is sort of marrying the runtime and the language, right? You see essentially the yield is co-operative. Yes, yes, yes, roughly, yes. Or probably you are saying that you are not saying that execute this after five seconds. You are saying that try to execute this after five seconds if you are free. Yes, yes, absolutely. So there is no guarantee obviously that after five seconds it will be free. It could just be that your event loopers or your JavaScript runtime has caught the process and is not letting the process yield. So essentially it does not interrupt in the middle of anything. Right, right, right. Okay, so there are couple of people here who seem to have understood under the rest. Still good? Cool. So the lack of interruptions also means that globals are in the problem for events. In a sense, the fact that you have global state doesn't really come back and hurt you with something like this. Yeah, I mean this would not have anything to do with globals at all. Well, another example is that what if I make this zero? Now I figure it out. You have tap disabled but never mind. Okay, so let's say I make this zero which essentially is saying that set time on zero which says execute this immediately because the delay is now made zero. Execute this immediately. But even then when I run this you will say that print's hello first. Why doesn't do that when I have told it to execute word immediately? It's because it has to go on to the event. Execute this when you are free. Exactly, exactly. So that's why that happens. So, you know, with me so far? Alright. So why is this exciting? Everybody seems to be crazy about the event. Why is this exciting? First of all, this is perfect for you guys. In fact, maybe because I'm dumb but I don't know of any other way to do UI programming other than event groups. Obviously, you don't want your processor to be you know, stop doing nothing all the time whereas your app is there, it's on the UI and it's doing nothing. Most of the time, right, the app is doing nothing. But you want to be interrupted whenever the user does something. So the event group is just perfect for that. And, you know, on the server everyone, this is a regular note chant so everyone's heard this. Most apps are just waiting for a connection to come up to the event. So, you know, you have to be most apps are just waiting for a connection to come in that they are to go and play the database so they're waiting for the database then, you know, they'll probably get some templates from disk and they're waiting for that to come through and only after that do they prepare a web page. So this is the gold mantra, right, saying that most of the time your app is doing nothing and so, you know, let's try to use that wasted time to do something better and event groups turn out to be, you know, great solutions to fix that. It's not the only solution it's a solution. There are other solutions as well, but, you know, that's the option that Node happened to pick and the reason they picked this is sort of two-fold. One is because we can pass functions around which is just very, very elegant in Node in JavaScript. And secondly, because there is a huge number of people who are already used to doing this on in the browser already so, you know, the learning curve is sort of easier when it comes to server-side JavaScript, right? So I want to come back to functions. Functions, you know, the disperse used to have this thing called lambda the ultimate, I don't know there he is, the disperse. Right, lambda the ultimate. So, yeah, so, you know, and this is the the only aspect of function that I'm really going to be talking about though. But the avenue to pass functions around all the jQuery guys might be familiar with this dollar.click and you pass it a function. Essentially what you're doing is, you know, here take this block of code, now wait for this thing to happen and when that happens when you get that message on your event loop, at that time use this use this function to, you know, do what you have to do, right? So that's what you're doing over here, which is a very powerful idea yet so simply expressed, right? This is another pattern. So this is a pattern where you're passing a function into another function dollar.click is a function, you're passing another function. Here dollar.ajax again something that jQuery guys must be familiar with is where you are passing it a function as part of an object literal, slightly different, you know, slight variation on the same theme and then there are the node guys who are probably seeing patterns like this Yeah, the text wrapping went crazy but, you know, so you must have seen patterns like this where you're basically saying get a file name you know, I want to read this file that's the file name and when that file, after you have done going out to the test, seeking, getting the contents, after you finish all of that call this function to do, you know, whatever you have to do, right? So basically the idea of passing functions around seems to be a very sort of common thread among all of these guys and so the node guys decided that, you know, if we have a standard way to do this, there's a lot of funky stuff we can do so let's try to figure out a standard way of doing this and they came up with this, it's called CPS or continuation passing style, I don't know why it's called that, I think it's because of the idea that you know, you code sort of continues where it left off the last time, I think that's what it is, but I'm not 100% sure So continuation passing style where you know, let's say that, so at the bottom there, I've got a function called make async call where I'm passing it, you know, value one so it does not matter what they are and the important thing though is that I'm passing the values or the regular arguments of the function first, then I'm passing the callback that has to be called which is the last argument to the function and within that callback, I always get the error object which is the first argument of the callback, right? node guys has decided it's a good idea if we stick to the standard the implementation of this would be, you know, where you've got something like that and you basically at some point when you are finished doing your asynchronous stuff, you call the callback that has been passed in either passing it an error if there was an error or passing it null if there was no error and you pass it, you know, as much amount of data that you want. The key aspects though, this is an example one more example it's too small now, isn't it? Is that visible? Not visible? Alright, so the wrapping will happen, I guess. So this is an example where, you know, you want to request some URL and you pass it a function that will do something with the response of that URL, right? Very simple question. Again to reiterate all the arguments that you want to pass in this case, the URL is passed in first and the callback is the last argument that you are passing into the function and within the callback the first argument to that is always the error, right? So I just sort of listed out what I have talked about so far. So it takes all arguments first, the last argument should be the callback, it passes an error as the first argument to the callback and then the remaining argument should be whatever data if there is a need to be passed into the callback, right? A couple of reasons why this is a huge hit. For me, one thing I'll, you know, I'm a very sloppy programmer sometimes. As much as I said that I take pride, I was just to brush you, honestly sloppy programmer. And I don't do a lot of error caching sometimes, right? I just, like, I fail at that and my servers have crashed because there's a lot of things. But the node style forces you to think about errors because you're always taking that error as your first argument. You have to do something with it now, right? So it forces you to think about errors. I like that, you know and so I feel that my code is somehow, like, you know, more resilient because of this pattern. So if you have, if you want to pass in some state into the callback, how do you do that? You can't. So usually that's done by closures. So it's not going to be passed into the, or you can bind it or you can bind it to a scope. You can bind the function to a scope if you want to. Feel free to interrupt me if you have any questions. What are you binding to a scope for? That is funky. Basically you're taking the this of the function and attaching that to an object and then you can access the this as well. That's a huge discussion by itself. We could talk about that separately. All right, I want to talk about ugliness. This is a problem with continuation passing style. I'm sorry, I'm zooming out slightly but I think it will probably help understand. You know, the example over here what it's doing is it's trying to read two files, do something with it and write a third file. That's what this is doing. So you can see there's reading file one, there's reading file two, then it's writing to the file and you know, that's how it looks. Apparently in my language returns can be capital. So, and this this is generally how your node programs look if you're a bad programmer like me. And that's why this has got an actual name for it. It's called name, it's called callback help because you're constantly passing callback after callback after callback, you know. And obviously a lot of people who come to node, this is the first thing that they complain about is that there's callback help. I don't want to... This is the ugliest form of programming I've ever seen who wants to deal with this kind of programming. It turns out they are right, they are not wrong. But there are ways to deal with it. For example, there is this framework called isync that I use a lot. It's about the same code, in fact it's slightly faster if anything. But it's doing exactly the same thing as this line. And so what it's doing is it's parallely fetching file1 and file2 and then when that's done it's writing that out to a file. So the actual library code does not actually matter. The idea is that I want to show you that it's possible to make things things look simpler. Right? Wouldn't that callback help be made to seem a lot simpler if you just declared each of the functions standard code. I think most of it is because you are declaring the function right there where you are using it. Correct. It still needs to be done smartly because you have to ensure that the declaring function does not let you take care of the depth. You still have to go deeper and deeper inside unless you decide that you want to branch off the writing and do that as well. It has to be done smartly. Though of course I'm sure the people who have a knack to do it will be able to figure it out well but usually a newcomer who's coming in will complain saying that I don't know how to make sense of this. Can you just go to the next screen? Yeah. This will work only if the two functions are independent of each other. So if I have to read from the first file and then do something with the second one then it won't work for me. Correct. So that's because I'm choosing to do it parallely over here. There is async.series as well that lets you go sequentially function after function. So after the first one completes go into the second one and third one and so on. So you can control that behaviour as you please. So it's sort of cleaner. I have only looked at the top parts of the code and it's made it slightly cleaner. But you know here's another variation of that again using async. Yeah. How in the back end it is parallely to both sides? Oh, okay. Great question. Right, right. So what happens in the async.parallel starts you're giving it an array. It starts processing this array internally. The array has got two functions and it starts executing the first function. It cannot execute both the functions parallely because JavaScript is single thread. So it starts executing the first function. The first function is doing fs.read file. So now obviously this process has to go over to the event loop because reading the file is not something that's done inside the JavaScript runtime or sorry not inside JavaScript language it has to go up to the event loop. So it schedules the read of this file onto the event loop. Now, now suddenly the event loop is free but async is now going to try executing the second function. So now the second function executes and that's also asking for reader files. The second file is also scheduled on to the event loop. So now both the functions parallely have caused the event loop to get scheduled. So whenever they will return they will return out of time the order might not matter we don't know at that point of time and whenever they are completed async figures out that they are completed together and we can go over how these figures out that they are completed together and then at the end we will call that last function that we have passed in. So it's essentially both of them scheduling stuff at the event loop one after another and then it could happen out of order or you know in order or whatever we can't be sure about that and then it will return whenever it's done. Right? You know Dharanjay was talking about functional programming and I have just you know recently started falling in love with it. It's absolutely elegant. I just love how you know you can just use and async lets you do this in over so async the library lets you do this over the event loop so you can actually do functional programming using the event loop that's actually a lot of fun. So here I've got two files that I'll just say you know I'm mapping over them and I'm saying fs.readfile you know it's that simple it's just two files are very elegant. Right? And then when they are done the callback is gone it's just beautiful. So anyway so that's that's that's our cps but cps is not it's not the solution to everything it's great when you want to do one thing and you want to do it once you know that's it's awesome in that kind of scenario but it sort of sucks when you want to do something repeatedly and it also sucks when you have to do the same when that same thing could have several outcomes like you call a function that would have several different things that could happen you know and cps does not really help very well over there so obviously there was there was an alternative pattern that was created and you know in the very early days of note I actually used to participate in the IRC rooms and you know as this as these things usually go and you go there with an opinion and you use like strongly defend your opinion and then you discover that you were a fool because they're just so much smarter than you but that sort of happened and you know ultimately this pattern is what one it's called event emitters and you know it's a very fancy name but really there are only two functions that you need to care about one is dot on and the other is dot emit dot on actually used to be called add listener at one time because it was sort of you know it was adapted from the browser so it used to be called add listener but add listener is just now sort of renamed to on or actually both of them are just pointing to each other and then there is emit as a consumer of something as a user of something that is using event emitters you actually don't need to use emit usually so most of the times you are only really using one function you're only using on so let's look at an example of that here I'm creating an HTTP server and you know every time a request comes in that function is going to be called the lambda is going to be called and you know if you look at the first request dot on data that's an example when I'm using the event emitter pattern I get a chunk of data repeatedly over so there is an example you can imagine there is an example of say uploading a file or something right so you've got a huge video which is say one gig or something and you're uploading that to a server so you know there will be passed on in chunks because that's how PCB works so you will get chunks and chunks of data and so each time you get a chunk the on data event will be fired that's the terminology the on data event will be fired which essentially means that if you have a listener that is listening to data like how we have over here then that function will be called every time that a data chunk appears similarly end is something that could happen when the stream is complete and error could happen if there was some problem in the transmission so here's an example of something that is actually having three different behaviors one of giving you chunks the second of actually stopping the stream and the third of possibly having an error in the stream and so event emitters are great for that how bad am I on time 10 minutes more so there is another pattern to use what is here in the earlier context I actually had encoding the expected sequence of how this was supposed to behave whereas this sequence now data and error could come in any sequence and your code is no longer making those assumptions which it would have had to earlier yeah so it turns out and you know unfortunately to add to the complication the fact that in CPS so elegant in terms of it sort of understood that the last argument has to be a function and here the event names are not standardized as well so you know there are some dissonance that is happening it's not very easy to use event emitters there are problems I don't know if that was your question actually I was I thought this was a big plus for event emitters that you no longer had to sequence out stopping first to handle data then handle and then end layer you are basically saying whatever shape and order it comes in I thought this was a plus for you I mean so that's the reason why it was created of course so you know the fact that things could happen in any way in any order and there could be entirely different things that are happening not simultaneously but you know very close to each other and you would be able to handle them within the same you know same block of a code at least so that's definitely a plus for you alright any questions so far on event emitters isn't the same the same programming paradigm is used in socket.io as well yes yes you are right and socket.io even on the client I believe we use the same one so it's a great example of where an idea from node crossed over and went to the client and you know it's the same pattern being used on the client as well exactly the same awesome so that's an example where you know an idea sort of went from the server to the client it's very interesting so you know obvious candidates for emitting events are DCP, UDP, sockets files as you are reading chunks of files again you know that's an example and HTTP request we just saw in the previous case so you know these are typical cases where event emitters are used but unfortunately since there's just so much code to be written to use an event emitter you know there are things like the read file function that I showed you which is generally the thing that you want you know in a lot of cases is that you know just go fetch the contents of this file for me and give it to me so sometimes you know people have created functions that sort of do all of these complications internally and give you just one chunk in the end you know because it's sort of more convenient that way right before I proceed it's the same exact same code from last time but you know can you think of any problem with this code other than the fact that can you think of any problem it's a problem that you know chunks will not get garbage I mean chunks will keep on up holding nothing on error absolutely so what happens is let's say you're uploading somebody is uploading a 5 GB file to your server your server only has one GB of RAM you know your server will start swapping and it will eventually crash and that's because you know chunks are keeping on getting accumulated in memory and you know it will not be released until you're actually doing something in the end you know you're just keeping on adding that up right so that starts getting that starts becoming a huge memory overhead so you know the solution obviously is to avoid buffering that that is classic buffering that you are doing there the solution is of course to avoid the buffering so rather than waiting for end to fire you call you do something right when you are receiving each chunk of data rather than you know trying to wait for collecting all the data together you just do it in chunks right for example let's say that you are having a file upload happening and you want to write that file to your server to the disk you could just as you get a chunk you just write that into a file and you know just keep doing this one after the other so you don't have to hold this in memory you can just keep flushing it instantly and it turns out this pattern is actually rather common in JavaScript in Node people start discovering that they are doing this actually very very frequently so they decided that this has to be formalized as well and as recently as 0.4 I think in Node is where they started talking about this and so they decided they have to formalize it they have to make it easier to give it a better API make it easier to write and so streams were spawn paraphrased and I probably won't mess up with you but I think this is by by Isaac's Isaac is the current maintainer of the Node project but yeah that's what he said he said streams are so awesome they alone justify the existence of Node that is how awesome streams are everything that has been done in Node until streams was created is essentially garbage compared to streams streams are just that awesome and let's show you an example of how that works those who are familiar here with Linux must have done something like this where you tail a log file and then grab it for a certain pattern and if you look at what's actually happening what Linux is actually doing is taking the standard out from your first application which is tail taking the standard out from that and then connecting that into the standard in using this pipe operator let's call it an operator I don't think it's an operator but connecting that into the standard in and then it's running a pattern over that so that's what's happening over here so eventually you are talking about building network applications that can be composed together of smaller applications I think this is what they must have been referring to they are very diverse over the network so you would have so you would have data coming in from different sources from across the network and then you would sort of piece them together by using small applications that are really doing each piece so to give you an example here is one where I'm reading something from a file and I'm piping that to a response so let's say you want to download a huge file I'm reading something from disk and I'm flushing that over your HTTP response so that's how you are able to download the file again obviously none of this is being held in memory this is very very efficient memory wise because it's just chunk after chunk that you're reading and you're writing and you're reading and you're writing it's essentially under the hood it's just the same but it's being packaged differently to appear more elegant as compared to the ugly limit amount of code that we were looking at so far and people have gone crazy with this there's amazing stuff that's happening people have written proxy servers that's one line of code you know essentially just take stuff from there go make a request and impact that over the response that's it and so this is one line of code that's a proxy server it's just very very elegant but I have to add that it's just very very elegant I just know how beautiful it is sadly streams aren't quite all that ready yet it's very hard to build a stream a stream that is pipeable is very hard to build it's hard so these streams that you can pipe from one location to another is called a read stream that's one type of stream there's also a write stream which is one that can accept data so there's the read stream on the write stream and then there are read write streams that can both accept and you know spit out data and these are very hard to build and you know 0.9 and 0.10 there's probably going to be a 0.10 for node which is a very weird number to have but you know whatever 0.10 they say that the focus is going to be streams and the focus is going to be to fix the API for streams and to make it really elegant if you look at github.com slash Isaacs there's already a lot of couple of ideas that he's already toying around with to make streams easier to work with Isaacs is the man he's got a lot of interesting stuff going on there and yeah let's be a little forgiving these are early days for stream streams are barely about less than a year old so there's a lot still to be evolving in the stream space quite Will it support renewable upload and download out of box so that's the thing is that you can already do upload and download out of the box this was an example where you can do download right this is an example so the problem is that to do that it's entirely possible to do that no doubt about it but to do that it's actually a lot of work which was my first point over years in the streams are hard to build right so it's entirely possible to do that your board will look very elegant after you have done all the hard work but doing that hard work is difficult so right now it's not you know it's not there yet it's not very beautiful yet so but you know it's something to watch out for in the future I think that in the future this is what will become the most interesting piece in Node same question regarding this Node.js is using in networking so its P2P communication can be totally replaced by this thing or not same thing P2P communication totally reduced reduced by this things that same thing that you can download it after some time or resume it any time so if it is in networking we are using in networking model we can directly build into the system and resume after some time if connection goes lost we'll stop there then read again from the disk and then flush again into the disk is that possible in the future I have read IEEE paper of 2010 about the Node.js I think that same same concept was that about this thing that you're using in networking scheme networking thing I don't know I guess I'll have to sit down and understand the scenario that you're talking about let's take that up right after this talk because I don't want to get everyone sitting down listening to that but that's interesting I want to explore what that means cool any other questions so far so that was the point my point was not about Node my point was not about browsers it was not like married to any one of them my larger idea was that the fact that there is activity happening on both sides of the network is helping improve APIs for everyone so now these kind of things are starting to happen on the browser socket.io is an example of that people are building much better APIs there are so many things now when you think about that that can be dealt with in terms of streams or in terms of event emitters or in terms of simple callback passing style on the browser that it's just beautiful things like there's now five system APIs that are available in the browser and you could think of that in terms of streams there is web sockets of course which we have already talked about which you can think of in terms of streams there is also the event stream spec if you are aware of which is called server sent events in some cases that's another case where streams are really useful there is also plain old where there is data coming down over the wire and you can sort of deal with it in chunks so that's another case where there is data that's happening asynchronously and then of course things like button clicks and form upload these kind of things can also be thought of in terms of events so probably in the next about six months to a year I think that there will be new frameworks that will come out that will start using APIs that mirror nodes API very closely there are already some attempts done I recommend you look at work by this guy called Max Ogden you know he's been doing some very interesting work but he's building client API that actually mirror node server API it's very interesting to work with those in terms of you know it's the same sort of paradigm that you are using both ends so that's very interesting and this is uncharted territory more or less so you know if you are a good client side developer and you are familiar with node give this a shot you could be the next guy who is doing this right it's very interesting and you probably should and that's a wrap that's all for me thanks you thanks thanks now any questions of course and if you're too shy to ask me right now you can you know catch up later go ahead this is one of my first events like this only one question of the topic since when are people giving presentations in the browser well that's been going on for quite some time congrats congrats on your first event yeah but yeah people have been giving so this particular one is by this guy called Hakeem Hakeem.se very popular on the interwebs for his work on you know generally about graphics and stuff like that he's one crazy guy this one this I think this is called reveal.js reveal.js there is also an id for it now yeah there is an id for it now as well so it's amazing impressive so Impress has Impressionist which was created by a guy in Bangor he works at Redo and reveal is by Hakeem who built his own id go ahead my question is specific to software there is something that interests me about more.js in the sockets part but when we talk about sockets we are also considering the hardware interrupt that the socket is going to in go which is pretty resource intensive so how gracefully does node handle that possibly node is great designed for that I am not sure about that I am quite unclear about that does node handle that quite gracefully or is there something else that needs to be I am not sure because I don't know too much about what is going on over there most of that code is in sea land and sea for me is like alien speak I can't understand sea there are just too many pointers flying around for me to make sense but I just want to make a quip about the fact that Anjai was talking about the worst language you said it was php I am surprised because maximum WTF was php I am not sure I am surprised because Perl still exists because I can't distinguish I don't know when Perl stops and a regular expression starts I can't make a difference correct nothing working on the keyboard could be a valid Perl code so I have a question about a paradigm man you have a system where you want to broadcast a message to let's say 50,000 simultaneous users so far I am not able to find an elegant solution for this so it works very much as if I am sending a message to 50,000 users where each message might be different is there anything which could be done where the message is seen when it is broadcast something called multicast but even then below the system it works very much in the same way it is relating to each connection individually not necessarily if your transport supports multicast it is multicast all the way so usually ISPs don't support multicast at the consumer level but what happens is distribution services like Akamai this is their primary business I mean apart from their caching business what they do is set up multicast servers at major ISPs around the world and they do a single cast to that edge point and from there it is split up into clients which means that your source server doesn't have to take off the load I don't know that myself I do know something every day we will go back to the web socket part I missed the initial session about that is it TCP over HTTP or is it web sockets I don't think anybody is sure anymore that spec has just changed so many times it is not it is not over HTTP it is negotiates over HTTP it starts from HTTP and then it moves it is almost like a TCP connection HTTP is a command that you can use to turn it into a web socket it says upgrade changes the protocol and how different it is they also claim that it is port sharing with HTTP yeah because you make an HTTP connection and then tell it okay I want to convert it into a web socket which means that your server whatever you are using must understand the web socket the conversion command and Apache doesn't support it nginx doesn't support it so I should use Nord so if the web server need to understand the web socket protocol as such then you need to have some gateways in between so usually the gateways are the ones that don't understand it like the popular gateways are what Apache, nginx neither of them understand web sockets there is one company called Causing which they provide some web sockets gateways for the other that's because the popular ones don't support it out of the box but there are patches so you can patch your nginx build a custom version which has the socket support built in and the thing is because the web socket standard itself is not final you know it's been changing a lot over the years so which is the reason why Apache refuses to make it part of the official business because that means it's becoming standard because Apache itself is so popular that once it's deployed there's no hope of changing it we can use HAProxy HAProxy can I think you can use HAProxy in front of Apache and that will sort out your web socket cuisine and I think you've tried pubnup.com you were asking what 50,000 broadcasting that message to 50,000 that was for our system we failed that problem in our system so there's this service called pubnup.com so I think and this is the specializing they have this full infrastructure they'll just give it to this other service basically so you just try that pubnup.com and go and check it out I was just saying that I think recently nginx converted to supporting web sockets in their latest builds so I think you should expect that is it in release? it's part of their roadmap now but I guess it'll again be a few months before it comes out in the next open 2 which is what motion will end up using and the guys are NTS so I have a question regarding what sort of programming style would you really like to use with the synchronicity and all this stuff what we see with Node is it's more about emitting events and callbacks there's another style which I'm not quite familiar with but something called as promises it makes it look very procedural it makes it look very easy for the developer and I constantly thought about adding a slide for that but I forgot about these relatively less common patterns but are there anyway futures, promises and stuff like that by and large I would recommend you should not use them simply because there are not enough people using them already so it must be a chicken and egg problem I'm not really sure if they're good or bad because I have not used them myself I would recommend that you don't use them anyway because it does not have enough mindshare there's not enough activity going on there and in a lot of cases you need to have buy-in that entire stack has to be using that mechanism so in a lot of cases once you take that decision then you get stuck in that world and you will not be able to come out of that so I would recommend that you don't go there usually but don't add something of support for futures and promises no it doesn't, people have done stuff with working at the sea level working with stuff like that so there's stuff available for sure you could play with that if you want to but that has not managed to garner enough community support yet so people are still playing with ideas like callback passing and event emitters it's okay for like job care developers who are very much used to callbacks and event emitting at the UI level and that's what we do in day in and day out but what about someone else coming in now that we are projecting node as the server language so what about people coming from java that reminds me of this thing that Bruce Crawford said that JavaScript is the one language that when you are starting work with JavaScript everybody thinks they don't need to learn the language that's how it works everybody just opens their editor and starts writing JavaScript everybody is a pro at JavaScript that's what everybody has used and when you are going to learn Java you would learn how Java works you would figure out what the videos in Java are you would figure out what design patterns you should use in Java but somehow when you come to JavaScript you don't bother doing that you just think that oh I know Java so I obviously know JavaScript and so I am going to do JavaScript the way I am used to doing it in Java and so I think and it's true that there are more people than not who do that honestly I did that myself when I came to JavaScript