Panel

• AJ O'Neal (twitter github blog)
• Charles Max Wood (twittergithub Teach Me To Code Rails Summer Camp)
• Jamison Dance (twitter github blog)
• Peter Cooper (twitter github blog)
• Yehuda Katz (twitter github blog)

Discussion

• The Javascript Show
• JavaScript Weekly
• FluentConf 
• SpotterRF
• Synchronous functions vs Asynchronous functions
• setTimeout
• XML/HTTP request (AJAX)
• User Event
• jQuery
• Game loops
• Callbacks
• setInterval
• FuturesJS
• named functions vs anonymous functions
• scope problems
• web workers
• Node EventEmitter
• Node.js
• Node sync
• I/O async
• Your coffee shop doesn't use two phase commits
• Threaded systems
• Idle time in browser
• onUnload hook
• Chrome
• Ad vendors
• Tilde
• Utah JS Call for Papers

Picks

• JavaScript: The Good Parts (Chuck)
• The Adventures of Merlin (Chuck)
• The Lean Startup (Yehuda)
• Sherlock (Peter)
• How JavaScript's Timers Work(Peter)
• Fluent Conference (Peter)
• Reg Braithwaite (Peter)
• Crockford Videos (AJ)
• YUI Blog (AJ)
• Node Google Voice (AJ)
• 750words.com (Jamison)
• Working Effectively with Legacy Code (Jamison)

Transcript

JAMISON: What's Canada? No. Canada isn’t in between there. PETER: It’s America’s hat. CHUCK: Hey everybody and welcome back to the first episode of-- (welcome “back”). Welcome to the first episode of the JavaScript Jabber podcast. This week on our panel we have AJ O’Neal. AJ:      That's me. Yup. CHUCK: So since we are new, do you want to just introduce yourself? AJ:      Okay sure. So, I work at SpotterRF (its radar company). But we get to do some good stuff with HTML5 and our browser-based software and some of our internal applications and a little bit of NodeJS as well. I first got interested in JavaScript because of Ruby actually. I’d only messed with it as much as people who hated have messed with it. I started going to the Ruby group and then got into Rails and jQuery and once I actually started learning JavaScript for real, so the good part is, I became a fan. CHUCK: All right. Also on our podcast we have Peter Cooper. PETER: Hello! Hello! Hello! Yeah I guess if anyone is listening to this, they may have heard of it, because I am going to link it up in all my various bits and pieces which aim a curate at JavaScript weekly, which is a weekly newsletter about JavaScript and also co-host to the JavaScript Show. I know I shouldn't promote another podcast on this one, but we’re going to link you up. So hopefully we have some business coming across. I'm also co-chair of O'Reilly's new Fluent Conference which is taking place in May (we’d probably talk about that some more some other time) but yeah I'm not actually that well known for my contributions in JavaScript code-wise, although I’ve developed quite a bit. I’ve done a couple scripts as well. I guess my only semi-claim to fame with JavaScript is I wrote the first kind of AJAX help library for Rails back in 2005 before it even supported AJAX. But it was quickly served and Rails built all that stuff in. But it was interesting couple of weeks. So yeah that's me. CHUCK: All right we also have Jamison Dance. JAMISON:  I'm Jamison Dance. I also work at SpotterRF so I work with AJ on some JavaScript and browser and those stuff. CHUCK: (Nepotism!) Oh wait never mind. JAMISON: (A little bit of that.) I also dabble in machine learning and data mining natural language processing, that kind of stuff on the side so I do some of that for fun. CHUCK: Alright and I'm Charles Max Wood from teachmetocode.com. I do things like video tutorials mostly for Ruby. I kind of got into the JavaScript stuff when I first had my first programming job doing Rails. I worked with the guy that is really big into JavaScript particularly into prototype.js which nobody really uses anymore. (I wouldn’t say nobody, but almost nobody). And I really kind of got to see the power behind it and thought it was a cool language but didn't really get into it until people started talking about Node.js and stuff like that, decided have a second look and I really kind of dig it as the language. I'm getting more and more involved in community and I'm excited to see where it can go. This week we were talking about asynchronous handling and the event loop in the browsers and AJ is kind of an expert on that so why don’t you go ahead and start a conversation and we’ll take it from there. AJ:      Okay. My first realization of the problems of asynchronous coding or the joys or whatever you wanna look at it as, was I was getting a little app where I wanted to integrate things like Facebook and Amazon and then I wanted to get both requests at the same time. And I was doing that very amateur mistake of you know, you set a timeout for a second, you check to see if the request came in and you set the timer again and that kind of stuff.  I guess the challenge to JavaScript is just understanding that, first of all that there is an event model, that it's not the same thing that you're used to with say, Ruby or Python. CHUCK: Alright. Are we talking about things like, what is it, setTimeout that you get in a browser? Or are we talking more about things like when you do an AJAX call and you have this success function blah blah blah and so it kind of sets up an event so that when it returns it calls that anonymous function. AJ:      Well yeah. I mean both of those kind of tied together same event loop. JAMISON: So I think one problem a lot of people are having when they come to JavaScript (I know I did) is the idea that there is an event loop. That it's not just your code getting executed sequentially. Maybe we can talk about that a little bit more just to explain how that kind of works. I mean I think lots of people come from like C and Ruby and I don’t know, just stuff where each line of code happens and the next line of code happen. AJ:      Yeah I think that's a great starting point. So yeah I’ve seen that a lot too where were people ask like, is this a synchronous function or an asynchronous function?  Like when you start talking about something like for each or other methods that appear to take a callback and then people want to know, how do you know if it's synchronous or asynchronous? So a good definition for that would be that it is synchronous when you're going to complete the function and everything inside of it, everything that you can visually see inside of that function before you return (or the function closes). Whereas the asynchronous part is if you have something like a setTimeout or you have an XML/HTTP request or are you waiting for a user event, that you don't know when it going to happen. Then when your function ends, you are returning “undefined” or perhaps you're returning some type of emitter or call back handling object, right? CHUCK: So what happens then if let’s say, I want when I hover over this icon, that it changes colors or whatever. What happens in that instance when I set that hover state up with jQuery or whatever? AJ:      So you're attaching an event or a function, to the event handler and when you move the mouse, as long as nothing else processing, then you are going to see the mouse cursor move and then it's going to fire an event for every pixel or however often it can handle firing the events. And then when the processor is free to handle that event, then will execute your function and carry out whatever had inside. So let's say for example, this is one of the reasons that there are event handlers in JavaScript, is the browser has a lot of things going on and if you wanted to do some sort of computation, that's going to take say, a second, then if the browser will lock during that time, you wouldn't be able to move your mouse.  So the events makes it so that you can have a little snippets of the code that run and things that would take a long time will then be enqueued. So you know, if we were to do something like in C code where you're reading from the user’s input and also, (I forget what it is) but you know, you open standard and then you are going to read into it. Then your program halts, you sit there, you wait, you do nothing. CHUCK: Right. AJ:      And you don't want to do that in a browser. You want the hover event to fire you on, the visual display to change. And you wanna do all that within a single thread, so amateur; (more or less) programmers can do something without having immediate failures and confusion. CHUCK: Alright so that makes sense. What are some of the things that people use it for. I mean we talk about hover states and things like that. Any other like major things that people— JAMISON: I think the most common one is just HTTP request. So you're just going to get some data from somewhere. CHUCK:  (Right.) JAMISON:  I mean like all the AJAX library and stuff like that. So that's where they are all started because it's going to take a while for it to come back off the network and then you might do something with it when it gets there but you don’t wanna block while you’re waiting. PETER: Don’t forget game loops as well. I mean obviously JavaScript heavily used in gaming (casual gaming) especially more and more now. I've been playing a lot with it, the gaming side of JavaScript and there's so many things using events there, just because actually, it's kind of an old pattern from game development of the last 20 years using event loops, so it's kind of a natural fit. CHUCK: Yeah, so you just set a callback for whenever somebody does something? PETER: Yeah I mean sometimes, I mean, they are actually adding APIs so that you can request animation frame and stuff like that now. But previously, the people were using, you know, setting into towards to do certain number of frames per second on one type of thing. But they are actually changing the APIs on that type of thing. So there is a little bit more to it than meets the eye in JavaScript, especially with the APIs that browsers are offering now with canvas like kind of stuff. JAMISON: So one other thing I think will be important is talk about it now, I mean talk about the event loop and how it works, but how you actually chain asynchronous things together. Like what if you wanted to do a bunch of things in sequence or do something once a bunch of asynchronous things had finished. I think that is a pretty common thing and that's why you see that like “pyramid of doom” pattern all the time, where you just do everything inside of a callback to the next thing. So you get this triangle that goes way off the edge of your browser or way out of your screen in JavaScript code. AJ:      Yeah that’s definitely something that—yeah I think that the pyramid approach and then what I was talking about earlier with the setTimeout, check and then setTimeout again. Those two approaches are very common when you’re first getting into JavaScript, because you're just not used to an event model. When you got the pyramid because you want to make a request to Facebook and when Facebook calls back with the log in then you wanna make a request to Amazon or you wanna make a requested to Twitter, they are somehow dependent. That’s when the waterfall is actually being used appropriately. If you can do two things at one time, then you should do them both at the same or rather put them both in the event loop at the same time. But then you have to figure out, well, when I go know which one is-- when they both come back and there’s not really any built in mechanism for either of those and if you think about it in the beginning, with JavaScript you had, setTimeout, a setInterval and event handler. And I think that was it. It wasn't until 2000 or 2001 that Microsoft added the XML/HTTP request. Is that right? JAMISON:  I think so. Yeah. AJ:      I don't think was built with the idea that you would want to be doing so many asynchronous things in mind when it was first created. So there isn’t a built in way to say, oh, well this is a clear way to handle that solution. That’s kind of what led me to create the Futures JS library. Just a quick rundown, so say you’ve got the waterfall, the way I like to do it, (the poor man’s way without even using a library or anything) , is simply to separate that waterfall into functions that are all indented at the same level. Then have that end of each function, the call to the next function. So when I look at my code, the very last thing to execute is all the way at the top and the very first thing to execute is all the way down at the bottom and every function calls the next. It's a little bit nicer than the waterfall because you named functions (so hopefully you are naming them something useful rather than just having the anonymous functions nested further and further). You can reduce scope problems that way, because there are problems that occur with scope, where you got the variable in one place and then you modify it in another place and it turns out that in that lower scope you might have done something two or three times and when you get to the next place where you are going to modify that variable, it was already modified. So that it's a thread problem all over again. So if you keep your scopes as high as possible, you definitely have much less of a chance of running into that, has this variable been modified when I wasn’t thinking it would. CHUCK: I'm trying to wrap my head around this. So basically what you're saying is that, you, instead of having, let's say that you have one event or you have one function that needs to be called, once two other functions have completed, what you set up is so that it just does it all insert certain sequence anyway? Or— AJ:      What I'm saying is, you have a sequence, instead of going through that, what you call Jamison, the death pyramid? JAMISON:  The Pyramid of Doom. AJ:      Okay, pyramid of doom. So instead of doing the pyramid of doom, where you're indenting, indenting, indenting, indenting, anonymous function one after the other to the point that when you go back and look at your code, you cannot tell what it does anymore. You can just tell that it’s indented fifty spaces. That you keep all of those functions indented at the same level and give them proper names. And that helps just with the organization. CHUCK:  Oh I see. That makes sense. So then what you do in your pyramid of doom, instead of it being indented, this is code readability issue right? AJ:      Yeah. CHUCK: instead of indenting, you know, yeah, for each anonymous function that needs to be called within the other anonymous function, you just set up an event that calls back out to your list of possible functions that it can latch onto and execute based on the event that was fired. AJ:      Right, but if you want to do two things at the same time, the poor man's way to do it is, to set a variable as a counter. Then for every function you have, you increment the counter by one, and then when all the functions are done, you have them all call the same callback. CHUCK: Right. AJ:      So every time that call back gets called, it decrements the counter and then when the counter reaches zero, is when you call the final callback with inside of it, the data that has all of the outputs from the other functions. The two functions that I have implemented in futures for that. One is called “forEachAsynch”, which handles the waterfall or sequence they are both very similar and then I created a function called “join”, which does exactly what I just said. Every time you add a function, it increments and when they are all done, it decrements, then calls for a callback. CHUCK: Interesting, I like it. So it's kind of a workflow manager. AJ:      Yeah, definitely. But one thing you want to be careful of, still understanding the difference between doing things sequentially on purpose and doing in things in parallel on purpose. Because you can do things sequentially on accident and just waste time, CHUCK: Right. AJ:      But you can also do things in parallel and hog down the browser or even cause your application to start throwing errors. Because for example you can only do six in the latest browsers, you can only do I think six web requests at a time. CHUCK: Yup. AJ:      And so if you're like oh, well these things don't need to be sequential, so I'll just go ahead and do them all at once. And you’ve got 20 requests you wanna make or something like that. So you have been queuing these up from user changes and now it's time to push your memory database out to somewhere where it’s going to be saved, something like that. Well if you queued up 20 of these Web requests, then when you are going to do them, only six of them are going to happen until those are done, the others are still waiting anyway and then you end up with the case where maybe you got HTTP time out and then you get an error for thrown when your code is perfectly valid. Makes sense? CHUCK: Right. AJ:      You got to understand what it is that you want to do on purpose and what you want to do because it’s convenient and make sure that they are aligned and then that you're not doing too many requests at once just because you can. CHUCK: So are there any other areas that we run into logjams like this and in the browser or is the HTTP request kind of the only thing there? AJ:      I haven really worked much with the web workers or— JAMISON:  (yeah you should talk about that.) AJ: WebSockets.  How many of you have been working with either of those? CHUCK:  Not really, no. AJ:      When I first tried WebSockets, it was a while ago and it was kind of *** (00:17:15). So I haven't played with it since. But I want to pick it back up in the next week or so. I got a little project I have to play with. JAMISON: I haven't done anything with WebSockets. I've done a little bit with web workers and web workers basically (someone will probably correct because going to mangle this description) but it seems like they kind of spawned off another JavaScript execution thread. That’s just pretty much separate from the one that’s running in your browser and then you can communicate just be a message passing. So in your web worker, you can compute some stuff and then pass the message back to the browser thread. Then in the browser, you listen on the web workers events. So if you had some computations that would take a  long time, you could just spin up a web worker and then web worker would do it all and then submit the data back via a message that would fire an event in the browser. CHUCK: That sounds really interesting I'll have to look into that. PETER: There’s also a fibers library for Node or similar type of thing and if you are in the Nodes side of things? AJ:      I thought fibers was to make it look less asynchronous or am I mistaken? Peter: You can do use it to do that yes, but it can build on top of the extra stuff that will add threading support to Node. It uses threads to do it. JAMISON: Yes so, one thing about web workers is that it's you don't get the full browser context. Like I said I've haven’t played with them very much, but I remember reading that you don't get things like XML/HTTP request. I don't think you have access to the dom. It thinks it’s just a JavaScript context in which things are running. PETER: Can pass through reference to stuff though, because I've seen people use web workers to deal with, like sandbox implementations and you can pass through functions and references to things that you want the web worker to access. So, it's kind of a sanitized environment which is kind of cool actually. JAMISON:  Yeah I think you can somewhat emulate that with an iframe as well. (I mean not that I'm suggesting that you use an iframe to do web worker’s job), but if you did need access to some of those other things, you didn’t want to do deal with that limitations of the web worker for very specific reasons. CHUCK: I see so I'm a little curious to, does the asynchronous loop in the eventing work the same way in something like Node.js where there is no browser, it's just a JavaScript environment they you can run things in? AJ:      Well, I think of you think of V8. That will be more like your web worker space, where you just have a JavaScript context. CHUCK: that's reduced (00:19:49). AJ:      Or the Google JavaScript engine. CHUCK: (What were we talking about? Anyway. ) AJ:      But in Node.js, the difference is the API is different and you have a lot more that you can do. But it's still the same event loop. I use a lot of the Node libraries in the browser like the node EventEmitter is my primary emitter that I use in the browser because it's a very, very good solution to a wide range of problems. PETER: If you are on Node though, there is something that you can install called “node-sync”, which gives you that kind of being able to write asynchronous code in a very synchronous way for your gain. But that definitely, that's won’t work with the browser. It digs into the Node runtime. JAMISON: So why would you want to do that? That seems like you are using Node because it's asynchronous and then making it synchronous again.  Like why not just use synchronous? PETER: You can write the code in synchronous style, but it will still run asynchronously, if you see what I mean. You wrap it in this big function call called synch and you pass in a function and then anything that's in that function will run asynchronously even if something blocks, it won’t hold up in entire system. JAMISON: So chuck you asked about when you want to do asynchronous stuff. We mention stuff in the browser but I mean if you are talking about Node then there’s all this kind of stuff too. Like talking the databases’ file systems and stuff and all of kinds of system calls and then there's lots of opportunity for asynchronous things. CHUCK: So that is an interesting point I think we all have experience with Ruby and Ruby generally doesn't do I/O blocking. So if it's doing some kind of I/O-like talking to a database or this or that, then it won’t block on that. It will just move on and then when it comes back, it will pick it up again. So it that's kind of the same thing here that we're talking about then? AJ:      Well what do you mean by that? I because I thought that, I mean, I just used like the MySQL library with Ruby but it seemed like file reads and database access and what not in Ruby is blocking. Isn’t it? JAMISON:  Do you mean if you pass in blocks chuck? CHUCK: My understanding is, let's say, that you have (and I'm not a Ruby expert) I'm pretty proficient with Rails. AJ:      (Yehuda why did you leave us.) CHUCK: Yeah Yehuda was supposed to be on. We are not sure where he is. We weren't doing super well with the communication. So he might show up in like five minutes and say okay I'm here. PETER: Come on chuck dig that hole. CHUCK: So my understanding is that Ruby has some provision for not blocking on I/O and I don’t remember exactly how it works. PETER: That’s Ruby 1.9? JAMISON:  I think that's new. CHUCK: But anyway, so it can make a request and then since its single threaded it can go and do some other work and then I'm not explaining this well at all. PETER: I think what you are probably getting at is that if you do have multiple threads running in Ruby 1.9 and you do a kind of blocking I/O requests in one of those threads, it won’t cease the entire because of the global interpreter lock; it will allow the other threads to continue running. CHUCK: Yes. PETER: But it has more threads it’s not all on a single thread. In that case it will just block if you make a blocking call. JAMISON:  So if you are using Ruby threads you mean? PETER: Yes you have to using a Ruby thread. JAMISON:  (Okay.) PETER: But there is a real thread in 1.9 but it still hooked up with its global interpreter lock things. CHUCK: Yeah that's what it was and I'm sorry I didn't communicate it well. I don't completely understand the interworking’s of the VM so anyway, yeah I made myself sound like an idiot but that's okay. AJ: You could have gotten away with it Chuck, this is the JavaScript Jabber. CHUCK: (But anyway so, yeah IO, asynchronous stuff). Are there any other examples of things that Node does that are asynchronous that aren’t call-outs the other systems? AJ:      Everything that you would do in C that blocks, now it doesn’t tell the network access all the file access, database access. JAMISON:  You can make non-blocking calls in C too right? You just can’t attach callback. AJ:      Its hacker complicated. Especially if you're looking for cross platform approach. There are libraries like Libav, which Node used to use but, by yeah it's not quite so elegant by any means. PETER: So they turn to the dark side. JAMISON: But the one thing I want to mention, there is a lot of people that approached JavaScript with the idea of oh I'm used to synchronous code as I’m going to write a synchronous code. I think that is a poor paradigm or a poor way to start it. Because you end up realizing later that you need something asynchronous that can’t be done synchronously. For example most of the APIs in Nodes have a synch option so there’s fs.read and there is fs.readsync, right? There are some things you cannot do that for. And then you end up having to mingle your code to add this callback as the last parameter. Or even worse like you have a callback and then you decide you need to add yet another parameter to a function. So then you end up doing this guesswork where it's like okay first argument exists and the second argument exists in the third argument isn’t a function but the fourth argument is, then that's the callback in jQuery. I hate that. I was going to think you got to write with setTimeout where function comes first, I think it's a very good model. I wish almost that everything in JavaScript, you'd either pass in a function or Nodes in the first parameter so that you find later on that you got to go back and make it asynchronous, you don't have to go through your API and change everything. CHUCK: right. So I'm still trying to get my head around some of the event and thinking that goes on with JavaScript. I kind of get that there's something there, there’s an event listener something that when you trigger an event, it pick things up then just executes the function. Does it do that right away and is that just built in to the language? JAMISON: Yeah it’s built into the language. A really good read is (and I will give a link for this later) but there is an article “Your coffee shop doesn’t use two phase commits”.  And it describes the event paradigm really well, they talking about databases but it really applies to events well. You go to Starbucks, order a coffee pot the cocoa bean right and you order your coffee or your hot chocolate or whatever and then you go and sit down right, you pay and you sit down. They got the most important part of what they wanted, which is your money and what you want. Then you sit around and wait. it’s not like you go up and you say, okay I want a coffee and they say okay well just wait here in line and will take 45 seconds to get that to you and then serve the next customer, right? PETER: (If only they did.) CHUCK: Right so you don't want to wind up in the paying queue and then not get in your food queue. JAMISON: Well you kind of do end up with both of those queues but at separate times. Did Yehuda come back? CHUCK:  Yeah I thought I heard him there for a second. JAMISON: Everyone say hi Yehuda. PETER: Speak! CHUCK: Dropped off. JAMISON:  I think he’s gone. Man, that California internet. PETER:  I think the thing to remember Chuck; because you were asking about events and model is that you know they have been around long time is not something that is new to JavaScript and such. It’s just that JavaScript kind of forces you to use one. But if you look at applications like even just in a regular Windows application built in the mid-90s or something like that, if you building your visual C or your Visual Basic or whatever. You will tend to have, because of the demands of the GUI system you'd have an event that or event driven system, just because of the demands of the GUI. So it's an old model and its and you know some of the developers are very familiar with but some kind of come to JavaScript and kind of rub up against it a bit. AJ:      So I think I usually think about event systems, I think that the way the analogy given about the coffee shop is good. I think it's it helps understand what event it is, but I think it misses the other options. I think there is a class of people who think the event, the solutions are just basically the only way to get with concurrency and as people probably know, threaded systems actually worked out okay. I don’t really want to get into an analogy war. I don’t really wanna figure out what threads mean in terms of the coffee shop, but there's definitely a fetishisation of events. I think in UI environments they make a lot of sense, because almost everything that's happening is responding to a thing that the user is doing. So like conceptually event when the user clicks, I would like to do this, but it’s not obvious just because it makes sense when we are talking about responding to user events that, but it is also the correct way to do concurrent programming. CHUCK: Right so I guess my question is, so I trigger an event, then does that function that needs to be executed get thrown on a queue somewhere and it just says okay these well these have all have their events fired so I just work through them or does it just execute them one on a time and does that kind of block the thread? AJ:      So events that come from the user like if you are on a browser, what's usually happening is that most of the time, your app is idle, it’s not doing anything at all. And as soon as you start moving the mouse, then the browser says, okay there is an event that has happened the user has moved the mouse. Does anyone care about a mouse move? If anybody cares, immediately invoke their callback. Most of the time people are not listening for mouse moves so nothing happens and so the browser continues to in idle in between every incremental mouse move. Eventually you're going to click on something and then the browser says okay you click on something, is there anybody who are registered a listener for that thing, if so, run their code right away. So that is basically how the browser event system works. If the user triggers an event, usually that is executed immediately. So basically, the reason why a lot of times in JavaScript you'll see an idiom which is like setTimeout function, do something one or something like that, is that basically if you don't do that, then any code you run is executed in line. So people sometimes were all, why does that time out? Which basically says run whatever code there is, when you're totally a done running the code, you're going to go back to that idle state and you be like nothing is happening now, except that part of what happened in the idle state is that the browser says okay, is there any timer that has elapsed? If there is a timer that’s elapsed, go on that callback. Essentially a timer that elapsed is basically equivalent to the user moving their mouse clicking on something. Except that the browser is keeping track of how much time has elapsed. CHUCK: Right. So the other question I guess that brings up is, let’s say that I am being really smart and I set things up so that on mouse move, I have like 10 different events that I'll get triggered because I moused over a certain dev. So does it execute those in a specific order or does it just you know a trigger them all and spin off threads for each one or how does that work? AJ:      All right. So in browser JavaScript there are things that never happen concurrently except for if they do not share the same state of level scope. So the only concurrent is like on the web worker which has this whole own JavaScript scope. But what happens, historically, there’s not been a case that it was standardized. But now the rule is, because it's like essentially works its way everywhere, is they are executed in the order that they were registered. And that's also what is true about jQuery events because for a long time. So basically, you mouse over and the browser says okay, event has happened, does anyone have any callback? And there is a list basically, internal, which is the list of the callbacks. It would basically just run through them in order until it is done running all those calling in order. It doesn't go back and say, okay we are now idle. What's actually really important is that, the only time that the browser is willing to render things, is during the idle state. Basically, you can easily make the browser hang by simply saying when you click on this, do a loop and wait a minute, wait a second. The browser, basically AJAX, no other callback can run. The browser is sitting there saying, okay I'm running code and it’s not like in the back of the browser, it’s always like oh, AJAX will come back running that. The browser only does those things when it's idle. So basically it’s in the middle of running those callbacks. CHUCK: Okay, and that's the advantage too, is that it runs stuff when it’s ready and you can just say okay and when this next thing is ready, then run so we can go back into that idle state and do its other work? AJ:       Correct. JAMISON:  So related to do this stuff, is there some kind of way to the see the contents of the event queue in the browser? Is there any kind of something like that? AJ:      So if you are using JQuery, there are ways to inspect jQuery’s internals which are soon going to be exposed to get it. Then there are also discussions that the browser exposing the callbacks and so John Resig of jQuery occasionally asks like, what can we do, to improve the browser for JQuery? One of the things on his list is always like; give me access to those for callbacks. That way if we have that, it will be easier for us to use that system instead of doing our own. Basically, if you use jQuery, under the events, sorry the new data cache and you can go and inspect that and there is an events property in there. However that is ultra-ultra private it is perhaps used for debugging not for actual code. But that does have the list of all the events and all the callbacks. CHUCK: Alright. Has anyone has something to ask or add? JAMISON:  I was going to say I have seen people do, what Yehuda was saying, where they create a loop and check the time and just do that in the loop, because they don’t understand the setTimeout or they try it to make it synchronous. I've seen that, where they will force it to wait a second synchronously and that's just a terrible idea. JAMISON: So a really common case where this is done on purpose is, the ad companies, they would like to be notified when you leave the page. They do not want to have to follow the normal rules. So what they do is, they register onUnload hook, but on onUnload hook will run and basically the browser doesn't say when you're done, will just sit there waiting any callback it’s like immediately shuts you off. So, ad manager, actually, I would really like to know, when you left. So I'm going to make an AJAX request or whatever it is that I would do, and them and I'm going to sit on this spin loop forever waiting for like “n” amount of time like 10 seconds or 5 seconds, until I allow for onUnload hook to finish. Basically what that means is sometimes you may notice you close a tab, you're like why is this tab not closing? Why is it taking several seconds? It’s because probably, there is an onUnload hook registered on that page that is intentionally blocking the browser from closing, so it can force the AJAX request to complete. Yeah I think I've heard, and am not sure if Chrome has done this, but I think that Chrome is going to not allow this to happen. Like it is going to force close onUnload hooks, but obviously that has implications for ads and blah, blah, blah. JAMISON:  I've never thought of that before I had that problem where we wanted to delay it. CHUCK: So your example when you're using setTimeout and then it checks the time and things like that, you're talking like there is a better way to do that? JAMISON: Well I think what AJ was saying is that instead of using setTimeout people are like, they just do a loop and then inside the loop they do like, the var date = new date and inside that loop they are like, if  newdate – date is bigger than a 1000, break. I would like to wait 1000 milliseconds now and so they do that. What you should do is you should use setTimeout. CHUCK:  Okay. YEHUDA: That is different from what I was saying before earlier on. CHUCK:  That makes sense all right. While we're still kind of getting to the flow on this podcast we are going to go ahead and get into the picks. I used to explain, like every time, on Ruby Rogues what they are. If you're not familiar with the format of this podcast, basically a pick is something that we enjoyed that we used, that we liked it doesn't have to be code related and it's just you know it's just kind of a chance to share what we are up to and things like that. So you know sometimes people will pick things that they are working on right now. Sometimes people will pick something like TV shows and stuff that they are listening to. Well will do the picks and we’ll start with AJ. AJ:      Why don’t we start with you so I get the format of this better? CHUCK: Okay. We will start with chuck. JAMISON:  Rejected. CHUCK: So as you could tell I'm not as familiar with JavaScript as I am with, say, Ruby or some of the other languages that I programmed in and so to kind of get ready for this, I started reading JavaScript: The Good Parts and I'm not expert enough to say that everything in there is terrific or not but they are definitely some concepts in there that I was already familiar with and then there were some other concepts in there that really were clarified for me. So like the prototype thing that you have with inheriting from an object. You and the functions stuff. Some of the function stuff that's there. It really helped clarify that stuff.  So that's definitely one of my picks is the JavaScript the good parts. One other pick  that I have, and that is something that my wife and I have gotten into, we have a Netflix subscription and we can watch the Netflix movies through our Blu-Ray player through the wireless and we've really been enjoying Merlin the adventures of Merlin and it’s a BB- BBC show (man and cannot talk today.) It’s a BBC show and basically, if you like the canonical Arthurian Legend then this show probably isn't for you, because they have changed a lot. But it's a fun show to watch and it's really, it takes some interesting turn here and there. So those are my picks and anyway Yehuda, why don't you go ahead and be next since you are now a veteran of the picks because you were in Ruby Rogues this morning. YEHUDA: Yeah I feel weird I cannot think of anything obvious that I didn't know what to say. I'll just repeat what I said this morning. Okay. So a couple of books. So I recently started a company called Tilde and I’ve sort of been thinking about a bunch of entrepreneurial topics for a while and sort of anticipation and joining a company. And two books that I really recommend if you are either starting the company now or thinking about starting a company or if you are in a company where you have full control over certain product design and all shipping and all that. Would be link start-up book which I think is like sort of- CHUCK: Cut out there for a second Yehuda. JAMISON: I just Googled “Tilde” and the first thing I found was this enormous picture of Arnold Schwarzenegger. I do know if it's related to Yehuda company or not. But probably it is. CHUCK: Yeah, it looks like he dropped off again. Peter, why don’t you give us some picks and when Yehuda comes back we will let him finish. PETER: Okay cool just so you are aware Charles, BBC have also done a thing called Sherlock which is bringing reading Sherlock Holmes out to modern day which is really, really cool as well so. Just watch out for that for anyone who is on BBC at the moment. AJ:      It’s pretty good. CHUCK: I heard it's good. PETER: It's pretty good. Which I didn’t wanna watch it at first but I looked right into it so yeah, good stuff. I'm actually going to ignore the advice about not going to be coding stuff. There is article by John Resig which is actually really relevant to today’s episode called “How JavaScript Timers Work”. I'll give you the link so that can go on the show notes so that can be useful for people that have been listening to this. So it’s got a really cool diagram together about it. Other than that of course I really should plug the conference I'm co-chairing which is Fluent Conference, which is the JavaScript Conference by O’Reilly. I'm not going to say much about it but you can see it through fluentconf.com but not today because it's the black out and O’Reilly’s taking part in that. Another thing I’d like to recommend is Reg Braithwaite, you may have heard of him. He goes by “Ragan Wald” hacker news and on Twitter so on. And he's doing some really cool blogs posts about Java script recently. The most recent of which is called Captain Obvious on JavaScript. He talks about how JavaScript functions work and kind of like the whole idea of being out to replace any expression by a function. He really digs into that idea. So I'm very keen to support his works. He does some really good blog post. I’ll send a link for that over as well. CHUCK: Alright. AJ. AJ:      Okay so since this is our first episode, I feel like mandatory to mention the Crockford Videos and YUI Blog. I take a lot of my coding style from Crockford recommendation and to have just learned a ton by watching those videos and re-watching some of them, because it was way over my head the first time I ever came across them. So I have a link for that. And also I just found a really cool Node module that lets you send SMS text messages through Google Voice. That is pertinent because we are testing some software. We wanna make sure that our devices are up continually and that there are no crashes or stops in service. And so I'm thinking to use this along with our tests to have it send me a text message anytime something goes down. So I'm reeling to that. It’s called Node Google voice. CHUCK: All right sounds really cool. I may have to look into that. Jamison. JAMISON: My first one is definitely 750words.com. So it's 750words.com. It’s like it's my secret diary thing. It’s kind of based on the idea that you should do your morning pages like write some every time you get up in the morning to kind of get your brain flowing. I have been doing it for a couple of weeks and it's actually made a difference. Lots of times it's full of like, Oh! so early I'm so tired when I write but I found that it helps me kind of reflect back my life and also just have creative time built into think about stuff. So that's a great one. And then my other one is (it's kind of an old one) but there's a book called Working Effectively with Legacy Code. It’s a big old nerdy programming book, but it's basically how to work with code that isn't under test and how to break it up so that it is testable so you can maintain it and change it without fear of breaking stuff. So those are my picks. CHUCK: Alright sounds good. Really quickly, just a few business items. I am hoping to get this into iTunes pretty quickly and so if you could give us a review that will be great. I also mentioned that you know if you're used to some of the other podcast that I do, they kind of have their own flow and we are kind of new to talking to each other, so, give us a few weeks to kind of gel and then thing I think these are really going to take off.  I know that there were some continuity issues before. So other than that, go check out Fluent Conf for Peter. It sounds really interesting is that going to be in San Francisco? PETER: Yes San Francisco, May 29 through the 31^st. CHUCK: And out here in Utah they are also planning a JavaScript Conference but I don’t think they finalized the dates on that yet. If you want to submit to their call for proposals, you can do that at UtahJS.com. Is it .com or .org? JAMISON:  I think its .org oh, its .com. CHUCK: Okay and other than that if you have feedback, go ahead and you can email me chuck@teachmetocode.com or you can leave comments on the blog at JavaScriptjabber.com. We will catch you next week!