In this episode the panel discusses various programming topics, and whether or not they are required knowledge for JavaScript programmers. This includes topics such as scopes and hoisting, closures, the event-loop, and the behavior of this. For each such topic, the panel discusses whether or not JavaScript devs are required to know and understand them in order to write better code, or pass job interviews, or to understand existing codebases. Alternatively, if these are topics that JavaScript developers don’t need to know, and maybe should even avoid.

Sponsors

Panel

Links

Picks

AJ

Follow JavaScript Jabber on Twitter: @JSJabber

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel we have. Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv. 

CHARLES MAX_WOOD: AJ O'Neil. 

AJ_O’NEAL: Yo yo, coming at you live from Sunny Pleasant Grove. 

CHARLES MAX_WOOD: Steve Edwards. 

STEVE_EDWARDS: Howdy from Portland. 

CHARLES MAX_WOOD: I'm Charles Max Wood from devchat.tv. And this week we're gonna be talking about the things that every Jalas, Jalascript, hey there we go, things that every JavaScript developer must know. 

 

A couple of years ago, I put out a survey asking people what topics they wanted us to cover on devchat.tv. And I got two overwhelming responses. One was from the JavaScript community. They wanted a React show was from the Ruby community and they wanted an Elixir show. So we started both. The React show though is React Roundup and every week we bring in people from the React community and we have conversations with them about React, about the community, about open source, about what goes into React, how to build React apps and what's going on and changing in the React community. So if you're looking to keep current on the current React ecosystem and what's going on in React, you definitely need to be checking out React Roundup. You can find it at reactroundup.com. 

 

CHARLES MAX_WOOD: So Dan, you suggested this. Do you want to give us a little bit of background on this? 

DAN_SHAPPIR: Yeah, sure. A while back, we recorded an episode, or we thought we recorded an episode. 

CHARLES MAX_WOOD: We didn't quite record it. 

DAN_SHAPPIR: It was really interesting. Yeah, we did an episode, but ended up not recording it. 

CHARLES MAX_WOOD: That was my fault, sorry folks.

DAN_SHAPPIR: in which we discussed, talked about things that you need to pass a JavaScript interview. Now it was a good episode and we considered doing it all over again, but I kind of decided to maybe try to generalize it a little bit. So rather than thinking about things that you need to know just in order to pass an interview, I thought maybe to do an episode about things that you need to know, period. Now it might be because you need to know these things in order to pass an interview, but it might be that you just need to know it in order to be able to do your job. You know, there are certain features of JavaScript that we definitely should be using. Or it might be things that maybe we shouldn't actually be using, but we may encounter in existing code bases. And then we need to know what they do and what they are because otherwise, you know, we'll be confused and not know what to do with it. And we'll have a misunderstanding of how the code actually operates. I basically tweeted out to the Twitter verse a question, kind of soliciting people to give me a list of things that they think that JavaScript developers need to know. And I got a lot of interesting answers. I'll probably add the link to that tweet to the show notes. And I also added some of my own. And I came up with a list that's way too long. And now AJ thankfully helped. Organize it a little bit more rationally like grouping things together so I thought that maybe I'll start by let's say reviewing at least the first part of the list because like I said, it's too long we probably won't have time to go over all the items and Afterwards we can start debating them like see whether we agree or disagree that these are things that JavaScript developers actually need to know if they aren't why not if they are why? Maybe we also talk a little bit about what they are and what they mean. AJ, you're still moving things around. You're confusing me. 

AJ_O’NEAL: Just thought this was a bad place to start, so I just put that below. 

DAN_SHAPPIR: Okay. But left something below. You should actually put pull number seven to like number one or something. Otherwise it doesn't work. Anyway, so here's the list I've got going. Now AJ, stop moving. 

AJ_O’NEAL: So you just told me to move it. You just told me to move it. 

DAN_SHAPPIR: No, not just one. Now let's talk. Okay, so yeah, no, it's all good. So the first three bullets that kind of go together are, the first one is scopes, hoisting, and the temporal dead zone. Number two is pure functions and higher-order functions. And the third one is closures. So these three kind of go together, and we can discuss why it is that they actually do go together. The next one, which kind of stands on its own, is event loops, the message queue and microtasks. Then another group that we have at number five, it's the behavior of this in JavaScript, the butt of many jokes. Six, which is associated with it, is a prototypal inheritance. Also, what is the prototype property? What is maybe the underscore underscore proto property? Feature detection and polyfills, which is really associated with prototypes in JavaScript. Then the next subject is promises and a sink awaits. We put them together because despite what a lot of people may wish, they have to kind of go together. The next one is regular expressions. And then the final two that I have for this part are method chaining. And if we'll get around to it, then the JavaScript number slash math system. There are other like 10 items. So if you tweet it back at me with an item that didn't make it into the list, it's still actually in the list. It's just that I'm pretty sure we won't be able to get to it this time around. We'll probably need to do a follow-up episode. So are you guys ready to start? 

CHARLES MAX_WOOD: Yeah, I'm looking forward to fighting over the first three for the next hour. I mean, yeah. 

DAN_SHAPPIR: Okay. So the first one is Scopes Hoisting and the temporal dead zone, I kind of bunched them together because they, they are part of the same thing. Sort of anybody think that it's something that a JavaScript developer can do without knowing or understanding 

AJ_O’NEAL: what is the temporal dead zone? The wrong place to start, but I don't know what it is. 

CHARLES MAX_WOOD: You want it. You're okay. So let and const are hoisted. So maybe we should back up and talk about wasting for a minute. So if you declare a variable with var letter const, it hoists that declaration for var, and it hoists the definition of at least the variable to the top of whatever scope it's in. And then the temporal dead zone for let and const is that they aren't actually initialized until that place where you actually put them into your code. So if you have const halfway down in your file, the temporal dead zone is everything above it for that particular variable. And if you try and assign it, it'll give you an error. 

DAN_SHAPPIR: Exactly. So I would even start with scope, which is why I put it first. So scope is, we feel like everybody knows what scope is, but there are really a couple of scopes in JavaScript. So first of all, you've got the global scope. We've got the global scope, which is either everything on the window object or the global object in node or the module-level scope in ES modules. So that's kind of the top level scope. And then you've got scopes in functions, and you've got block scopes. So up till ES6 or whatever. 

AJ_O’NEAL: There's one more scope. 

DAN_SHAPPIR: Yeah. Go for it. 

AJ_O’NEAL: Try catch. 

DAN_SHAPPIR: Correct. But let's ignore that for now. It's just confusing enough as it is. So up until ES6, with the exception of try-catch, we really had function-level scoping. So every variable that you declared was either in the global scope or was in the entire function in which it was declared. So regardless of where you put the var, it kind of lived within that entire function. And the second thing that we had is something called hoisting, which was originally introduced into the language so that you could put function declarations at the bottom of a file, but use them before they were declared function at the top and then the function that it depends upon I actually prefer to put it below that function But for that to work those function declarations need to be like pulled to the top or Hoisted now an interesting side effect is that hoisting is not just for function. It's for all variables That are at least declared with var. So regardless of where you put the var in a function It's as if you put the var at the top of the function. So if you have var A equals three, what actually happens is that the declaration of var gets pulled to the top, but var is actually assigned undefined. And only when it gets to that instruction, it's actually assigned the value three. But as Chuck correctly said, if it's let or const, then there are two changes. First of all, it's block scoped rather than function scoped. So the scoping is just from the open brackets until the curly brackets until the closed curly brackets. Which by the way, also the four, if it's a four, well four is like a complete mess, but it can also extend a little bit outside of that block. 

AJ_O’NEAL: That you can put open and closed curlies anywhere in the code to create scope. 

DAN_SHAPPIR: Yes. Correct. 

AJ_O’NEAL: Which is something that is very strange to me to see introduced into JavaScript. 

CHARLES MAX_WOOD: It's not just me, okay, good. 

AJ_O’NEAL: Well, I mean, it's in other languages, but for a very particular purpose in JavaScript, it's just kind of like, Well, we introduced let so now we have to put this weird syntax in here to support the odd quirks of let, you know, it's just, 

DAN_SHAPPIR: Yeah. But on the other hand, before we had that, we would have the self, um, what's it called the self-executing functions or 

AJ_O’NEAL: immediately invoked function expression. 

DAN_SHAPPIR: Exactly. And then, and now we can just have a block and achieve the exact same effect. So if we wanted to have a variable or that was like local to some area within that has certain function, we would create like an iffy within that function. And then that variable just lived within that scope. Now we can just put a simple block and use that in const. 

AJ_O’NEAL: So I'm not familiar with that way. I only used iffys to to give scope to a file back before there were all these bundlers and stuff? 

DAN_SHAPPIR: The bottom line is that since ES6, since modules and block scoping, I just don't use if-is that much at all. Like if we talk about things that you need to know in JavaScript, I would put this in the category of things that you need to know because you will likely encounter them in older code, but you shouldn't be using it anymore probably because you can just use regular old blocks or ES6 modules. 

AJ_O’NEAL: Yep, I agree. 100% agree. 

CHARLES MAX_WOOD: I don't think I've used it either since I started. Basically, I use ES6 modules in import. 

AJ_O’NEAL: I'm still on the list. 

DAN_SHAPPIR: And like Chuck said, the temporal dead zone is that weird thing because people think that with let and const, they aren't hoisted. The reality is that they are hoisted, but they aren't assigned a value. So if you try to use them before their declaration, you're trying to use something that has no, it's not that they have undefined, they have nothing. It's like what is nothing. They have no value assigned to them, not even undefined. So you can't use them. And if you try to use them, you get an exception and that's the temporal dead zone. 

AJ_O’NEAL: Is that only if you're in strict mode or is that anytime? 

DAN_SHAPPIR: It's anytime you're in a block that has constant net in it. 

AJ_O’NEAL: So we've got not defined, undefined. And then, 

CHARLES MAX_WOOD: yeah, basically. Yeah. It did. It created essentially another no undefined type. 

DAN_SHAPPIR: Yeah. I think I would say that a JavaScript developer needs to know scoping and needs to be aware that hoisting exists, but the temporal dead zone is kind of,

AJ_O’NEAL:  if you're writing clean code, you shouldn't encounter it.

DAN_SHAPPIR: Well, yeah, probably you just need you don't need to know what it's called. I think again, maybe you'll ask by some smart aleck person in an interview, but just don't use let and const before they're declared. 

AJ_O’NEAL: Just don't use let and const. Uh, that, that, I'm just teasing. I'm just teasing. 

DAN_SHAPPIR: Actually get if, uh, if, you know, Kyle Simpson, getify is, is a really an advocate of using a VAR. So if you'd say, If Kyle was on this call, Kyle would say use var because it var is great. And this is the way that JavaScript has always worked and why fix something that ain't broken. I personally, and it's a legitimate opinion. I personally like a block scoping, perhaps because originally I came to JavaScript from block scope languages. So I'm, I'm kind of used to it. And also I'm just want to use const. So it's not so much about the block scoping, it's about the constness of it that I like. So, but that's like a whole total like show on its own. 

CHARLES MAX_WOOD: Yeah, there are nuances to it that are worth discussing, but that's not what the show's about, so. 

DAN_SHAPPIR: Okay, so did we finish number one? 

CHARLES MAX_WOOD: Yeah, I have to generally agree with you, though I think, yeah, you don't need to know what the temporal dead zone is called, but you need to be aware that it exists. And I just want to make that distinction right. You don't necessarily need to have the term name memorized, but you need to know that it's there because otherwise You may be confused why let and const start behaving the way the var does 

DAN_SHAPPIR: I would argue that if you're going to start using let and const instead of var Then you should know why you've decided to use them instead of var. 

CHARLES MAX_WOOD: I agree with that as well 

DAN_SHAPPIR: Now it might be that you're now it might be a bit of an unfair statement when directed to somebody Coming in to the language right now through a boot camp where they might be teaching them let and const instead of r without explaining, you know, why that is. So they're just using it because their teacher told them to use it and they don't like understand this distinction. But otherwise, that's what I would think. 

CHARLES MAX_WOOD: Yeah, but that's a common beginner space anyway. You're doing a lot of things they're telling you to do without necessarily understanding the why. 

DAN_SHAPPIR: Yeah, that's definitely true. The next one is kind of putting a functional like angle on the whole thing. And that's number two was a pure functions and higher order functions. Do we think that all JavaScript developers need to know what these terms mean or maybe just some of them or not at all? Maybe if you're doing object oriented JavaScript or just procedural JavaScript, you don't need to know what they are. What do you guys think? 

AJ_O’NEAL: I don't think that like what I think is important. What if you're just learning JavaScript you'd come into naturally without knowing any different which is just that a function is A variable essentially. I mean, I think that's what you mean by higher order functions Is that a function is just a variable you can pass it around you can do stuff with it, right? 

DAN_SHAPPIR: Essentially. Yes, it's a value rather than a Value sure sorry. Yeah a high a high order function is literally one or two things It's it's either a function that receives a function as an argument or provides a function as a return value. That's essentially all it means. 

AJ_O’NEAL: Oh, I was thinking first class functions. 

CHARLES MAX_WOOD: Yeah. And so I think you do need to understand higher order functions because it's a very, very, very common pattern in JavaScript. Well, that's what a promise is. Yeah. 

AJ_O’NEAL: Yeah, promises. Mostly. Yeah. 

DAN_SHAPPIR: Yeah, promises the dot, the then of a promise takes a function. So yeah, so the then is a higher order function.

STEVE_EDWARDS: So, Dan, talking about these higher order functions, what's the one thing I guess we haven't really talked about or it would be the benefit of using one? What is the purpose of something like that search? 

DAN_SHAPPIR: Well, I think first of all, in the context of JavaScript, I think they're one of the languages most powerful features. The fact that you can give functions and that you can return functions. Now the whole asynchronous nature of JavaScript is built regardless of whether you use callbacks or event handlers or promises is built on passing functions in. Now it's kind of obscured to you if you're using a sync await, but with all the other patterns it's kind of dependent on it. For example, add event listener. You can't do that without using a higher order function effectively.

AJ_O’NEAL: What, so in, in the event oriented nature of what we've traditionally seen in the browser, there used to be, you could get an element and call say dot on click, or you could call element dot add event listener click. Would it still be considered a high order function if you can just assign it to an object that gets calls as opposed to pass it as a value to the event listener when they both accomplish the same task. 

DAN_SHAPPIR: I think, well, first of all, internally, it's actually implemented as a higher order function. So internally, when you do the onClick, it's actually what's known as a setter. And it's actually invoking, when you're assigning the property, it's actually invoking a function. And it's passing that function that you assigned as a variable into that function. So certainly, on the inside, it's a higher order function. But even on the outside, ultimately, it behaves like a higher order function. It gets it's retained and gets called. Yeah, I think like with the temple dead zone, you might not like need to know the term, although it definitely helps, but I think you need to be aware of the pattern. Yeah, well, and like Chuck said, so much code in JavaScript is built on it. 

CHARLES MAX_WOOD: Well, I mean, even some of the ways that things in, I mean, in React, for example, they have higher order components, which kind of function on the same idea is just that components are a little bit more complicated and structured idea than the simplicity of a function in a higher order function. And so you see this pattern actually extrapolated out to other areas that you're going to run into as well. But yeah, yeah, higher order functions is a common enough thing to where I think you need to understand what, what they are. And I think what one of the fundamental things here in AJ pointed it out is that functions are values. And so you have to understand that first and then understand that then a higher order function can take a function as a parameter and it can return a function as a return value because it's just a value. And once you understand those things, then you kind of get the point and then we can dive into closures. But I mean, that's, yeah, I think higher-order functions is kind of a critical thing. Pure functions on the other hand, I think it really depends on the code base and whether or not they're even used or assumed? 

DAN_SHAPPIR: Pure functions are, again, the definition of a pure function is actually really, really simple at the end of the day. It's just two points. One that given the same arguments, it would produce the exact same value. And the second thing is that it doesn't have any side effect, which means that it doesn't like change any global variable on the side. That's essentially all that it means. Now the benefit of pure functions is more difficult to understand, I think, than the actual concept. So I think that pure functions, while I would like to think that all JavaScript developers should know what they are and use them, don't actually... it's not actually like mandated knowledge, I would say. 

CHARLES MAX_WOOD: I also want to just put in on that, that in web development, when you're using systems that assume pure functions, they, it's either stuff that goes into just pure functionality. Otherwise, I mean, it's web development. And so there are going to be side effects, right? It's going to call back to the server and modify the global variable known as your database or your backend, or it's going to, you know, it's going to have a side effect where it updates the DOM or things like that. And so anyway, these systems that usually have mechanisms for the side effects that you have to be aware of. And so I find that the exceptions, when they say it's a purely functional system, they have a system of exceptions built into that, exceptions to the rule of pure functions. 

DAN_SHAPPIR: Well, every system has to have side effects, otherwise there's no point in running the code. 

CHARLES MAX_WOOD: Yeah. 

AJ_O’NEAL: The system as a whole, as opposed to a particular function. 

STEVE_EDWARDS: Yeah, but a particular function would be a pure function. 

DAN_SHAPPIR: Yeah, the idea with pure functions is that you're usually isolating your side effects to place it to like having most of your code without side effects because it's easier to test this way and easier to reason and then like isolating your side effects. But still, I think that while I definitely think that people have to have an understanding of the concept of higher order function of being able to like you said about what AJ said of being able to pass functions around like values, pure functions are very nice to know. But I don't think you have to know that. I agree. 

AJ_O’NEAL: So one more thing on this. So I just want to try to clarify this. When I think of pure function, the word that comes to mind for me is lambda. And that is a function, basically, that does not have closure, does not have access to something that is outside of it. It is whatever is defined as input parameters in the lambda and whatever is returned, that is the full scope of it. So a pure function is not necessarily quote-unquote feature of JavaScript, it's if you take all the features of JavaScript away, you're left with a pure function. 

STEVE_EDWARDS: So am I the only person that thinks of revenge of the nerds when they hear the term Lambda? 

DAN_SHAPPIR: No, you're not. But we are all showing our age. Maybe we'll choose that movie as a pick. 

STEVE_EDWARDS: Lambda, Lambda, Lambda. 

DAN_SHAPPIR: I just want to mention that actually the definition of a Lambda, and not AWS Lambda, but the Lambda in the context of functional programming, is basically just that it's a function without a name. It's an anonymous function. That's all it means. So everything else that you associate with a lambda might be something that you usually do with lambdas or how you usually construct lambdas. But to be a lambda, you just don't have a name. That's it. 

AJ_O’NEAL: Oh, interesting. I always thought of it from the Ruby perspective because that's where I learned it. 

DAN_SHAPPIR: Like if you're using an array filter, right and you're creating a filter function that these days would likely be an arrow because that's like the most condensed way to write it. And you know it's a one-time thing. You're only going to use that function within that filter expression and it's pretty clear because it's such a succinct function. It's pretty clear what it does. So you don't actually need to give it a name and that's just it being a lambda. That's it. 

CHARLES MAX_WOOD: Anyway. It's just that it's a technical type in Ruby, whereas in JavaScript, it would just be a function that doesn't have a name on it. 

AJ_O’NEAL: Yeah. I get that now. I, I've been so tainted by my Ruby ears. 

DAN_SHAPPIR: Look, I've been tainted by basic. I'm still trying to wash that taint off. So, uh, Ruby is... 

AJ_O’NEAL: That's a stain you can't remove, Dan. 

DAN_SHAPPIR: Yeah. That you'd be saying. There's a lot of truth in that actually. 

CHARLES MAX_WOOD: Uh, your SynthB is Ruby, right?

DAN_SHAPPIR: Yeah, exactly. The next one I have on the list is rather a complicated one. It's closures. 

AJ_O’NEAL: And I don't feel like this is that complicated though. I think it's... 

DAN_SHAPPIR: You define it. 

AJ_O’NEAL: Yeah. Well, a closure, it's just, uh, if you can look at code and you can see that there's a variable on say line seven, and there's a function declared that is inside of that block and that function has access to that variable. That's what a closure is. Closure just means if you look at the indentation, everything that's inner indented has access to everything that's outer indented. 

DAN_SHAPPIR: I have to tell you that having come to JavaScript from languages like C, mostly writing code in C and C++ in the early days, it took me a while to wrap my head around closures. And it's funny because I actually did. 

AJ_O’NEAL: Well, C doesn't have scope. I mean, it's got one type. 

DAN_SHAPPIR: That's not true. You do have it. 

AJ_O’NEAL: It doesn't. It does. Like it does not have layers of scope. It doesn't. 

DAN_SHAPPIR: It has just two layers of scope. You've got the global scope and a function scope and that's it. 

AJ_O’NEAL: In a loop kind of sorta, but yeah. 

DAN_SHAPPIR: And, but you can actually return a function pointer or provide the function pointer into, you know, in, in C. And so you can move functions around as if they were values, but they don't carry their scope with them. They don't have closures, or at least they didn't have. Maybe now in modern C they do. I haven't kept up with the standard. I know that C++ has got some sort of closure capabilities in later iterations of the language. Just because closures are such a powerful mechanism, by the way, and they're especially powerful when you combine them with high order functions, which is why I mentioned prior to this conversation that they have to go together. Closers really have a meaning when you return a function from a function, let's say, or something like that. So let's say I declare a function A within function B and I return function A from function B, then function A carries with it the values of other variables that live within B within that invocation of B actually. And it's not so trivial, I have to tell you. I have two kids learning programming and this whole thing is not trivial for them. 

AJ_O’NEAL: Interesting, because I just found it to be, to me it seemed more intuitive than the way that C is. When I compare JavaScript and C, I think, oh, JavaScript makes sense. C is the one that's weird in that regard. 

CHARLES MAX_WOOD: The way that I look at it is that I have this idea of sort of temporal lines of code, in other words, lines of code that are near each other. And so the information that's near each other tends to move together. And so closures is just another mechanism for that, right? Because anything that's defined around the function definition, meaning within that scope or any scopes outside of that scope, you know, so anything that it can see, it just picks that up and carries it with it. And that way I can go back and I can make the assumptions that the stuff that's defined around it is stuff that is within that closure, generally. 

DAN_SHAPPIR: By the way, if you recall from our conversation on the My JavaScript story that you did with me, I now recall that I actually started using JavaScript before it had closures. And we had to jump through terrible hoops to achieve similar behavior. Closures are awesome. Let's put it this way. My idea, my thought is that closures are something that you have to know as a JavaScript developer. 

CHARLES MAX_WOOD: Oh, 100%.

DAN_SHAPPIR: And if you don't know or understand what closures are, then do invest the time and effort. It's probably the most important thing maybe on this list that you might not know. And if you don't know it, then that's the first thing that should be at the top of your list. 

AJ_O’NEAL: And I'd say for any modern language, I don't think that any modern language doesn't have closures. And for reference, Python is an ancient language, not a modern language. 

CHARLES MAX_WOOD: I have to agree with Dan. If you've been writing a lot of JavaScript and you don't understand closures, I'm sorry that you've been writing it in a painful way. 

DAN_SHAPPIR: Oh yeah. 

CHARLES MAX_WOOD: Because you have been running into stuff that has been driving you nuts. And this will clear a ton of things up for you. 

DAN_SHAPPIR: And the good thing is that you can probably find a whole bunch of good explanations online of what closures are and how they work. 

CHARLES MAX_WOOD: Yeah. I really like the MDN explanation on closures. They do a terrific job. 

DAN_SHAPPIR: Yeah. MDN is awesome. 

CHARLES MAX_WOOD: Well, let's make sure we link that in. 

DAN_SHAPPIR: Yeah. So the next one on the list, going on to the next topic is event loop, the message queue and micro tasks. What do you think about those? 

AJ_O’NEAL: I think the event loop is absolutely important. I mean, that you just, that is why JavaScript is performant as a server side language and why it can work at all as a browser language. 

DAN_SHAPPIR: I totally agree. I think that the event loop is, is a must. No, you can't really understand. Like you said, it goes beyond JavaScript, the language. It goes to the environment to which JavaScript runs in. And I think it goes to the very core of the language of why it was designed the way that it was designed, why it can be a single threaded language and still be able to work. It has to do with event loop. Event loop for those of you. The message queue is the basis for the event loop. So again, a very brief explanation. The way that the browser work, I'll do. I'll. I'll explain in the browser, AJ, if you'd like, you can also explain how it relates to Node. But in the browser, whenever something happens, then it's put into a queue. The fact that it happened. So it might be a file that finished downloading, it might be some user interaction, it might be a timer that fired. Whenever one of these things happen, the fact that it happened and the data associated with it happening is put into a queue. And then the browser itself just goes and takes the next thing from the queue and does something with it. And that very often that does something with it is invoke some JavaScript code and hand this information from the queue to that JavaScript code so that the JavaScript code is able to process it and react to it. So for example, if it's a user click. You get associated an event handler that's just some JavaScript function. It gets invoked and it receives an event object that describes that click. And it can then respond or react to do something as a result of that click. 

AJ_O’NEAL: So I like, I like to compare this to when you go to Starbucks, like you get in the queue in the British terminology of the word queue and you just like you said, 

CHARLES MAX_WOOD: the guy from James Bond queue. No, not that British queue. 

STEVE_EDWARDS: Either that or Star Trek The Next Generation. 

CHARLES MAX_WOOD: There you go. 

AJ_O’NEAL: So anyway, you're in a line in the coffee shop that's an ordered line where things get processed as you come up to the cash register. 

CHARLES MAX_WOOD: First in, first out. 

AJ_O’NEAL: Yep. You get your receipt and then it stops being first in, first out at that point because once you have your receipt, it's whatever worker is available to do the work that needs to be done that can be processed by what they are capable of doing. And then when the, you know, if there's only one of the latte machines working, then you've got to wait for your latte. But if there's more of the coffee machines working, you don't have to wait for your coffee, whatever. And then they call you back by your number, by your reference, and then give you what has been, uh, you know, what was part of that transaction or that receipt or that, uh, I forgot the word that you had actually used Dan, but that's how I like to think about this one because it just perfectly maps to the real world, to the way we're used to life working. 

DAN_SHAPPIR: Yeah, there's only one caveat to that, which I would make, that in a sense, the message queue is more like the queue in an ER room than in a coffee shop, in which it's actually in a priority queue. That means that some things are more urgent than others, and therefore handled sooner, even if there are other things quote unquote ahead of them in the queue. So like if you're waiting for some stitches in the ER waiting room, but then they bring somebody in who's like, you know, has been in a bad car accident and they'll probably handle them first and then just have you wait, even though you were there first. So there are certain things that the browser prioritizes above other things, even if those other things are already waiting in the queue. But other than that, that's I totally agree with your description. 

 

Are you stuck trying to figure out how to get to the next stage of your developer career? Maybe you're just not advancing fast enough in the job you're in, or you're trying to break in in the first place, or for whatever reason you keep going to interviews and it's just not working. You want to land that dream coding job, but it just doesn't seem to be working out. Well, Johnson Mez has written a book for you called The Complete Software Developer's Career Guide. He walks through each stage of the development career and all of the things that you need to do in order to move up, keep learning, keep growing, and find that next job that's going to get you where you want to go. So if you're stuck and trying to figure this stuff out, go pick up the Complete Software Developer's Career Guide. It's the number one software development book on Amazon. It's sold over 100,000 copies so far. I actually have friends of mine that reach out to me and go, hey, do you know this John Sonmez guy? Cause his book is awesome. So go get the book. You can get it at devchat.tv slash complete guide. That's devchat.tv slash complete guide.

 

CHARLES MAX_WOOD: Well, and what's interesting in that example is that the person who was in the car accident, they actually get brought in by EMTs in the ambulance, right? And that's why they get rushed past the line. Everybody else goes through the line like AJ was talking about. And so unless it comes through a specific mechanism, then, you know, then yeah, it does or doesn't get prioritized based on how it comes in and what it is. 

DAN_SHAPPIR: Now the one concept in this list, which is so...So I do think that everybody needs to understand the concept of event loop, every JavaScript developer, and probably also be aware of the term because it's just a term that gets used in the industry. I don't think that the message queue in and off itself is as important. Although if you're using things like workers or communicating between tabs or  this whole messaging queue mechanism and workers are certainly becoming much more mainstream. So maybe it's also becoming something that JavaScript developers need to know and at least be aware of. The micro tasks, I think, are the least important of these three. 

AJ_O’NEAL: That's the set immediate, right? 

DAN_SHAPPIR: Yeah, although set immediate is kind of deprecated. It's more associated with promises these days. Basically, what happened was is that in addition to that main queue that the browser itself has, the JavaScript engine maintains its own private queue. So when you resolve a function and there's code associated with that function, instead of handling that immediately, the JavaScript engine puts that in its own queue. Now, when the JavaScript engine is done handling whatever main task it browser's event loop and in the past it would just hand over control back to the browser's event loop. Now it first looks at its own private queue and clears up out its own private queue before it hands back control to the browser event loop. 

AJ_O’NEAL: So the question I have about that is is this something like a deferral where it happens right at the point of a return in a function? Or is this even later stage than that? 

DAN_SHAPPIR: Later stage than that. 

AJ_O’NEAL: So all functions would have to return back up to the root function. The full execution stack has to complete. 

DAN_SHAPPIR: Exactly. Like I said, in the past, it would have just been handed over back to the browser's event loop or the node event loop. Now the browser, the JavaScript engine clears up its own private queue before handing back control and the only reason that it does it really is has to do with performance because Jumping back and forth between the event loop and JavaScript is actually fairly expensive. 

AJ_O’NEAL: So you have to do the C++ calls? 

DAN_SHAPPIR: Yeah all this junk So they just want to get rid of all these things pending things that they know they're going to have to handle. They just want to do that as efficiently as possible. 

AJ_O’NEAL: So is that an implementation specific thing where Oh, or is that, or is that like part of the actual ECMAScript latest standard? 

DAN_SHAPPIR: I think it's actually part of the standard because it actually impacts the order in which things happen. Like if you've got a resolve promise, you know that the browser is not going to handle some keyboard event before invoking the, before handling that resolve promise. So, so I do think it's part of the standard. Now let's get to the, the one, the awesome one. The behavior of this, the butt of so many jokes. You know, there's this auto- 

CHARLES MAX_WOOD: I always say this keyword when I talk about it because otherwise I get confused. 

DAN_SHAPPIR: Yeah. So there's this awesome tweet. I have to find it somewhere. I forgot to prepare it in advance where he said, whenever I use JavaScript, I say F this shit, but I always don't know what this means. Um, so, so. So yes, the behavior of this in JavaScript or the this keyword in JavaScript is kind of different than almost any other object oriented programming language that uses this like in Java or C sharp or C plus plus or whatever. This is the behavior of this is really different than what it is in JavaScript. 

CHARLES MAX_WOOD: Yeah, i've also seen it called like self or Well, it has another cute it's the same key general keyword idea. 

AJ_O’NEAL: It depends on whether it's in a worker or if it's in an iOS worker, or if it's in the main thread. 

DAN_SHAPPIR: Yeah. But you're thinking about, about the global this. I would argue that that one is, is, is something that people think about a lot less about. I think people mostly get confused about what happens when you invoke a method in JavaScript and whether, and whether it's with apply or call or bind or whether you called it as a method or function. I think that's what confuses most people. Like in JavaScript, the this keyword is just an implicit, almost just an explicit argument. So it really depends on how you invoke that function. 

AJ_O’NEAL: So I stand with Crockford in that I believe

CHARLES MAX_WOOD: It sounds like a political statement. I stand with Crockford. Anyway, 

AJ_O’NEAL: well, it is, it is a political statement. That's it right there. Whatever he, who he's voting for. I'm voting for the same one. Just hope it's one I like. No. So he basically says, prototypes are stupid for you to use as a developer because prototypes are intended for patches to the language, not for you to do weird stuff and if you're using this, you're doing it wrong. Just don't use this. I, I that I'm putting a little bit of words in his mouth, but that's kind of paraphrasing. And I'm I'll link to, I think I don't, it's in one of his later talks in the Crockford on JavaScript series. It's like somewhere after the end of all things where he comes back around and says, actually I've spent a few more years in JavaScript and I realized I was wrong about prototypes, don't use them. And that's where I'm at. Like, I think there are edge cases, extreme edge cases where you may find that in certain engines. There might be a performance benefit or penalty from using prototypes, but in the general case, you don't, you don't need them. You can, you can do all of the quote-unquote object oriented stuff that you want without ever touching this. So I think you need to know enough about this to know not to use it. 

DAN_SHAPPIR: I tend to agree in that I also, as the years go by, find myself using this less and less if I can't avoid it, then I don't use this at all. Uh, sometimes you don't have a choice because some library or API that you're using kind of forces you to use it. But otherwise I really tend to avoid it. And it's becoming easier thanks to arrow functions that literally don't have a this, which is also another interesting behavior aspect of the behavior of this. 

AJ_O’NEAL: Ask yourself though, that statement is kind of paradoxical, right? If arrow statements don't have this, why would you have needed to use this without an arrow function? Because just because you're using a regular function doesn't mean you have to use this. 

DAN_SHAPPIR: Look, there's a whole interesting discussion here because there's a whole concept of a lexical scope, of a static scope versus a dynamic scope. And it seems that in generally speaking, static scopes are better than dynamic scopes and our readers can Google what I'm talking about here. So like I said, I tend to agree with you. That being said, there's still a ton of code out there that uses this. There are a lot of developers out there that are churning out new JavaScript code that for various reasons prefer the object, the quote-unquote object-oriented approach over the functional approach. And consequently, even though you can do object-oriented in JavaScript without this, thanks to closures, especially, but they do use this not JavaScript also has classes now, so that encourages people to use this. And even, 

CHARLES MAX_WOOD: I was going to say classes are prototypes. 

DAN_SHAPPIR: Yeah, but they are, but they encourage people to use this because they encourage a style of coding that's similar to Java. And if that's not enough, you've got TypeScript. That really encourages people to kind of write Java in JavaScript. 

AJ_O’NEAL: I wonder what large corporation that stole Java and renamed it C Sharp would possibly have been pressuring the committee to put that in there. 

DAN_SHAPPIR: Be that as it may. What I would say is that if I think you kind of said it, AJ, that you should know, you need to know what you're doing. You need to understand the behavior of this in order to not use it. 

AJ_O’NEAL: Yes. 

DAN_SHAPPIR: It would be the way that I really agree with this phrasing. Like you can't get away from it if you use it. But I do have to mention one more thing, is that it's becoming ever easier in JavaScript, the modern JavaScript, to avoid using this. Because you've got, like we said, you've got arrow functions which don't have their own this at all. We've got, we don't need to use apply anymore because you've got the spread operator and other things so you can really like, it's easier than ever to write code without ever using this. But on the other hand, I have a friend who was complaining about it. And when I responded that he can avoid using this, he said, yeah, but I'm working on this huge code base that has tons of this all over the place. 

AJ_O’NEAL: Var me equals this problem solved. I mean like that's, that's. That's how I did it when I was working in code that had this, I just do var me equals this, and then, then I wouldn't worry about anything else. And if I needed to use it six layers deep, I'd have me. And I mean, that was extremely common throughout code bases to see var me equals this. I mean, I've never seen it. Oh yeah. Well, self didn't work so well because then web workers and 

DAN_SHAPPIR: anyway, so interestingly, I don't even have that in my code so much anymore. I just use closures and arrow functions and I'm a happy camper. 

CHARLES MAX_WOOD: So, so then do you use prototypes? 

DAN_SHAPPIR: Because prototypes kind of push you at this. I'm only really only almost well, I can't say that I totally, absolutely never use them, but I strive not to use them. I mostly use them when I'm polyfilling. But then I'm just mimicking, it's just mimicking existing functionality when I have no choice. Like the happy path is that this polyfill doesn't even exist. But, so like I said, I cannot say that I absolutely, positively never ever use them, but I strive not to use them. 

CHARLES MAX_WOOD: So I guess my other question is, is then what mechanism do you prefer? And I'm not trying to pick on anything, but I'm trying to understand what mechanism do you prefer then for sharing functionality between different objects. 

DAN_SHAPPIR: Well, in most cases I affect effectively use closures, but I'm just, uh, 

CHARLES MAX_WOOD: closures and higher order functions. 

DAN_SHAPPIR: Yeah. I'm, I'm, I'm becoming ever more functional in my approach. 

CHARLES MAX_WOOD: Yeah. 

AJ_O’NEAL: So the approach that I like to take is the value object approach or the JSON approach, meaning that I have, uh, say var P equals capital person dot create empty object. And what that will do is that the create function is a function that I create a person object and I assign functions to that person object, like create, get, set, et cetera, and my create is just a constructor method. It just fills in default values. So my var P equals person dot create P is just Jason. I can Jason dot stringify, Jason dot parse. I can dehydrate, rehydrate that way. And then I pass P essentially almost like the way that you'd have this or self in a language like Python. And so all of my functions are grouped in the person object. And I just pass this value object around. And sometimes I do it differently, but I find that that approach is very simple. And it could, you could definitely argue that, well, it's nasty to have to pass in P as the first argument to your person methods. And you could do it the inverse way where you're creates method assigns all of those functions as well and that would you know behave similar but then you are dealing with actual this again. 

DAN_SHAPPIR: Yeah so well not necessarily I mean if you you can have it so so first of all yes it's really a question of taste effectively you've got a factory function I think that's the pattern name a factory. 

AJ_O’NEAL: Well that makes me feel dirty I don't I don't I'll change I'll change I'm sorry. 

DAN_SHAPPIR: But then yeah so it's really a question of taste whether or not you you're using your quote unquote object just as like a structure, a data store, and you've got functions operating on it, effectively passing it as like, like you said, the first argument or effectively passing it in as an implicit argument via by putting all these functions as methods on this object. It's just off. I just find it to be really matter of taste. Either way, I prefer to avoid using this and just use a closure to store all the common, the common state if I need to have common state. 

CHARLES MAX_WOOD: Interesting. 

DAN_SHAPPIR: Hopefully understandable as well. 

CHARLES MAX_WOOD: Yeah, it is, but yeah. 

AJ_O’NEAL: In the Crockford talk, which again, I don't remember which one it is, but it's something after the end of all things, he puts this up on slides and stuff and demonstrates what we're talking about. Like we both have a slightly different take on it, I think, than his, but if somebody wants to see what we're talking about in action. It's worth the three hour watch to figure out which one it's in, because you're going to learn stuff from every single one of those. 

DAN_SHAPPIR: Yeah, if, if Crockford is talking about it, it's worth you listening to it. I would say that to summarize though, to say whether or not it's something that's important for JavaScript developers to know and understand, I would say it's like this only slightly less so. So if, if you have to, to learn, to know this, even if you're just in order not to use it, then you should know prototypes, but then even more not probably not use it. You certainly don't have to use it. So it's like this just more so would be the way that I would put it. 

AJ_O’NEAL: When, well, we got the feature detection polyfills up next, but I think to me, prototypal inheritance and polyfills go hand in hand because when I look at polyfills, like I said, the purpose of polyfills is that the language was shipped out very quickly. It had to persist in browsers. The original idea was that we wouldn't be having all these transpilers and layered mechanisms, but rather that the language would be upgradable where you could upgrade the language to the newer standard with by, by adding prototypes to things like object and array. So you could get methods like map and filter as they were defined before they were implemented completely in browsers and get the best performance possible because JavaScript itself happens to be very fast and they have to do special tricks to make that JavaScript C++ bridge be optimal. And so the polyfill piece was just for the sake of being able to upgrade the language in tandem with the features of the language as specified, even when browsers were lagging behind. And that happens through array.prototype.map equals, et cetera. 

DAN_SHAPPIR: I agree. 

AJ_O’NEAL: String.prototype.trim equals.

CHARLES MAX_WOOD: I think there are two parts to understanding polyfills. I mean, one is understanding what polyfills are, why we have them, why we need them, and how they operate. The other thing, and this wasn't in our top 10, but I'm gonna hark to it for a minute, is the build tools like Babel and things like that, right? Where it's actually a syntactic change that your browser just isn't going to understand because it doesn't implement that particular part of the language yet. And so understanding why we have both of those things and the process that TC39 goes through to make changes to the language and why JavaScript works so hard to maintain backward compatibility and understanding those concepts, I think those are important for people to understand, but necessarily like how to build a polyfill or things like that is somewhat less important, I think. 

DAN_SHAPPIR: I agree that most people don't construct their own polyfills. Certainly they shouldn't. 

AJ_O’NEAL: Well, usually you just get the es7.js and include that script tag, right? 

CHARLES MAX_WOOD: Right, and it's smart enough to actually do the feature detection, so you don't even need to know that per se. 

DAN_SHAPPIR: Yeah, but I do, look, again, the purest in me tends to think that if you consider yourself, want to consider yourself like a quote unquote real JavaScript developer, then you need to understand the concept of feature detection and not do browser sniffing or stuff like that. And have a basic understanding of how polyfills actually work and their kind of association with the prototypes and etc. But the reality is, I would guess, that the vast majority of JavaScript developers can actually effectively get by without knowing this stuff. 

CHARLES MAX_WOOD: Yeah, I was gonna say that a little differently. Yeah, I was just gonna say that a little differently and that is that the stuff that we've talked to before this is more important for you to learn than you know, than what we're talking about now with feature detection and polyfills and how they work. You know, this I kind of see as one of the things that you're gonna learn after you've mastered kind of the basics of the language and understand how these other pieces kind of plug into it. 

DAN_SHAPPIR: I think that at this point, it's kind of worthwhile to plug your bookcamp. No, a lot of the stuff that we're talking about actually gets covered there. No. 

CHARLES MAX_WOOD: Yes. Um, in fact, I have a call in 10 minutes Q and a call for it. So yeah, we're going to do it again, probably in September, October timeframe. But yeah, what we're, I mean, we've covered kind of at a basic level and then Kyle's been around to answer some of the deeper questions on scope, scopes, hoisting, temporal dead zone higher order functions, closures. We didn't really go into the event loop, but behavior of the this variable or this keyword, prototypal inheritance, we talked about TC39 polyfills and build systems. We didn't really get into asynchronous programming promises and async await. I don't think we're gonna have time to on this call either, but we get into a lot of the other stuff here that we're talking about. So if you're trying to get your head around some of these basic concepts. The book camp really does, you know, fill in a lot of the gaps there. And you can go sign up for it at devchat.tv slash book camp. And yeah, we run it for 30 days. You get a video, you get exercises every day, you get a podcast interview that I did with Kyle. I must have talked to him for like 10 hours about just asking questions and clarifying stuff out of the book. You get a copy of the book. And yeah, it's a great way to learn this stuff. So I'm not going to plug it any longer. But I think it's well worth it, regardless of whether you're a new person trying to understand these basic concepts or whether you've been programming JavaScript for a while and you realize that there are these areas that are fundamental to how the language works that you just don't know. 

DAN_SHAPPIR: I totally agree. And like we said at the beginning, I think you need to know these things from the two perspectives, both of actually being an effective JavaScript developer. I mean, knowing them will definitely make you a better JavaScript developer you know, a real JavaScript developer even. And second thing is that especially these days when it's getting more challenging to get a good job, a good position, you're gonna be asked about some of these things in an interview. So understanding them is also important to actually landing that job to begin with. I think, yeah, I think you kind of alluded to the fact that we're running out of time and out of the 20 that we wanted to cover, we only made our all the way down to number seven. So at this rate, we'd probably need two follow-up shows rather than one. I think we've ran out of time more or less, no? The next one would have been Promises and Async Await, and the one after that would have been Regular Expressions. But I guess we'll save these for some future dates. 

STEVE_EDWARDS: I don't know, we don't use Async Await or Promises in JavaScript very much, do you? 

DAN_SHAPPIR: Yeah, for sure. 

AJ_O’NEAL: You can get by without Async Await just fine, but not without Promises. 

DAN_SHAPPIR: Set time out. Set timeout for me all the way. Well, set timeout and callback. 

AJ_O’NEAL: Oh yeah, yeah, yeah, yeah. Like I'm going to fire off these three events to go like fetch something from the Flickr API. It's probably going to get done within 750 milliseconds. Set timeout, done. 

DAN_SHAPPIR: Exactly. 

CHARLES MAX_WOOD: Yeah. 

AJ_O’NEAL: Great user experience, impeccable code quality. Works for me. 

CHARLES MAX_WOOD: I do have to say just on that point, it's interesting to me how often there are other things that kind of over the top of promises and or async await where you don't even realize you're using it until you're using it but 

DAN_SHAPPIR: By the way, just to the point that you were making so it's it's great that thanks to promises We don't do that set timeout with one second in the assumption that it will probably be done in one second But what about the the the inverse of that of just having these? Promises that you're waiting on with no timeout mechanism built in at all so that you end up stuck for like, I don't know, half a minute until the browser times out on the network request. I've seen that happen. 

AJ_O’NEAL: I think you just hit refresh at that point. 

CHARLES MAX_WOOD: All right, I've got to push us to Pcks. I'm going to be late for this call and I can't be late for this call. 

 

Are you building applications with Vue.js? Then you need to check out the views on Vue podcast. Every week we bring in a guest panelist from the Vue community and talk about the interesting things being built with Vue or the changes coming in its ecosystem. You can find it all at views on Vue.com. 

 

CHARLES MAX_WOOD: So Steve. Why don't you start us off with picks? 

STEVE_EDWARDS: All right. I'm going to go pretty simple here since I don't have any exciting new products or handy dandy things to talk about. So I've been doing some contract work over the past couple of months, which means I get paid for the hours I work and that's it. And so my pick is going to be a vacation. Even in cases like that, I decided that, you know, being able to get away after weeks of job hunting and then doing this work worth the not getting paid for a week just to be able to get away with my family and we were able to go down to the Oregon coast, which is very beautiful, but was also very cool, a little bit foggy during our week down there. But it was well worth it just to want to get together as a family because I've got two older kids, 2017, who are working and got their things going on and for me just being able to step away from a computer. We had no Wi-Fi, which my kids said, what? No Wi-Fi! Which was a good thing because we weren't you know, able to get on computers or laptops and do anything. But it was well worth the time to just get away and sort of refresh and gather yourself for lack of a better term. 

DAN_SHAPPIR: I agree with you so much. I mean, we were supposed to go on a family vacation more or less now, and it got canceled because of this whole Corona thing. And it's just that I'm missing it. It's just like I was so looking forward to it and the fact that I'm just working through this period of time instead of going out on a vacation and recharging my batteries and whatnot. It's affecting me in ways that I don't like. And I really don't know what to do about it. I have to be honest. 

STEVE_EDWARDS: Yeah, we actually had one. We hadn't gotten away from like a big travel vacation for a while and we had, we're all set to do one the week of spring break here in the state, which was right at the end of March when everything started falling apart and started having. No lockdowns yet. That's a whole different topic. But just travel restrictions and concerns about being gone somewhere and then maybe you get sick and can't come back. And so we had to bail on that. So. So yeah, I was I was in the same space there for a while. But fortunately, this one was one that I had planned like way back in September. Family member has a condo at the beach and they let me use it, you know, that type of stuff. But yeah, it was it was well worth it. 

CHARLES MAX_WOOD: Nice. Yeah, I need to pull something like that. AJ, what are your picks?

AJ_O’NEAL: Okay. So basically if you don't trade promise chaining hell for try catch hell because then you net zero. You don't you don't win anything from using async await if you just trade one bad paradigm for another bad paradigm, but instead you can make use of dot catch. And I think if you if you use a wait with dot catch so that you both shorten down your your promise trees as well as don't introduce, try catch how then, then you do well for yourself. I'm also going to pick, this is something I meant to bring up earlier, but didn't get to. Kenzie Dodds has an article called newspaper code structure. I saw him present this at one of the local meetups a few years ago. I think it's, this is one of the benefits that hoisting gives you is the ability to write your code in the order of what's most important, not burying the lead. So that as somebody goes from top to bottom of your code, they can see the most important bits first. And then you kind of put the implementation details down lower. And that's a benefit that you get from languages that have voice language, I think is pretty much all of them at this point. Well, the modern languages, like go Russ JavaScript. Yeah. Well, I don't know if it, I think Python still has that kind of, I mean, I think of the old ones support that too, for the most part, but anyway. Yeah, just being able to declare things in an order of importance. My most picked pick, your coffee shop doesn't use two phase commit. And this kind of really talks about the benefit of an event loop, although it's not using the language of an event loop, it's just talking about kind of that process of how the real world works. You know, Walmart having multiple lanes versus Starbucks getting people through very quickly. The croc on JS video series that I already referenced. I got a link to that in here. And then. Finally, I'm going to pick JQ, which is just a neat little tool to be able to transform JSON from bash. So if you need to curl something that gives back JSON as a result, and then pipe it to JQ, you can do a little bit of JSON query selection. So that is a cool tool. And I'm putting a link to webinstall.dev slash JQ, which has my cheat sheet for common use cases for it and how to install it. 

CHARLES MAX_WOOD: So my picks, I've got a couple of picks. One pick that I have is things have gotten a little bit tough with devchat.tv. A lot of it boiled down to just things slowed down at the beginning of the year with sponsors due to some Twitter drama. And then when COVID hit, like everybody cut their marketing budgets. And so anyway, things got tight enough to where I'm actually finding a job. But I am getting things together so that the shows are self-sustaining. I have a couple of things that I'm working on. One is a podcasting course. I mentioned it before, podcastplaybook.co. So go check that out. I'm also working on a basically how to build career momentum course for developers. And I'm not quite sure where I'm gonna host that at yet, but keep an eye out for that. And I'll put a link in as soon as I have it. And then the other thing that I'm working on is JavaScript resource guide. And so if you have, it's going to list like IDEs and CICD tools and courses and books and things like that, that I think are kind of the best to breed for people to go learn more on. And so if you're interested in that, you can just go to devchat.tv slash JavaScript resources or JavaScript dash resources and take you to that page. So yeah, those are my picks. Dan, why don't you go ahead and throw your picks out and then wrap us up. 

DAN_SHAPPIR: Will do. Thank you, Chuck. So, you know, I'm actually going to add a pick that I was like thinking about including or not. And now that Chuck has said what he said, I'm definitely going to include it, which is I'm going to actually pick this podcast. And in fact, the whole of Dev Chat and what Chuck is doing, I think it's an amazing resource that Chuck is providing the community with and just all this content and the conversations that we have this time with ourselves, but other cases with super interesting people from the industry and so much information out there. And I think we definitely need to be grateful for him for what he's accomplished in that and what he's given for the community with that, regardless of what you think of his political views or whatever. So that's one thing that I wanted to put out there. The other thing is a lighter topic. It's a TV show that I'm watching. I'm like a season late, but I'm enjoying it very much. And that's the Umbrella Academy. It's like this sort of weird drama slash black comedy slash superhero series. Like it has all the characters you'd expect to have in shows like this, but with a really significant twist. It's certainly darker than usual and I'm enjoying it a lot. It's kind of strange, it's kind of weird. I guess you need to have, I'm guessing it's probably, it's not up to everybody's taste, but like I said, I'm enjoying it a lot and I highly recommend it. So I'm watching it on Netflix, that's where it's at. And that would conclude my picks. Anybody wants to add anything before we wrap up? Okay. In that case, thank you everybody for participating. I think it was an excellent discussion and I'll definitely schedule a followup to cover the additional topics that we didn't get to. So thank you for joining and bye bye. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y dot com to learn more.