JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

048

048 JSJ Why JavaScript Is Hard


Panel

Discussion

00:56 – Why JavaScript is hard to learn 02:30 – This 05:30 – Bind 09:11 – Browsers 11:01 – Class-based inheritance

  • Prototypal inheritance

16:37 – New function 18:51 – Closures 20:51 – JavaScript is asynchronous 22:14 – Variable scoping

  • Hoisting

26:14 – Numbers and math

  • (AJ joins the podcast)
  • == ’s vs === ’s

32:15 – Things that make JavaScript hard after learning JavaScript

  • Package management

35:06 – Numbers (cont’d)

40:16 – Changing/Evolving JavaScript 43:31 – Environmental reasons that make JavaScript Hard

  • Tooling

48:25 – Few projects are primarily JavaScript 49:07 – Adolescence and the JavaScript Ecosystem 53:59 – Running JavaScript

Picks

Next Week

MooTools with Arian Stolwijk and Valerio Proietti

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

TIM:  I’m just learning lots of math and attempting to do real math in JavaScript is a fun challenge. [Hosting and bandwidth provided by the Blue Box Group. Check them out at  Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody and welcome to Episode 48 of the JavaScript Jabber show. This week on our panel, we have Joe Eames. JOE:  Howdy! CHUCK:  We also have Tim Caswell. TIM:  Hello! CHUCK:  And I’m Charles Max Wood from DevChat.tv. And when this episode goes out, you’re going to have about two weeks left if you wanted to sign up for my Rails Ramp Up course. You’ll find that at RailsRampUp.com. I’ve been working hard on that. This week, we’re going to talk about why JavaScript is hard. And I think it was Tim that came on and said, “So, we’re talking about why JavaScript sucks?” And I didn’t want to call it that but at the same time, it’s one of the — I think the reasons that people find JavaScript hard and the reasons some people say that JavaScript sucks are kind of the same thing. So, if you want to think of it that way, go right ahead. But I kind of wanted to talk about this for a couple of reasons. One was that I was at the users’ group meeting last week and they talked about some of the things that make JavaScript hard and I don’t remember what they all were. But there were a few things that, there are some concepts that are markedly different from what you find in other languages or at least some of the concepts exist in the other languages but they aren’t kind of as important or as in-your-face as they are in JavaScript. Anyway, the other reason is that I was thinking about when I first started this show. And when I first started the show, I was a web developer that was kind of like, “jQuery, whoo!” And thought jQuery and JavaScript, you know, were mostly the same in the sense that the only way to write sane JavaScript was to use jQuery. And so, I wanted to talk around some of the things that I’ve learned over the last year from the other panelists and help people who are coming into JavaScript understand the real power behind some of these other concepts. So that being said, let’s go ahead and get started. I’m a little curious as to what you guys think are some of the hard things that people run into in JavaScript, like why do they struggle with it? TIM:  Alright. So, I actually spend a lot of time teaching programming. And a lot of my students have background in other programming languages. And there are very subtle but very important differences in JavaScript and in other languages that look similar on the surface and I think that’s what confuses a lot of people. Like, if you come from the world of Java, or even the world of Ruby or just some scripting language that just has more traditional classes, then JavaScript’s really going to confuse you. Because you have this dynamic scope through this value keyword, we’re not even sure what it is, but it’s not really bound to the class of the constructor like you think it is. How many people have been bit by that? I even have articles, entire conference talks about what is this? What does this mean? CHUCK:  I’ve been bit by that. JOE:  Yeah, that’s probably the first thing in JavaScript that you have to squall is that this is not what you think it is most of the time or some of the time. TIM:  Right. There is no steadied class binding anything. It’s just functions and objects and then this thing called ‘This’ was thrown in so that you could do class style programming and it worked most of the time. CHUCK:  I so need that Princess Bride clip, “You keep using that word, I do not think it means what you think it means.” [Laughter] TIM:  That’s a great movie. I recently bought it on Blue Ray just for fun. CHUCK:  Awesome. TIM:  They actually made it quite a bit sharper. I’m not sure how. Anyway… CHUCK:  But yeah, there are a lot of cases still where I’ll be doing something. I’ll make an assumption as to what ‘This’ is and I’m wrong. TIM:  Right. And it bites you first when you do anything with an event handler. Because the way ‘This’ works and the way that I explain it is, whatever is on the left of the dot when you call the function. So, if it’s some object dot some method and you call it, whatever’s on the left of the dot is going to be ‘This’. CHUCK:  Okay. TIM:  And more or less, that’s correct. CHUCK:  What if it’s a function that you just call by name with no something dot function? TIM:  Then ‘This’ is undefined. CHUCK:  Oh, really? TIM:  Well, it depends on what version of JavaScript you’re in. In non-strict mode, I believe it gives you Window or Global. And I think in strict mode, it gives you null or defined. Either way, you don’t want to rely on that. You don’t want to use ‘This’ if you call it that way. CHUCK:  Okay. TIM:  And so, then there’s Bind which forces ‘This’ to be a certain value, no matter how it’s called. So, a lot of times, you want to bind your functions before handing them to event handlers. Or what I usually do is I just wrap it in a closure. CHUCK:  How exactly do you do that? I’m not sure if I have used Bind. Here I get to learn something. TIM:  Right. I need a whiteboard, this is not working. [Laughter] TIM:  So I mean, the way I think of Bind is just the same as doing a manual closure. It’s not, but it acts more or less the same.  So, suppose you’re doing Node, because I do a lot of node. You do fs.readfile, you give it the file name, maybe some options, and then you give it a callback. And it’s going to call your callback when the file is done loading. Well, suppose for your callback, you wanted to do some method on some object of yours, and inside that method you use ‘This’. So, if you just hand it myobject.mymethod to the callback, it’s going to call that callback in the scope of Window or Global and it’s going to break everything. So, what you do is you just put a little inline function there and then in your little one line inline function you say, myobject.mymethod and then manually pass in all the arguments. Or myobject.mymethod.applymyobject and then the arguments or whatever, but you wrap it in a closure. And Bind does that more or less. Bind on the function returns a new function that’s like the old one but always has a set ‘This’ no matter how you call it. CHUCK:   Oh, that’s very nice. JOE:  Yeah. TIM:  So yeah, that’s a source of confusion for a lot of people. And I understood it best when I started doing the object graph series, where I just drew lines and like, “Here’s this object and it has its property which points to this other object.” And functions are just objects, right? They’re just values. And I wrote this object that had a property called ‘Greet’. So, it’s like, Bob.greet. And inside the greet function, it’s like, printthis.name or something, just something simple. And then I made a new function, a new object that had a reference to the same function which you can call this other one that uses the other ‘This’, of course. Then I’d call it directly and I’d call it with apply and I show call it all these different ways and how the output changes each time. And people are like, “Whoa! You mean it’s not bound to the function you initially declared it on?” I’m like, “No, it’s not at all.” There’s no such thing in JavaScript. It’s just a big mesh of references, that’s all the language is. JOE:  The Bind method is a part of ES6, right? So before that, you have to use a shim? TIM:  ES5. JOE:  ES5, okay. So before that, you got to use a shim but there’s a lot of libraries out there that shim and it’s pretty easy to write your own as well. Underscore has a really nice Bind function. TIM:  Yeah, it’s like two lines of code. It’s not hard. JOE:  Yeah. CHUCK:  So, I guess I have to ask then, which browsers have ES5 already or at least some ES5 functionality? TIM:  Nowadays, it’s pretty common. I think Bind is as far back as, did IE7 have it? Or was it IE8? JOE:  I don’t know. TIM:  I don’t know. But IE9 is when they got real JavaScript, I think. [Laughter] TIM:  Before that, it wasn’t JavaScript. It was JScript. JOE:  That’s debatable. TIM:  Well, it’s shocker engine versus the old thing. It’s an entirely new engine. JOE:  I would say IE10 is when they got real JavaScript but I won’t say that in like two years when Chrome and Firefox have lots of awesome JavaScript features and IE10 doesn’t. TIM:  Yeah, but as far as Bind goes, most browsers have it and it’s extremely easy to polyfill. CHUCK:  Nice. TIM:  To support those ancient ones, just polyfill and you’re good. CHUCK:  So, you said that it effectively creates a closure. It’s not exactly how it works but you can kind of think of it that way. Is that how the polyfills work? TIM:  Yeah, the polyfill is just a closure. CHUCK:  That’s awesome. TIM:  Because I mean, it returns a new function so I’m just going to return a closure as my new function that acts like the bounded function, and there you go. CHUCK:  Yeah, awesome. That sounds — that makes a lot of sense. So speaking of browsers, that’s another thing that kind of threw me off. I’ve not been bitten too often by what’s in one browser and not in another because I’m usually using a library that will abstract that away for me. But it is something to be aware of and it’s something that I worry about is that I’m dealing with multiple implementations of JavaScript and I don’t get to pick which one my user is using. TIM:  Right. And it’s not that different than C programmers. You don’t know what compiler your people might be using if they’re compiling from source. CHUCK:  That’s true. TIM:  Or if they’re using it as a binary dependency in their library, you don’t know what Linux distribution, what patches they put in. I mean, it’s a common problem with anything that has large reach. CHUCK:  Yeah, that’s true. TIM:  I guess with Ruby and PHP and Python, it’s less of an issue because there’s basically, or used to be, just one implementation of the language. CHUCK:  Yeah. And at least with Ruby, I can speak to that a little bit. You generally know what the limitations are of each implementation, so you can just deal with it. JOE:  Yeah, that’s not an issue in .NET. It doesn’t have that issue at all. TIM:  Right. But then your reach is a lot smaller. You can’t run .NET. Yeah, you’re stuck in Windows boxes. You can’t run on your iPhone or your Chromebook, or… JOE:  No, no, no, definitely not. But I’m just saying that something that — anybody is about net programming is going to be used to this issue. TIM:  Right. I mean, yeah. The blessing and the curse of the web is it’s everywhere. JOE:  Right. [Chuckles] TIM:  That is why JavaScript is so popular because JavaScript code can run literally anywhere practically. If it has a full operating system, it can run JavaScript. CHUCK:  Yep. JOE:  Right. CHUCK:  So one other thing I want to get into, some of the things that were new to me when I started learning about JavaScript, like real JavaScript not just what jQuery does for you, were closures in particular and just how to think about things since I was coming from a language that is very highly focused on class-based object instantiation. And you don’t really see that as much in JavaScript, at least not in the classical way that most other languages implement it. TIM:  Right. JOE:  Are you differentiating between closures and classical class-based inheritance or…? CHUCK:  Yeah. JOE:  Okay. You’re talking about two separate things. CHUCK:  I am talking about two separate things. Sorry, I should have been more clear. So, I kind of want to talk about, how do you do that kind of thing with the class-based inheritance sort of thing in JavaScript? TIM:  So, JavaScript has class-based inheritance, it’s just not direct and doesn’t work the same. [Laughter] CHUCK:  It has what you’re asking for. It’s just not what you’re asking for. [Laughter] TIM:  No, it’s pretty similar. So, I’m going to make a rectangle class, so I’m going to have function Rectangle with a capital R because that way Crockford doesn’t cry and that tells me it’s a class because I capitalized the constructor. And then I do things like, this.width=W, this.height=H, and whatever. Then on your prototype, you pull in your methods and that’s a class. You create instance using new and it’s not that different than any class-based language on the surface, other than the Gotcha where you want to pass off one of your methods to an event handler and your ‘This’ is busted. It works pretty much like a class. Then, if you wanted to do Inheritance, then you just need to somehow set the prototype, I mean the underscore, underscore proto, the real prototype of your dot prototype to some other classes prototype. So, Inheritance isn’t very declarative but it’s there. JOE:  I think that your description is probably although true in concept, like the concept like the definition of class-based programming and prototype-based programming are essentially exclusive to each other, mutually exclusive. If you’re prototype-based, you’re not class-based. So even though you can think about them as classes, it’s still not truly classes. For one thing, everything’s an object, there are no classes. But my input to that question is really that when you start off, you just got to think of it like it really does have class-based programming and treat it like you do. And then slowly over time, learn the differences in prototypal Inheritance and then you can sort of take advantage and understand more and get caught up less in Gotchas as you understand prototypal Inheritance more and more because you can replicate it with prototypal Inheritance. I mean, there’s a great article by Crockford where he talks about — I think other people have said the same thing. The fact that you can simulate class-based inheritance with prototypal-based Inheritance but you can’t do the opposite. You can’t see many prototypal Inheritance with class-based Inheritance. So, you can treat JavaScript like it’s class-based and then using just patterns that people have established, and then over time, you can start to take advantage of what prototypal Inheritance gives you. TIM:  Right. I mean, it depends on what you define a class as. In some schools of thought, a class is a strict separation between behavior and state. Your class has your methods, your object has your state and you don’t mix them. Like, you can’t put a function on an object and you can’t store state values in your class. And the reason for that strict separation is they believe that it makes for cleaner code. So, if that’s your definition of a class, then no. There’s no strict separation at all in JavaScript. A function is just a value like any other value and you can inherit them from your prototype or not. JOE:  That’s an interesting definition. I’ve never heard that one before. TIM:  But in practice and especially if you want to make it run fast on V8 because of the hidden class implementation, if you write it like a class, it’s going to be very fast. JOE:  Yeah. Well, does that — that definition might work with JavaScript versus say Java or C# or C, right? But like Ruby, that doesn’t quite match up, right? Because Ruby, you can add functions to objects. TIM:  No. You can add functions to the item class of an object but that’s still a class. CHUCK:  Yeah. JOE:  Okay. So, you can’t take an existing object in Ruby? I can’t remember Ruby. I dabbled with it a while ago. But you can’t take an existing object and just add a function to it? TIM:   Well, you can but behind the scenes, it will create a new class. JOE:  Oh, it creates a new class for it? TIM:  It creates a new class just for that one object. JOE:  I see. TIM:  So I mean, it’s flexible but it’s still class-based. Whereas JavaScript, I can just put a function directly on an object and it’s just a reference to a function. JOE:  Right. TIM:  It knows nothing about classes or constructors or anything. It’s just a reference to a value. CHUCK:  Right. But that doesn’t modify the prototypes. So, if I effectively inherit from that object, then I don’t get that function, right? JOE:  Right. TIM:  Well, if you inherit from the modified object, you’ll get the ‘New’ function in your prototype because you can… JOE:  Yeah, depending on how you do it. TIM:  Oh, yeah. JavaScript is prototype. And it’s a very simple system once you learn it. It’s just it’s not what it appears, especially with the Java syntax and the ‘New’ keyword CHUCK:  Yeah, the ‘New’ keyword is a brain bend for me because that does not do what I expect. TIM:  What does ‘New’ actually do? Who knows that? It does a lot, by the way. JOE:  Yeah. TIM:  So I’ve got this function, it’s just a function, right? A constructor function is no different than any other function other than we capitalize them for convenience. CHUCK:  Right. TIM:  And that function happens to have this dot prototype property which by the way, all functions in JavaScript have even ones you don’t use as constructors. And that prototype property has this hidden dot constructor property that points back to the function. So, these two objects intertwined, is what makes a class. So, what ‘New’ will do is you say, new, give it a function, give it some arguments. It will now create a new object that inherits directly from the dot prototype of that function. It will then call that function with the ‘This’ scope of this newly created object and then depending on if you return defined or undefined affects what the result of that new operation is. CHUCK:  What do you mean? What happens if you return undefined versus not? TIM:  So, if you return a value from a constructor, then that’ll be what your ‘New’ results in. So, even though it created this new instance of the object from the prototype, it won’t return that. It only returns that if you return undefined from your constructor. JOE:  Or essentially, don’t put a return statement. TIM:  Or don’t put a return which is the same thing. Which is actually very useful because a lot of times, what I’ll do is the first line on my constructor, I’ll say, “If this, if not this instance of.” And then the constructor name, “Return ‘New’ the constructor name of my arguments.” JOE:  Right. We use that here for caching so we can basically try to construct an object. If that object already exists, we just return the existing object rather than create a new one, for models. We do it for models because we cache our models fairly extensively. TIM:  In my parsers, I do that for my tokens and my lexers. If it’s the same string, I always want the same instance. It’s very nice. You can return another object instead of the one that you just made. But all of that complexity is in ‘New’. It kind of calls the function but it calls it in a really weird way. And it makes it look like you’re creating an instance of a class. JOE:  So, Inheritance and constructor make JavaScript hard, but closures are another thing that makes JavaScript hard which is funny because I think closures don’t necessarily by themselves — closure is just a feature of the language. So the fact that there are closures in JavaScript doesn’t necessarily make JavaScript hard but… TIM:  They make it very powerful. [Crosstalk] JOE:  Yeah, they make it very powerful. And everybody uses them. [Crosstalk] CHUCK:  I was going to say, I’ve seen closures in other languages. For example Ruby, if you create a proc, it creates a closure. And a proc is effectively a function. TIM:  But only procs do, right? CHUCK:  Yeah. I don’t think lambdas do. TIM:  I’m trying to remember. JOE:  So, like in C#, they have lambdas that are closures and you can close over variables and then have those variables that you’re closed over be accessible later on if you pass the lambda round. And I had no idea that lambdas could do that because in .NET, you don’t use lambdas for that. CHUCK:  Right. And it’s the same in Ruby. I mean, most of the time, you’re going to create a class or an object and you’re just going to give it some instance values or instance variables and it’ll just do what it does. And so, it has another mechanism for holding on to those values. JOE:  It’s the paradigm of the language, right? In JavaScript, we use closures all the time to do all kinds of stuff. And part of that is to compensate for the fact that context isn’t guaranteed. The ‘This’ isn’t guaranteed, so we use closures to compensate for that a lot. TIM:  And the reason that your ‘This’ changes on you is because you’re using your methods as callbacks. Well, every JavaScript runtime I know of uses non-blocking IO. The JavaScript, everything’s async. In Node, everything’s async. So, you’re using callbacks a lot. If you’re doing .foreach on an array, that’s a callback. And so, yeah. While the ‘This’ in JavaScript can do the same thing as the instance and class languages, it’s going to bite you all the time. JOE:  Right. And that’s another thing that makes JavaScript hard is the fact that it’s asynchronous and that’s a lot different from pretty much most other languages people are used to. CHUCK: Yeah, that’s absolutely true. And you know, it ties back to what Tim’s saying about ‘This’ and some of the other things that we’re talking about with closures. You know I think, this is where it really comes to a head is that in a lot of cases, if I have work to do in JavaScript, I’m going to do it through a series of callbacks instead of asynchronous, do this, then do that, then do that, then do that and just know that the virtual machine or the compiled code is just going to march through that sequentially immediately and then come back with a value. And the fact that the context changes with every callback is what really throws people, I think. Because asynchronous versus synchronous, what it really comes down to is, I’m going to throw out there that I need work done and it will happen eventually instead of knowing that the call is going to happen right away. But it’s that context switch that really just, you know, gets you confused because it’s like, “Oh, I’m doing this but I’m doing it in a different context and I’m doing this in a different way. This isn’t what I expect it to be. I may or may not have closed over what I need.” And it gets tricky. JOE:  Yeah. TIM:  Another thing that I think is harder is variable scoping. Like ignoring ‘This’, I often write code that has none of ‘This’ in sight, because it’s complicated and I don’t like it. But ignoring that, you still have weird variable scoping, like I remember this one bug I had where I was closed over this variable, and then I had this massive function. And the first line of my function, that variable I closed over was undefined. But I was like putting console logs everywhere. The line before I call my function, that variable had a value. And then on the very first line of my function, is now undefined. What changed? Well, it happens to be that a hundred lines down in my code, I had a var statement by the same name. [Laughter] TIM:  And var statements hoist their declaration up the entire function body and that includes var statements inside for-loop heads, inside for-loop bodies. If’s and for’s, those aren’t new scopes. That all shares the same scope as the function. JOE:  Isn’t that a lesson on not to make your functions a hundred lines long? TIM:  Well, yeah. [Laughter] CHUCK:  Can you explain hoisting really quickly? TIM:  Right. So, with the var statement, that variable is defined for the entire scope of the function, no matter how far down the function you actually put your var statement. The compiler is going to take it and move it to the first line. And this is why a lot of best practices say, “Put it on the first line,” because that’s what it’s going to do anyway. At least then, you can see it. JOE:  And mention the blocks that don’t scope, like for-blocks. TIM:  Right. So blocks, the difference between a block and a function is a block you can break out of, you can continue out of and you can return from it, it’ll return to the function. So, block and a function body are very different. But blocks in JavaScript don’t have scope. They share the scope of the function they are in. CHUCK:  Okay. JOE:  Unlike most other languages. TIM:  Right. So like, you need a for-loop, you need this variable for your iterator where that variable is now global to your whole function. JOE:  But with ES6, we’re going to be getting the ‘Let’ statement. [Crosstalk] JOE:  Yeah. ‘Let’ will scope within the ‘for’. So, if you do a ‘for I’ which everybody likes to do, you can declare the variable, know that it’s local to that. TIM:  Right. CHUCK:  Yeah. That’s another one that I keep seeing demonstrated over and over and over again is the for-loop. And then it relies on ‘I’ somewhere in there and so anyway, ‘I’ winds up being the whatever count you went through in the for-loop plus one. And anyway, so when you finally — it’s usually when you’re sticking something into something else. I don’t remember the exact circumstances, but yeah. TIM:  I’ve seen it, yeah. CHUCK:  So, they wind up wrapping a function around it so that they can close over ‘I’ so that they can, you know. TIM:  Oh, that case. Yeah, that’ll bite you real fast. You have to — if you want to create scope, you basically have to make a self-calling function. Because very often, if you create a closure inside a loop, you want the scope of that loop from that iteration. If you don’t, you’ll get whatever the scope was after loop is done. CHUCK:  Yeah. And that trick is so obscure to anybody who isn’t a JavaScript programmer because I don’t know any other language where you can sit down and say, define a function or define a method. And then inside there, you define a function or define a method without using some other meta-programming trick to do it. And then in JavaScript, it’s just, “Oh well, I’m just going to function this, blah…blah…blah.” And it’s… TIM:  But even that, it won’t bite you unless the closure you create inside the loop is called asynchronously after your loop is done. Because if it’s called synchronously like directly, then your scope is still what you want. But in JavaScript, there’s so much asynchronous callbacks that that particular combination will bite you. Yeah, scope is interesting. This is why I’m creating my new language to not have this. [Laughter] CHUCK:  Yeah. Are there any other things that you guys can think of that people just run headlong into and then go, “Whoa!” TIM:   I would love to talk about numbers. CHUCK:  Numbers? TIM:  Yes. CHUCK:  Okay. I don’t see people doing heavy math in JavaScript. Is there a reason for that? TIM:  Well, JavaScript has one number type and that number type happens to be IEEE double whatever floating point which is a 64-bit floating point. And what that means is it can be an accurate integer up to the 2 to the 53 which is a pretty big number. And it can do negative and it can do decimals up to a lot of digits. So, it seems like the ideal number, right? Unless you’re dealing with 0.2 and 0.3. Suppose you want to add — suppose you have like a shopping cart on your web page and you want to add up all the prices of your various things. Well, because of the way floating point works, it’s a base 2 system, you can’t represent numbers. I think 0.3 is one of the numbers you cannot represent. No matter how many digits you have in the base 2 system, you can’t represent that. CHUCK:  Really? TIM:  And so you get these floating point errors, where you add 0.7 and something, and your answer is now this 15-digit long thing that’s wrong. [Laughter] CHUCK:  Really? TIM:  Yeah, the numbers are not precise. AJ:  Well, Ruby has that same problem. CHUCK:  Hi, AJ! AJ:  Hi! TIM:  Yeah, anything that uses floats as your numbers is going to have that problem. And you know, the web and shopping carts, and online shopping people like it when their totals add up to the right number.  They get kind of mad when you’re charging them the wrong amount because you can’t do math in JavaScript. [Laughter] CHUCK:  Oh, come on! AJ:  How many times are you charging someone a billion dollars? TIM:  Even if it’s off by two cents, that’s enough to upset someone. Because it’s… AJ:  It could only be off by two cents if you’re charging them a billion dollars. The best way to do it, of course, is to multiply by 100, do everything in cents and then divide by 100 when you display it to the user and round it. But even if you’re doing like your basic shopping cart math, you’re not going to screw up on that. Now, bank account math, you might screw up on. But do you really screw up on basic shopping cart math? Because I don’t think you do. TIM:  So, here’s what messes you up, and just in addition, you can’t be off by more than a penny. But then, you calculate your price per item and I’m ordering 50,000 units of this and then, you multiply that by 50,000 and now, your error just got 50,000 bigger. AJ:  Well Tim, can I ask you the last time you ordered 50,000 of anything? [Laughter] JOE:  Tacos. TIM:  Tacos, just last week. AJ:  I believe it’s a valid problem for the server side and I believe it’s definitely an annoyance when you’re doing checking because like you say, “Oh well, when this number reaches 500 then stop.” But it’s actually 499.999999999996 and then, you have an error in your program where you go above your limit or you go below your limit. I run into that, for sure. But I don’t necessarily think that people will get charged the wrong amount. [Crosstalk] CHUCK:  Hold on. JOE:  Just want to know that you round. If you want to reproduce this, it’s really easy. Just go to your browser, just type in like .7 + .2 and you can see there’s a lot of other ones that they don’t show up. You type in .2 + .2, it actually comes out to .4. AJ:  Yeah, so .1 + .3 and .1 + .7 or .1 + .6…[expression] TIM:  Yeah, there’s lots of them. CHUCK:  Yeah. But the thing that I really want to point out, AJ, is that yeah, I’m not going to go and order 50,000of something, but I know businesses that do, and they do it online, and it can be a problem. So, it does make sense. AJ:  Okay. TIM:  There’s a more common problem that just completely breaks your code. Suppose you have logic that says, “Well, if the amount equals this exact amount, do this thing.” AJ:  Yeah. And that’s what I was saying earlier with the 500but you get 499.999999 because I’ve run into that. And it’s like, takes a long time to debug before you figure out, “Oh yeah, I can’t do floating point math.” TIM:  So, JavaScript has this crazy type coercion == operator that will say the string one is equal to the number one but if you say 0.9=0.7+0.2, that’s false. JOE:  So, I think that another thing that people run into that is a good practice to get into is just using === all the time. TIM:  Yeah. Don’t use the coercion unless you need it. [Crosstalk] CHUCK:  So, what is the difference between == and ===? TIM: The === will check types first. And if they’re not the same type, they’re not equal. Whereas the == will coerce them to the same type and then compare them. CHUCK:  Is it like Ruby in the sense that you can say, number === integer? TIM:  No. It’s not for types. CHUCK:  So, it does type check and value check. TIM:  So most likely, it was for web forms. So, I have this form, input the quantity you want. So they type in this text area and put field as number. And then your logic, you don’t want to manually convert that to an integer. You would just want to say, what they entered, == 5. And JavaScript will say, “Well, that’s a string. I’m going to parse it as a base 10number.” And, “Oh look, it’s 5.” So you go, “Yeah, that string 5 equals the number 5.” It’s extremely convenient for that type of use case. AJ:  Except for when they prefix a leading zero. TIM:  No. I think that’ll be fine but there are… AJ:  Oh, does it? TIM:  And it’s really loose too. So, if I put like 05frog, it’ll parse that as the number 5 instead of throwing an error. CHUCK:  Right. This is just throw out parse or something? TIM:  Something like that, yeah. You have to read the spec to see the exact mechanics. But remembering all the different rules is complicated. JOE:  So, we’ve talked a lot about why JavaScript is hard to learn, but there’s a whole section of crap that makes JavaScript hard to program in once you get past the learning curve, you know? These sorts of things, these are things you encounter in the first year that you’re working with JavaScript. But then you move past that first year into bigger, more complex problems that aren’t being solved right now. And there’s just a huge section of things that make JavaScript hard for that kind of problem once you’ve learned JavaScript and know JavaScript. TIM:  Right. So, the things that are hard even once you know what you’re doing. JOE:  Exactly. AJ:  Example? JOE:  The top of the list is packages, no package management. TIM:  Let’s stay out of that wormhole, I think. [Laughter] JOE:  Did you pick it last week? [Laughter] TIM:  That could be an entire five episodes but yes, package management especially in the browser is not a good situation. JOE: You know, Paul Irish just had this short little YouTube video that he posted because someone sent him an interview question. And he went on a walk with this camera he’s holding on his face and he talks about stuff and just briefly mentioned package management. And he just said this great thing because lack of package management, people are solving the same problems over and over because they don’t want to depend on other people’s packages because package management is just a solution that isn’t well-solved yet. So anyway, that’s one of the things that makes JavaScript hard. You have to deal with packaging when you get bigger problems besides a little bit of animation on your page. TIM:  And you have to understand that once you ask someone help on package management, you’ve probably just opened a can of worms in whatever forum you’re in. AJ:  Yes TIM:  And it does slow you down because you just want to get your work done. Like, “What’s the best package manager?” And, “Oh, I’ve just got ten opinions and now I started a fight.” JOE:  Yeah, exactly. CHUCK:  Isn’t it pretty cut and dried in Node as far as just using NPM? TIM:  For the most part. CHUCK:  But you’re talking about specifically in the browser? TIM:  Yeah. In the browser, it’s not a good story. There are worlds of opinions and it’s still a fight. AJ:  It seems like there’s mostly just two or three, though. I would say AMD is the clear win at this point. Like, there’s some of us like myself, we want to use the CommonJS style packages but AMD is kind of the clear win. RequireJS, it’s got the market really. TIM:  I’ve heard quite the opposite from many, many people, so… [Laughter] CHUCK:  There we go! JOE:  We’re having an episode about this shortly, I believe. CHUCK:  Yeah, we should have that religious war. JOE:  Yeah, definitely. AJ:  I’m definitely on the religion side of the CommonJS. But that’s just my perception is that RequireJS wins. [Crosstalk] TIM:  Let’s move on to other things that are hard about once you know JavaScript. CHUCK:  I was going to say is that, like, I was raised a Catholic but I’m practiced as a Mormon or something? [Laughter] TIM:  Alright. AJ: Actually, I was raised as a Baptist and I do practice as a Mormon. TIM:  Right. So, going back to numbers, I’ve done JavaScript since the 90’s. I would hope I know the language because I teach about it. I still learn things every now and then, which is amazing. But I’ve been doing a lot of Crypto lately. And most Crypto is based around 32-bit integers. AJ:  Oh, no! CHUCK:  Oh, wow! TIM:  But at least, they’re not 64-bit. Because like I said, the number type in JavaScript cannot represent 64-bit integers. AJ:  Well, it can’ really represent 32-bit integers. It can only represent 31-bit integers. TIM:  No, it can do up to 53-bit. AJ:  Well, kind of, except that the coercion makes — like, you said Crypto and I’m thinking like bit shifting and stuff. And then, you have to like convert stuff into a string because it can’t represent a 32-bit integer. It can only represent a 31-bit integer when you’re bit shifting. So to get that last bit, you have to convert it to a string. Because I’ve done some stuff with bit shifting in JavaScript and found out the nasty way that your numbers, all of a sudden, become negative for no reason. TIM:  But that’s not a problem. And yeah, so I’ve been dealing with this a lot and yes, as soon as your 31st bit is high, or the first bit whichever — 31st…32nd…yeah, because it’s… CHUCK:  Are you little-endian or big-endian? TIM:  Bits are little-endian, I think. I know they’re within a byte. I’m just going to assume they are within the 32-bit word. So yeah, the high bit, the one that’s the signed bit, in signed integers. But if you’re doing bit wise operations, it doesn’t matter. It can look like a positive number to JavaScript, it can look like a negative number to JavaScript, it’s not going to matter because all your bit wise operations treat it the same. It’s still the same 32-bits. And you can force the JavaScript representation to be signed and unsigned by using the triple right shift operator zero. So you take your negative number and do >>>0 and you now have a positive number with the same 32-bits. So I mean, you get to learn all these different tricks and then how they perform differently in different browsers and different runtimes and you just say, “Why can’t I just have a 32-bit integer that just works as a type?” Well, then JavaScript would have multiple number types and that would be a different language. [Laughter] CHUCK:  Don’t most other languages give you different number types? Like floats versus integers? TIM:  Most scripted languages don’t, most static languages do. That’s where the split is. AJ:  Does Ruby give you different numbers other than big numbers? CHUCK:  You have fixnum and bignum. AJ:  Yeah, okay. That’s what I thought. CHUCK:  But it has more to do with how big the number is rather than whether it’s floating point or not. TIM:  Yeah, Ruby will switch between them internally, which is what JavaScript engines do too. They’ll switch between 32-bit integers and floats. But as far as the spec goes, they’re always 64-bit floats. The other thing related is strings. Who knows how strings are encoded in JavaScript? JOE:  Wait, I know this one. It was in Dave Herman’s book. He talked about how to treat strings as an array of characters, an array of sequence. I can’t remember exactly how he said it. TIM:  Not characters, there’s a different word for it in Unicode speak because characters can contain three bytes out of BMP characters. JOE:  Yeah. TIM:  So basically, according to the spec, a character in JavaScript strings, the 16-bits. There’s more than two to the 16 Unicode characters, so that’s a problem. So these bigger characters are multiplied by two JavaScript characters, but if you use length or like any of the string operations in JavaScript, it’s going to treat those as two separate characters. Even though in Unicode, they’re one. And then, suppose you want to store some binary data in a string which you can do if you’re careful but Unicode does not look the same as like 8-bit ASCII. JOE:  Right. TIM:  So I mean, this is why in Node, we added the buffer type. And in the browser, we now have buffer array and type arrays and all these neat binary safe types. Because JavaScript strings are, I think the format is called UCS16. I think that’s the official name for it. But it’s this special 16-bit Unicode encoding and then everywhere else it the world, when you serialize to a string, it’s UTF8 which is a variable length encoding. And if you want to convert between them, you can do these really clever hacks using escape and UR link code and it works pretty well actually. But the secret I found is just understanding that a JavaScript string is really an array of 16-bit values. JOE:  Yeah. Dave Herman’s book, ‘Effective JavaScript’ has a section on that and it’s really good. If you missed our episode on that, you should definitely listen to that episode and then definitely buy that book if you’re doing JavaScript development. That book is also really good at getting over and learning a lot of the things we’ve been talking about that it’s just hard in JavaScript to learn because these little nuances that can get you like numbers and strings and stuff, he talks a lot about that sort of stuff, really good book. TIM:  It is a good book. [Crosstalk] JOE:  Go ahead, Chuck. CHUCK:  So assuming that you guys spend quite a bit more time programming JavaScript than I do, or maybe programming different things in JavaScript. Since most of the apps I work in these days have an XJS frontend that’s more or less the app, and then, you have an API built in Sinatra or Rails which are Ruby frameworks on the backend. Do you feel like some of these things are things that should change in the spec to make it easier for people to come in? Or is there a downside to that trade-off? TIM:  So, like I said before, the blessing and curse of the web is it’s everywhere. So, you can’t change a language. JOE:  Well, that’s only partially true, right? We’re getting ‘Let’ to compensate for var. [Crosstalk] JOE:  Some of these issues with variable hosting. TIM:  Right. You can add features and you can remove some features that pretty much no one uses like you can’t use width in strict mode, I believe. But you have to opt-in to strict mode. And I’m pretty sure you’re going to have to opt-in to ES6 as well when it comes out. And this is the thing, you cannot break the web. If you break the web, then the web loses all its value. JavaScript isn’t the most popular language because it’s the best language. It’s the most popular because it’s everywhere. And as soon as you don’t’ run everywhere, you’re no longer so awesome. JOE:  But it can definitely evolve. JavaScript language can definitely evolve and we’ve seen that. It’s evolved already. TIM:  It has evolved and it’s much better than it used to be. JOE:  Yeah. So, as paradigms become — you’re going to — you got websites that were built in 1996 that are up and running and you don’t want to break those. TIM:  I think that’s broken already. [Laughter] JOE:  But as we get farther along and people start iterating and using newer features and the old paradigms and old features get out of place, then things get better, at least for developers. TIM:  Right. But for the most part, it bloats the language. It’s very hard to say, “If I wanted to remove ‘This’ from the language,” it would never happen. [Crosstalk] CHUCK:  How much of the web would you break with that? That makes sense. TIM:  All of it. AJ: I kind of think of JavaScript as like a unicycle with an oblong wheel but an optional two second wheels that are the right size and a jet pack. [Laughter] AJ:  Then nobody wants to use any of that and then whenever you say, “Oh, by the way, did you know that it has two regular size wheels and a jet pack?” You always get some guy being like, “No, don’t do it, use strict ‘This’ for newbs. And you can’t have octo, keep the oblong wheel, you can learn!” JOE:  Nice! CHUCK:  [Laughs] AJ:  PHP has the clawed hammer, and then JavaScript is this oblong wheel but at least it has the redeeming qualities. But a lot of the big leaders in the community are completely against the redeeming qualities. TIM:  What are you talking about? Octo is awesome. Okay, maybe outside of false system permissions, it’s never ever used. But that’s useful in certain cases. AJ: Oh and good news, the Node devs finally corrected Node so that you can now run Node in strict mode. There’s actually a flag, dash, dash strict mode where you can run all of your Node code in strict mode. So, all the core modules are strict compatible. TIM:  Okay. JOE:  So, I think there’s also some environmental reasons that make JavaScript hard. CHUCK:  Okay. JOE:  Like tooling and adolescence but this goes hand in hand with both the language and the tooling, the tooling is adolescent. I wanted to say infantile but that probably would be unfair. But our tooling is adolescent, browser, debuggers. TIM:  In some ways, I went back to doing GTK Python because that’s what I did before I made apps in JavaScript. And the nice thing about PyGTK is you got this nice fairly clean language and this widget framework and everything works and it’s great. And then in JavaScript, I got spoiled because I had WebKit inspector and I can inspect the DOM and I can set breakpoints and I can even say in Chrome, “When anything mutates this property on this DOM element, set a breakpoint.” And there is nothing like that for most of the native frameworks. So yeah, language wise, the tooling’s not very good for JavaScript because it’s a very dynamic language but the browser aspect of it is extremely mature. I think there’s really good tooling there. JOE:  I think that they’ve made some huge bounce forward, but debugging in the browser compared to debugging in a decent server side language, there’s a significant difference in the quality of the tools there, significant difference. TIM:  I guess I don’t know. I mean, V8 has a debug protocol. You can run it from eclipse if you really want. JOE:  Yeah, that’s true and you can do it from WebStorm, it’s cool. CHUCK:  I’ve kind of seen it both ways. I mean, I’ve seen some of the tools out there that seem to work pretty well for Ruby or whatever, and programming on any given day. I don’t know. It seems like most of the JavaScript I do since it’s on the web end, I’m looking at it, to a certain degree, totally different things. And so, it’s really hard for me to kind of compare the tools. For the most part, I find them adequate on both ends. So, I’m not really convinced that, you know, we’re lacking too terribly for JavaScript. JOE:  Well, I’m not just talking about just like the debugger in the browser, right? Like testing frameworks are hugely adolescent compared to server side testing frameworks. CHUCK:  That’s fair. JOE:  At least, all the ones that I’m familiar with. Like just the ability to take a huge suite of tests, grab just a certain set of them and run just those. That’s pretty much missing in every testing framework, at least the big three, QUnit, Jasmine, and Mocha. TIM:  I thought you could do that in Mocha. I guess it’s just one at a time. JOE:  You can select one test or you can select the group that that test belongs to and then really just does a grip. So then, you’re not even 100% sure. Say you have a describe, you have a list class and a list chair class, right? If you do a grip on list, you’ll get both of those if they have a describe list and a describe list chair, you’re going to get them both because of the way the grip works. I want just my tests for list. But what if I want to run two tests for list and two tests for list chair, I can’t do that. TIM:  Now, why is that hard because it’s not like it’d be hard to implement that. JOE:  It’s not hard but nobody’s done it yet. So the tooling, there’s nothing hard about that as far as doing it. But nobody’s done it yet because the tools are adolescent. They haven’t been used yet. TIM:  Just not enough users, I guess. JOE:  Not enough use, not enough people complaining about it, not enough, “Hey, why don’t we fix this?” TIM:  Now speaking of tooling, I worked at Cloud Nine for a year. And as far as I know, that was the most advanced tooling for Node there ever was. And it was a full breakpoint debugger and we even had very smart auto completion that rivaled some of the stuff that Visual Studio and Eclipse do. And it was really, really hard. We had to hire several people with PhDs to work on this because JavaScript’s a very dynamic language. I mean, if you think about it, there’s nothing declarative about the language at all, for the most part. It’s extremely procedural and function based, it’s this big blob of references that just mutates state constantly. And then, how do you take that and extract structure from it? “Well, here’s a class with this method with these arguments that does this.” How do you write tooling for that? JOE:  Right. It’s hard. TIM:  Right. And V8 actually does a pretty good job. If you look at stack traces in V8 on a modern version of Chrome or Node, it can tell you what name this function had when it was set to the property and what name it was called from and if they were different names. And it does all this crazy analyzing of your code to guess what the name of that function is. But language wise, it’s just a function. It has no name. AJ:  Right. Another environmental issue I think that affects JavaScript makes it hard is the fact that it’s just, very often, JavaScript’s ancillary to the main development that’s going on. You know, you’re building a website, you’re using a server side, so the JavaScript code is very secondary. And because of that, people don’t give it due consideration. Wasn’t it Crockford that said, “JavaScript’s the only language people feel like they can program in without bothering to learn it?” [Laughter] CHUCK:  That’s so true! TIM:  I don’t know, there’s a lot of Rails developers who don’t know Ruby. [Laughter] CHUCK:  That’s true too. JOE:  Yeah. [Crosstalk] JOE:  So, what I’m saying is very few projects are primarily JavaScript, in the grand scheme of things. TIM:  Right. And also, there’s the history since it is everywhere and it’s accessible to beginners, there are so many JavaScript developers in the world that really don’t know what they’re doing. JOE:  Right. That’s kind of another thing is I feel like, and this is my own personal opinion and don’t mention me for saying this, but there’s two primary groups that program in JavaScript. Group A is me, and the people that I come from which is some kind of a strictly typed server side language and they come to the JavaScript world and you wonder where the IDE is and where its compiler is, and what are all these closures? These idiots using closures and what are you kids doing? Right? CHUCK:  Hippies. JOE:  Hippies, exactly. And then you’ve got these script kitties that just barely graduated from college six months ago, and they wouldn’t know a best practice or a software pattern if it bit them in the hush puppies. So, you take those two groups of people and the one group is so used to doing things one way that learning things a new way is hard, right? And so, learning to right JavaScript the way that JavaScript was meant to be written is hard. And for the other group, younger group, who is growing up in JavaScript nips as their primary language, they know the paradigms of the language very well. But when it comes to writing hard software, solving complex business problems, they haven’t reached — they’re in their adolescence. And I listened to this great talk about something entirely un-tangential but they talk about adolescence is premature maturity where you act the way that you see mature adults act, but you don’t understand why. That’s what defines an adolescent, is acting the way that you see an adult act but not understanding why. You’re just mimicking. Then as you grow older, become an adult, you start acting the way that you prefer to act because that’s the way you prefer to act and not because you’re mimicking something. It was an interesting talk and I’m not explaining it very well. But yeah, we have that same issue where we’ve got a lot of — this industry, a lot of JavaScript developers are people that don’t know what software patterns are. They don’t follow luminaries and say, “Hey, we’ve solved a lot of problems. There’s value in looking at how other people have solved problems and learning from them.” They kind of have a natural tendency to just pooh-pooh what older people say. [Laughter] TIM:  Not invented here. JOE:  What’s that? Not invented here. TIM:  Not invented here. It’s related. JOE:  Yeah, exactly. But the problem is that for a company, you want to build a big JavaScript project, you can’t go find a developer who’s been developing it for 20 years just doing JavaScript because by the time they get old, I feel like I can talk this way because I represent this group, then they’re comfortable what they want to do. They don’t want to learn anything new which I think sucks because that’s why I got into programming was to be learning new stuff and doing cool stuff all the time. So, you get developers with a lot of experiences that can benefit everybody else and they don’t want to do it. So, you hire young kids who know JavaScript but then, they haven’t gone through the pain that comes from not having a tested code base and not having CI in place. TIM:  Yeah, there are definitely different groups emerging there. JOE:  Yeah. So, it’s just a funny thing I really feel like that contributes a lot to the pain of JavaScript as a language as a whole. TIM:  It’s nothing to do with the language and the semantics itself directly, it’s just… JOE:  No, it’s just the ecosystem. I mean, JavaScript is the future of what’s going on. More innovation is happening in JavaScript than is happening just about anywhere else in our industry. Certainly as a product percentage wise of innovation going on, it’s a Wild West, it’s all happening here. And imagine how nice it would be if it was as cheap to develop single page applications in JavaScript as it is to develop post back pages in Rails or .NET or Groovy or whatever, Grails have you. Once it becomes that cheap and companies can provide this highly interactive experience at a really low cost, they’re going to go there and say, “That’s really interesting.” I believe that’s where the industry is heading. But until we get there, it’s just a funny landscape. TIM:  Isn’t that what things like, frameworks like Ember are trying to do? JOE:  Yeah. CHUCK:  Yeah.  JOE:  Absolutely. TIM:  For that use case, yeah. CHUCK:  I think we’ve kind of gone off on a tangent here. [Laughter] CHUCK:  But at the same time, I definitely agree that, you know — and we’re seeing this in a lot of the other areas too, especially in the up and coming languages where yeah, you have new people coming in who don’t have the depth of the experience and don’t know where all the pain is, and haven’t found that what Uncle Bob or somebody else says is generally right and a good idea. And so, we kind of have to teach them. But at the same time, they have that fresh outlook and that excitement for learning new things that we definitely need to see more of in the community. TIM:  One interesting thing related to the scope of JavaScript where you can run it is, not all environments are the same at all. So, I run JavaScript pretty much anywhere I can. And if you’re doing JavaScript in Node, then you know that you have ES5, you know that you have V8, you know you have all these built-in things, you have a built-in synchronous require system, that’s one platform, that’s one world. And you do JavaScript in the browser for the general public and you have to support all the way back to IE7, then you have an entirely new set of constraints. And then, maybe you’re making WinJS apps in JavaScript. Then you have this entirely other set of constraints in this crazy WinJS API that mirrors the C# APIs from Windows but in a JavaScript-y promise-y kind of way. And then, you’re doing JavaScript maybe in Node, because JavaScript is now the official language of Node maps and the Window managers already do it in JavaScript. Well there you have Spider Monkey and you’re using Let, and de-structure in JS 1.8 everywhere. This is not ECMAScript at all. It’s JavaScript 1.8. And technically, they’re all the same language, right? CHUCK:  Uhmm. TIM:  But they’re not. They’re not the same platform at all. They have entirely different best practices and for a lot of the time in the history of node, people were like, “Node’s awesome because you can now share code between the browser and the server.” And I’m like, you can share some but they’re not doing the same thing. They don’t work the same way. Just because they happen to be the same base language doesn’t mean that you can share a lot. JOE:  Right. CHUCK:  And so it takes context to communicate about what you’re doing and where you’re doing it. TIM:  And it really confuses people because like, “I’m a JavaScript developer and this is what’s important to me. Why is this not important to you?” Well, maybe because I’m doing something different. CHUCK:  You mean, you’re not in PhoneGap? TIM:  Right. I mean, whereas in Ruby, most people are doing Rails or Sinatra or some sort of web server with block-in IO and probably a database. There’s a lot more cohesion there. CHUCK:  Or Chef or Puppet kind of thing where it’s IT management. But they’re all kind of compartmentalized and they don’t really have to share a lot. TIM:  Right. We did Node on Web OS to load your context from this crazy database. I mean, there is no web server in sight. This was just using Node for something else. CHUCK:  Yeah. That’s definitely an interesting take on kind of the — I don’t want to say fracturing of the community. But you know, the different interests that are there. TIM:  In my mind, they’re not one community. They’re several communities that have something in common. CHUCK:  Right, but we tend to lump them together in certain instances and that’s where the confusion comes in. [Crosstalk] CHUCK:  Alright. Well, we kind of need to get to the picks. Are there any other things that we’ve neglected? TIM:  I mean, language wise itself, just go read Dave’s book. It will tell you all the Gotchas. JOE:  Yeah. CHUCK:  Yeah, we’ll get a link to that in the show notes. TIM:  It’s a great book. CHUCK:  Yup. Alright. Well, let’s go ahead and do the picks. AJ, are you still there? AJ:  Yeah, I’m here. CHUCK:  Do you want to do your picks for us? AJ:  Yeah. So, first thing I’m going to pick is Sharpie. I love Sharpie’s. I think I’m not alone. I bet that there’s a wide audience of our listeners that also love Sharpie’s. And today, I’m going to pick a very special Sharpie that’s near and dear to me, it is Sharpie Metallic Silver. And the great thing about Sharpie Metallic Silver is, let’s say that you wanted to run a really crude ad-hoc ad campaign. You could just take some cardboard you got from like Amazon packaging, write on it with Sharpie Metallic Silver, put it under a black light, take a picture of it, and bam! You’ve got an awesome looking retro ad. Just saying. JOE:  Can you also use that if you’re also at the exit to a Freeway? AJ:  The exit to a Freeway? JOE:  Yeah, cardboard with a Sharpie on it. Is that a good color if you’re standing at the exit to a Freeway? [Laughter] AJ:  Oh, no! I wouldn’t recommend Metallic Silver for that. I recommend maybe something different because Metallic Silver, at least this time of year in Utah, with all the snow and the light reflecting off the snow. You’re not going to get as much contrast as you need, unless you happen to be at night and have a black light as well. But then whatever your message is, probably gets invalidated by the fact that you have a black light. Because it’s normally something like, “I need food.” CHUCK:  Yeah, we’ll use black light for food. AJ:  That’s right. We’ll rent black light maybe. So, let’s see. Another thing, I came into the conversation right as you guys were talking about the — Tim, what did you call it? Self something functions? Self-calling…? TIM:  Self-calling functions? Immediately — what did Dave call them? AJ:  Immediately invoked function thresholds. TIM:  Yeah. That’s what he called it. AJ:  So, I wrote an article on that and have a screen cast with it. And the feedback I’ve gotten from it is that it’s a pretty good explanation. So, you guys can check that out if you want to and give me more feedback. And then also, I found a unicycle that I think kind of embodies the JavaScript unicycle except that its primary wheel is a regular shape. But I think it’s good enough for illustration purposes and there’s a link to that as well. JOE:  Awesome. CHUCK:  Alright. Tim, what are your picks? TIM:  Alright, I got two. One of them is, if you want to go off a rabbit hole learning math, try to understand how RSA really works. On the surface, it’s just, “You take this really big prime number and you take it to the X point of this other massive number modulus, this massive number.” But how you implement that in a computer that has finite numbers, then it gets fun. So, if you ever want to have a math rabbit hole go read up on RSA and click all the links on Wikipedia and come back to me in a month or two. And my other pick is, I don’t know how to pronounce this, OUYA. It’s a new game platform that’s being built, it’s based on Android and the goal is that Indi developers can easily put games on this gaming platform because it’s really hard for any developers to get games on like a Nintendo or any of the existing platforms. So, this is just a $100 box that plugs into your TV. And I think it’s neat. I’ve been trying to make these kind platforms for years and never done well. So, I like it that someone else is making one. CHUCK:  Awesome. Joe, what are your picks? JOE:  So, my first pick is going to be the game Borderlands 2. It went on sale on Steam for like half price about a week ago. I picked it up and I’ve been having really a lot of fun playing that one. So, I highly recommend it, of course. It’s pretty obvious that it’s a really good game based on the reviews it’s getting. I want to pick MechWarrior Tactics. It’s in closed beta right now and if you pay $20 to become a founder, or more, then you can get into the beta. And I’m interested in checking it out but I have this problem with free new gamesome. This is like a half pick, right? If anybody listening has played it and thinks it’s actually really fun, then let me know because I’d like to pick it but I’m afraid to pick it and I’m afraid to pay money for it. And for my last pick, just this last week, I published my second Pluralsight course. It’s on testing JavaScript, client-side JavaScript at Pluralsight.com. And so, if you’re interested at all in testing Pluralsight JavaScript, or testing client-side JavaScript, then you can pick up a free week trial and watch my course and not have to pay a penny for it. CHUCK:  Awesome. Alright. So, my picks this week are some picks that I’ve gotten into with PeepCode. Do you guys know what PeepCode is? TIM:  Yes, they’re awesome. CHUCK:  Yeah, they do videos. TIM:  Screencasts. CHUCK:  Screencasts. Oh, I know Tim knows what it is because he has a Play by Play on there. But Geoffrey Grosenbach runs it, he’s super awesome guy. He used to run the Ruby on Rails podcast. He’s been doing videos like this for a long, long time. And they’re usually some kind of tutorial on how to get into something. Their most recent one is ‘Fire Up Ember.js’ and it has all the latest stuff from the Ember code, the new router, all that stuff. I haven’t had a chance to watch it yet but I just bought it and I am excited to go through it. So, I’m going to recommend that. I’m also going to recommend another one. And this is something that I’ve kind of gotten into more recently is DevOps. And the thing I like about DevOps is that it takes a lot of the pain out of setting up and managing servers which I did for a living a while back, quite a while back. You can keep everything up to date with it. You can tell it what versions of what packages you want, things like that. So, I bought their Meet Chef series, as well. And so, there are two videos there. I’m going to put those up. I don’t remember how much they cost. I think they’re like $10 a piece or something, per video, or you can just sign up for their unlimited subscription and just watch all of their stuff. Most of their stuff is pretty good. It’s easy to follow and Geoff does a pretty good job pulling it all together. I think he has people help him with a lot of these. So, they do a lot of the recording and then he does the narration and they’re terrific. They’re just super. So, I’m going to recommend those two videos. And we’ll wrap up the show. Thanks for coming, guys.

x