044

044 JSJ Book Club: Effective JavaScript with David Herman


Panel

Discussion

01:01 – David Herman Introduction

01:45 – Effective JavaScript by David Herman 04:27 – Reader Opinions & Controversy

09:09 – ES3 Shimming 11:25 – Code: effectivejs/code 12:50 – Parts of the Book 15:54 – Blocking

17:28 – Book Level of Difficulty

20:09 – Asynchronous APIs

  • Recursion
  • Tail-Call Optimization

26:51 – Programming Language Academics 30:55 – DOM Integration

31:50 – Advice for JavaScript Beginners

33:16 – Advice for Programmers in General 34:53 – Performance 38:16 – The JavaScript Language 40:45 – Primitives Vs Wrapper Classes 42:37 – Semicolons 45:24 – -0/+0

Picks

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

CHUCK:  The most effective way to hack is quickly. [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 44 of the JavaScript Jabber show. This week on our panel, we have Jamison Dance. JAMISON:  Hello. CHUCK:  AJ O’Neal. AJ:  Yo! Yo! Yo! Coming at you live from the living roomisphere of Provo, Utah. CHUCK:  We have Joe Eames. JOE:  Hi. CHUCK:  Merrick Christensen. MERRICK:  What’s up guys? CHUCK:  Tim Caswell. TIM:  Hello. CHUCK:  I’m Charles Max Wood from devchat.tv and this week, we have a special guest, Dave Herman. DAVE:  Hi there. CHUCK:  So Dave, you haven’t been on the show before. Do you want to introduce yourself? DAVE:  Sure. I work for Mozilla. I have sort of helped create this new department called Mozilla Research where we do a whole bunch of web platform experiments and new technology for the web. And I also am on the horribly named TC39, the standards organization for ECMAScript, working on the next edition of the JavaScript standard. CHUCK:  Cool. DAVE:  Oh, and I wrote this book. CHUCK: You did this book. TIM:  You didn’t just read it and then become an expert on the book and then talk on a podcast about it? [Laughter] CHUCK:  So, I heard about this book. I’m a little curious when you started writing the book, I mean, what was the idea behind it? What inspired it? DAVE:  To tell you the truth, I had no intention of writing a book, it didn’t occur to me. But the publishers reached out to me, I guess they heard of me through TC39, maybe ‘es-discuss’ or something. But they said, “Okay we’ve got this series, this Effective series.” And I was very familiar with Effective C++ which I think is a great book and I really like the format. And just when they approached me, I kind of thought, “You know, I kind of do have a few things to say about JavaScript. This could be a fun project.” I think what I really enjoyed about it was just getting to collect my thoughts in one place. So, it really just sort of was unexpected. JOE:  I’m just amazed by the number of things that you came up with, not that, I know that JavaScript just has tons and tons and tons of really just awesome nooks and crannies to look at. But I can think of ten things that would be useful to say. So, the fact that you came up with 68 of them is just amazing. DAVE:  It kind of happened organically. It was like I sort of had some topics that I could talk about. And then, when I thought about those topics, I started drilling down. And before you know it, you start realizing, “Wow, I should really talk about this. Well, if I talk about this, I got to talk about that.”  And it just kind of builds up from there and I ended up having to cut some things. JOE:  So you didn’t start off with like 65 ways off the top of your list, and you just add three? DAVE:  [Laughs] No, we’re also lucky that the number wasn’t something else. I had no number in mind ahead of time. I didn’t even know until I finished and counted them up. TIM:  So no one has said this yet but the book is amazing. It’s the best JavaScript book I’ve ever read by far. JOE:  Same. TIM:  So, thanks for writing it. It’s awesome. DAVE:  Thanks! TIM:  I’ve actually seen lots of people congratulate or talking about how awesome it is too. So, it seems like everyone really likes it and I wonder if it’s really gone to your head and now you make people call you ‘D-Money’ or something. [Laughter] DAVE:  No, I get enough angry people about various opinions about JavaScript that it… TIM:  …balances out. DAVE:  Yeah. I have gotten a lot of good feedback and I really had no idea. It’s kind of terrifying. I had no idea how scary it is to write a book. But I just didn’t know how it was going to be received. So I’ve been really pleasantly surprised that people seem to be happy with it. CHUCK:  So I have to ask, what is the most controversial part of the book? DAVE:  Controversial? CHUCK:  What is the part that people are getting mad at you about? DAVE:  You know, they haven’t gotten mad at me yet about the book. I get more opinions about ES6 than I do about the book. But it hasn’t been out for very long so I’m sort of waiting to hear more. I’ve certainly gotten a share of typos. And the most embarrassing thing was that I kind of misused the term currying, item 26 says, “Use binds to curry functions.” I really should have said, “Use bind for partial application.” And as a programming language nerd, I should have known better. TIM:  Yeah, don’t you have a PhD in Computer Science and programming languages? DAVE:  I do. Yes. TIM:  Did your advisor call you up and chew you out or something? DAVE:  You know, my advisor didn’t point it out. So, maybe we could shift the blame on him. It was actually Reg Braithwaite who goes by Ragan Wald, pretty well known Ruby hacker and JavaScript hacker and Coffee Script hacker, he pointed it out to me. He’s also working on a book where he talks a lot about partial application and currying. So, he cares about that quite a bit. And it’s totally embarrassing to have a PhD in programming languages and get a PL term wrong but presumably, I’ll be able to fix that in the second edition. CHUCK:  So they’re going to revoke your PhD commitment. DAVE:  Oh, undoubtedly. I’m surprised it didn’t happen sooner. But I guess if I were going to guess what’s going to end up to be the most controversial, it might be that when I’m talking about objects and prototypes, I spend a fair amount of time talking about how to write in a class like style. And I know a lot of people get very, very protective of JavaScript as not being a class base language and being all about prototypes. And I’m actually pretty easy going as far as people’s preferred style. I think that people should write the code that feels right to them. But if you’re writing in a class like style, there’s a lot that you need to know to simulate that and that’s really why I wrote it. It wasn’t to say, “Thou shall write OO programs with classes.” JAMISON:  I remember when I was reading it, the only part that I objected to a little was the parts on the Wonder Bar Proto, because I think it’s fun to mutate the prototype. But I understand why it’s dangerous too. AJ:  I don’t think the book’s going to be terribly controversial because I felt like it was pretty objective honestly. You covered both parts of the semi-colon debate, although all kind of nasty gross arguments that people are getting into. I feel like you covered them fairly like, “Okay, this is just how JavaScript works.”  And you didn’t delve into a mini, “This is what I like.” You know what I mean? MERRICK:  Yeah. I was disappointed that there wasn’t a section that said, “Don’t forget to put semi-colons everywhere.” Or, “Don’t put semi-colons in,” one or the other. AJ:  No, I liked it. I liked how objective it was. DAVE:  My goal was to arm people with an understanding of the consequences of their choices. Between consenting adults, I think people can write the code they want to write. I didn’t want to end up with a book that was kind of so uncontroversial that it wasn’t saying anything. But what I really wanted to get into was, “Look, you can have this debate. You can be on either side of the debate but you better understand what the consequences are of your decisions.” CHUCK:  So to me, it sounds a lot like ‘JavaScript: The Good Parts’. It’s like, “These are going to tear your head off if you don’t do them.” Is that kind of the direction you were heading? Or was it really more just, “Here are the trade-offs of one decision,” or the other? DAVE:  I think the good parts are more opinionated than my book is. I think it’s really trying to say — actually, the way I like to look at it, and this is a very appropriate thing particularly for beginners, I like to think of it like when you go bowling with little kids and they fill the gutters with those padded bumpers. So, they kind of aren’t really playing the full game of bowling, but it helps kind of get them into the form and the motion and the basic idea of the game. Eventually, they can grow up and take the pads out and it’s a little riskier but now they’re playing the full game. I think when you start with the good parts, it basically cuts out part of the language and says, “Don’t use this, just don’t even go near it.” And that will protect you from a lot of things but it’s also cutting out parts of JavaScript. So, I think with my book what I’m trying to say is, “Well, here’s a little bit fuller picture. But you need to understand what the pros and cons of things are.” AJ:  The one thing about that is, I did feel that the book had too much about ES3 shimming, and not enough about, “ES5 is here, it’s been here. It’s even in Internet Explorer, use it.” DAVE:  Interesting, I wonder what in particular you’re thinking of. AJ:  Well, just as I was reading through it, there was a lot of — you’re mentioning a lot of shims for ES3 but like… DAVE:  Oh, like objects I would create and stuff like that? Yeah. AJ:  Which is good, but then there wasn’t — I didn’t feel like there was enough of, like I’m letting you know about this problem if you’re working with IE6. And I kind of wished that you would have said just IE6 instead of just other browsers as this euphemism. DAVE:  [Laughs] Yeah, that’s a hard line. AJ:  Because it’s really just IE6 and like what? Opera for Wii or something? DAVE:  Not entirely. JOE:  Firefox 1. DAVE:  I’m not actually an expert in all of the individual browsers but I’ve certainly read a bunch of articles in preparation where it was like, “The BlackBerry Browser does this. The various older versions of Firefox do that.” And there actually were gulches in more than just IE6. AJ:  But one thing that I really love/hated about the book, was almost every example, you start out with like the worst possible way to do it. And my gut is just like churning inside and I’m like, “Please, don’t show people that. Please, don’t show people that.”  Then, I have to turn the page because the paragraph finishes and it’s like, “That is a terrible way to do it. This is the right way to do it.” And then, I’m like, “Phew.” It’s like a roller coaster. DAVE:  Rebecca Murphey and, I think, Rick Waldron both pointed that out when they were reading drafts of the book. They were like, “I am terrified of you publishing these bad ways of doing things. Even though you correct them, somebody’s going to come and copy and paste it and just not notice that it’s the bad way.” AJ:  Oh, sweet! Dictionary class, nice. [Laughter] DAVE:  I tried to do as much as I could. The publishers were really generous in letting me use color. And I tried to put red comments next to as many of the negative examples as I could. So hopefully, that is like a big red warning sign, “Don’t touch this code.” TIM:  Put the Unicode poop symbol. [Laughter] MERRICK:  Use the radioactive one. [Laughter] CHUCK:  Is the code online anywhere where people can get it? DAVE:  Oh, God! I’m behind on that. I’ve got two of the seven chapters transcribed. They’re on the Github repo. JAMISON:  Is that something someone could just do? Like if a reader wanted to just transcribe the code examples and then submit a pull request? DAVE:  I would welcome that, absolutely. JAMISON: And fix little typos? DAVE:  Yeah. I also have an errata page, they’re definitely a handful of typos. Some of which are even in the code and that’s a shame. So hopefully, in another printing, we’ll fix some of the simpler typos. MERRICK:  It’s certainly, from what I saw, nothing that you can’t just look at it and reasonably as a human discern like, “Oh, he said add text here and set text here,” you just rename the function. DAVE:  Yeah. MERRICK:  So, I want to point out for the people that are listening to this, like the kind of errata that’s in there is definitely not something that’s going to prevent you from being able to learn or follow the examples. It’s just stuff where you have to be slightly above monkey intelligence. DAVE:  Yeah. And if you do find that you’re confused by something like, “Wait a minute, that doesn’t make sense.” It might not hurt to just take a quick glance at the errata page and see it was just a typo rather than you’re misunderstanding something. But anyway, the Github repo is github/effectivejs/code is where you can get the code samples. It’s only chapters one and two right now. And yeah, please, if somebody wants to help out, get this transcribed faster. I’ll be happy to accept pull requests. JAMISON:  So to me, reading the book, I think there’s two main parts to it. There’s the first five chapters that teach you the language and what the language has and every gotcha you could have. And then there’s chapter six and chapter seven which are basically best practices, like how to design libraries, how to do concurrency. And I mean, there’s nothing in the language of semantics or syntax there. It’s just how to more effectively use the language on top of understanding how it works. I mean, do you see a similar split or is it just more of the same? DAVE:  No, absolutely. And I think, one of the things I really wanted to do was get at — I guess, it’s a combination of best programming practices in general. But also, styles in programming that I feel like JavaScript particularly fits nicely with like, that go with the grain of JavaScript. For example, I talk about structural typing in item 57 that may be one of my favorite items in the book. I feel like structural typing is a perfect fit for a language like JavaScript because first of all, with dynamic typing, you don’t even have to declare an interface or anything. Some people call it duck typing. It just fits very smoothly with a dynamically typed language. But on top of that, JavaScript has the really concise object literals that make it super easy to construct an instance of a structural type. So, while it’s true that it’s not kind of specific to JavaScript, structural typing is a concept that exists in a lot of languages, I fell that it’s a particularly good fit for JavaScript. But it’s true that six and seven are getting a little bit more into how to use the language effectively at a bit of a higher level and not as much about the mechanics of the language. JAMISON:  Especially chapter seven, like it starts out with, “Don’t block the event queue on IO.” And I know the browser has always had non block in IO, but it’s never really been an issue because the only APIs you get are non-blocking for the most part unless you do a sync XHR. Now that we have Node and I’ve been working with Node for the three and a half years, it’s like, “This is a big deal.”  And I like that there’s several items talking about these things that have come up as people try to use JavaScript in the server and it’s a bigger issue. DAVE:  Although I will say as a Mozillan, it’s a problem that we’ve been dealing with for years in the internals of Firefox, because the UI at Firefox is all implemented in JavaScript and XPL which is a kind of earlier variant of the newer flex box style of CSS and HTML. Anyway, so the JavaScript APIs that we have internal to the browser implementation do have a lot of blocking IO and we do find that some of our performance issues in Firefox are because somebody was careless about blocking the main thread. CHUCK:  Wait, did you just say Mozillan? DAVE:  Yeah. CHUCK:  It rhymes with Villain. [Laughter] JAMISON:  So, I also want to point out that with the browser, there are issues now of blocking in such a way that it could prevent the user’s interactions. In particular, Joe, you were at the presentation where Aaron Frost was talking about doing motion detection, right? JOE:  I only caught the tail end of it. JAMISON:  Okay, but that raises a very good point. He’s taking an image that he’s getting using the GetUserMedia API, and then he’s running an algorithm on it that’s going through all of these million pixels and he’s doing that every so often. The way that he did it in the presentation was he was only doing it every 200 milliseconds. But if you were designing like a live motion tracking type system where you’re iterating over video frames, you can get into a situation where you need to follow one of those patterns of, like process some of the data, let the event loop continue for a loop, process more of the data. DAVE:   Yeah. And actually, item 65 talks about that more specifically like it’s not only IO but it’s also a long running computation that you want to make sure doesn’t hog the main thread. TIM:  It’s just cool that people are doing things in browsers now that could do long running computations, like people are starting to do some really interesting stuff in browsers that you could never do before. DAVE:  Absolutely. JAMISON:  I’m going to put a link to his, Aaron Frost’s presentation notes because since I mentioned it, it’s pretty cool. TIM:  One thing I really liked about the book was how you don’t shy away from talking a little bit about some of the low level details and just about how some of the language works and just how computation works in general. I think there’s a lot of people who use JavaScript who don’t come from a traditional Computer Science background. So you talk about bits, and people might not know what bits are or that computers are made up of binary digits. Or you talk about stack frames and how a function call pushes a new thing onto the stack and stuff like that. I just thought that was really cool. And it’s done in a simple, easy way to understand but it’s also giving you some real understanding of what’s going on in the background without just glossing over things. DAVE:  Thanks. Yeah, one of the things I really cared about in writing this book was I didn’t want it to come across — I mean, Effective C++ is seen as this very serious book and it’s used  by serious practitioners of serious programming. And I didn’t want Effective JavaScript to look like Effective C++ light or the kid sibling of the other Effective books because I think that JavaScript is a serious programming language where you can do serious work. And I think programming is hard, no matter what level you’re programming at. So I didn’t want to shy away from really getting into the more advanced topics. At the same time, people have pointed out that this can be a little daunting for beginners. So I would kind of recommend for people who feel like one of the items they’re reading is kind of going over their head, to just not worry about it and put that item down and maybe go on to some of the others and revisit it later. Maybe the first time they come across a program using bit wise operators, they can go back at that point and revisit that, for example. MERRICK:  To echo that sentiment, there are some things about JavaScript, and I don’t come from a Computer Science background. But there are some things about JavaScript that I’ve kind of just accepted like, “Oh, you can’t call array prototype sort method on strings because of something in the JavaScript internals.”  But come to read Effective JavaScript, you learn that strings are essentially a mutable array. So, the difference between the methods that you can call and what you can’t call are whether or not they’re manipulating the existing strength rather than returning a new one. And those kinds of insights, also the way that imagers are stored in JavaScript engines and the way strings are stored, like it just helped me not shy away from a lot of the, “Oh, that’s just how it works,” kind of things. So, I loved that aspect of the book. DAVE:  Great. MERRICK:  The other thing that I found interesting that I found myself doing a lot is you mentioned in the book about how asynchronous APIs should not call until the next turn of the event loop. DAVE:  Yes, I’m so glad you said that. [Laughter] MERRICK:  Even if you have that internally or you can immediately call it back, you should still wait till the next turn of the event loop so people can know not to block, or do some sort of expensive computation or you break the contract. And I never even considered that as being part of the contract until you mentioned that. DAVE:  It’s so subtle. I really believe that there’s a lot of really subtle gotchas in designing asynchronous APIs. That they’re rare enough to get bitten by, and they’re hard enough to diagnose that when they actually happen, you’re not even sure why your program’s going wrong. You’re just like, “Wow, I’ve got this occasional bug and I can’t figure out where it’s coming from.”  And it may well be deep in the guts of an asynchronous API. And I have this feeling that, that one is actually out there and biting people. But it’s a little hard to prove. That one’s important. I think it was an article by Havoc Pennington talking about C sharp APIs that crystallized that one for me, where he was basically making the same point in callback based APIs. And I think he was talking about C sharp there. But it applies just as well in JavaScript. MERRICK:  Yeah, it was brilliant. JAMISON:  I know I’ve heard lots of the promises, people talk about that too. And one of the things the promises are supposed to do is always make things that are supposed to look async, be async and it definitely carries over to callback based code. DAVE:  One of the subtle things that can go wrong is if you call it in the wrong stack and it throws an exception, it’s really subtle to get the catching of exceptions. And when you’re writing one of those libraries, you have to think of every line of code so carefully and you get one thing wrong with exceptions and kind of everything goes wrong. So that’s definitely an area where you have to be super careful. JOE:  And even using, for example, using functions to essentially recursive functions, to iterate on the async operations. Things like that were just so insightful. Like I said, the book is just amazing. I just loved it. DAVE: Thanks. Yeah, recursion is one of those things that I think it’s seen as a pretty advanced thing by a lot of people. And in the programming world, it’s kind of bread and butter. People use it everywhere. In a language like JavaScript, if you’re doing asynchronous program with recursion, you’re actually likely to blow the stack if you have a lot of data. In fact, some languages like Python really punish you for using recursion and they give you a really smaller stack that blows up sooner. But when you’re doing async stuff, when you want to do a loop asynchronously, you’re actually forced to use recursion. So, it’s something that you can’t really avoid learning once you start writing more asynchronous programs. AJ:  Yeah. And on that note, it seems like I’ve read recently that JavaScript is going to try and do some sort of tail-call optimization or something to make the synchronous recursion not blow up the stack. Is that true or am I totally wrong on that? DAVE:  It’s half right. So, we’re definitely — the committees agreed to have what’s called Proper Tail-Calls in ES6. But that’s only for one specific kind of recursion. That’s for tail recursion which is basically when the last thing that your function does is to return the results of calling another function. And so, when you’re returning, calling that other function, rather than keeping your stack frame around kind of pointlessly, you can actually pop your frame before you call the other function. That’s actually only one of the limitation strategy a JS engine could do differently. But a reasonable way to think of it is before it calls the other function, it pops the current frame. So what that ends up doing is if you do a whole bunch of tail-calls, like maybe just some long sequence of tail-calls, you’re never going to be growing the stack because it’ll keep popping and calling, popping and calling, popping and calling. But that only works for tail recursion. So, if you have a recursive function call that’s not a tail-call, your stack is still going to grow and eventually, all the JS implementations will blow up. There are other programming languages where they will actually continually grow the stack. So, kind of like a link list where instead of an array, it can keep growing forever. They’ll grow your stack and they’ll let you use as much recursion as you want to. It will slow down eventually but it will keep growing. But that really is kind of different from the way the architecture of the JS engines works. So, that’s not likely to happen. Sorry, long story short, tail-calls are happening but not general recursion. AJ:  Okay. MERRICK:  The other take away is that there’s going to be a hit R&B song called ‘Popping and Calling’, pretty soon. [Laughter] TIM:  So, you say these are proper tail-calls, not just implementation tail-call optimizations. What’s the difference? DAVE:  Yeah. That’s a subtle point. And from the standpoint of the implementation, it’s maybe not much different. But from the programmer’s standpoint, what it means is you have a guarantee. The language mandates that an implementation must not grow the stack without bound when you do tail-calls. And that means that as a programmer, you can rely on that; whereas with tail-call optimization, it’s just sort of a best effort. It’s like the compiler will try to optimize this in some cases, but you can’t count on it. So, one analogy that I make is, imagine that for loops, every time you start at a new iteration of your for loops, it pushed a stack frame. You’d never really use for loops because you wouldn’t really be able to count on them not blowing up if you had too many iterations. And if you had a compiler that said, “Sometimes, for loops will blow the stack and sometimes they won’t.” As a programmer, you still wouldn’t be able to use it because you wouldn’t be able to rely on it. But if the language mandates, “Your for loops must not blow this stack without bound,” which of course, that is what the language mandates. It just doesn’t bother saying it because with for loop, nobody expects the stack to blow. But with tail-calls, sort of historically, languages haven’t had proper tail-calls. So, if you don’t actually say it explicitly in standard, “You must have proper tail-calls,” then in practice, the engines aren’t going to implement proper tail-calls and programmers won’t be able to rely on them. JAMISON:  Yeah. So, I wanted to ask you, we’re kind of getting into some of it too, the more programming language like academic stuff. You definitely have a background in that. How much of that came out in the book? DAVE:   I think some of it does. It’s kind of hard not to get into it. It’s definitely one of my favorite topics. And you can also probably sort of relate it to that, a lot of the programming languages world, like especially the research world, does a lot with functional programming. So, I have a lot of background in functional programming. And I think you can see that coming out in the book too, talking about binds and currying – which I should have called partial application – and structural types and recursion. Those are all programming topics. And when you talk about getting into some of the internals, like how stacks work when you’re doing recursive calls, that’s certainly a programming language-y topic. But I did try to think always from the standpoint of the user of the language. There’s a sort of disease that PL people get of being so obsessed with the technology itself. So, I really wanted to keep the book focused on, even if I’m talking about sort of nerding out on PL details. It really should be only in as much as it matters to the programmer. JAMISON:  That’s really cool. You should talk to some of my professors. [Laughter] TIM:  That was one of the coolest tricks that I took away from the book by the way it was the partial application with bind, particularly how that cleans up your for each loops and basically all those asynchronous APIs that take callbacks. That was just so cool. DAVE:  Cool. TIM:  Do you guys know if underscore and all those bind up limitations does kind of a similar thing? JOE:  I’m pretty sure they do. All the code that I’ve looked at does. TIM:  Cool. JAMISON:  So one other thing that I want to talk about too that I really liked, I feel like lots of JavaScript books will try and kind of pad their pages by including API references and DOM/API stuff. And that was one thing I actually really liked about this book is it’s just JavaScript. It doesn’t have anything that you can just Google on or look on MDN for. But it’s just the interesting stuff that is useful to have someone explain to you. Not like, “What’s the name of this function that you use to select something by its ID,” or whatever. It feels very streamlined, I guess. AJ:  I would argue. It would have been nice to have a section where it gave references to other good documentation. Because I think the book has great documentation, most of the documentation online for JavaScript sucks really bad. And it would have been nice for like, an ‘other resources’ section with a link to Mozilla Developer Network, and a link to the Node API. DAVE:  Any time you put that stuff in print, it goes out of date so fast. AJ:  Well in the end, is it going to disappear anytime soon? DAVE:  I hope not but it could. And then in ten years, there will be this link. Like I read these books from ’95 and they have links to like just these defunct websites that don’t exist anymore. So, I don’t know. I like it. AJ:  I would say it’s a net game. DAVE:  I think it’s a fair point. And also, if I had enough links that started going stale, we could always do another edition of the book. I assume eventually, there will be another edition. For example, once ES6 ships, we’ll want to update the book to have more stuff based on ES6. But yeah, I take your point. I think some references to kind of more information or more reference material wouldn’t hurt. MERRICK:  But still the fact that it’s just about the heart of JavaScript and [crosstalk]. That’s awesome. TIM:  And it acknowledges multiple platforms; and also, the history that you have to deal with in practice. MERRICK:  Do you think there’s a place for a book about DOM integration, an Effective book about DOM integration? DAVE:  I bet there could be. I think I’m probably not the person to write it because I really was writing about what I know which is the language. And the DOM is, I really wouldn’t call myself an expert at it. But I think there are so many gotchas in the DOM, both in terms of just weird API design, as well as interoperability issues where things were unspecified and different browsers do it differently. Yeah, I think there’s probably a lot. In fact, there’s sort of a precedent for that in the Effective series. The first book Effective C++ has a separate book, ‘Effective STL’ which is about the C++ STL library. So, I think that’s not unheard of. That would probably make a lot of sense. JAMISON:  Yeah, this is not in the topic in the book but it’s something I think a lot of listeners would be interested in. I’m wondering what kind of guidance would you give to somebody who wants to learn JavaScript really well? DAVE:  I’ve thought about that question a lot. And I think it varies a lot based on a person’s background. So, I think for people who already have some programming experience in other languages, I think my book is actually a pretty good place to start because they’re not going to need the kind of basics of programming and some of the more introductory topics. What they really want to know is, “How is JavaScript different from the stuff that I already know?” And I think this book kind of hits that pretty succinctly. For somebody who’s more of a beginner programmer, I think it’s missing probably too much introductory material. And there’s a lot of good stuff out there. I mean, I like Marijn Haverbeke’s book ‘Eloquent JavaScript’. I actually have been meaning to read Cody Lindley’s book ‘JavaScript Enlightenment’ but I haven’t had the chance to read that yet. A lot of people swear by that one too. And then there’s, if you’re not in a hurry to get straight into JavaScript, I’m actually a big fan of the book ‘How to Design Programs’, which is using scheme or actually the racket directive scheme. It’s maybe a little more academic but a really good introduction to programming from kind of a functional programming perspective. JOE:  How about outside of JavaScript. Is there anything that you could tell programmers on how to, I guess, up their game? Or what’s influenced you the most as a programmer yourself? DAVE:  I guess, I just really like to hang around people who are smarter than me. That for me is the way I’ve learned the most. So find your community, and that community can be of any sort. For me, a lot of it was Grad school where I was actually physically around a whole bunch of just incredible programmers. But in this day and age with Github and IRC and all sorts of online resources, I think it’s really about find yourself some open source projects. Get involved and just hang out with talented programmers and try to learn from them what you can. TIM:  I like that. Based on what I read out of your book, I imagine when you want to get around with people that are smarter than you, it’s hard for the three of you to get together. [Laughter] TIM:  I look at Mozilla, and Tim Disney, we had him on for macros and I was like, “This is an intern.” Like, “Are you kidding me? This is the intern quality that these guys have? These guys are insane!” They’re smart over there. DAVE:  Yeah. So he interned with my group at Mozilla research and we’ve got a just incredible program. Our group is phenomenal. And I just go to work everyday, hoping nobody will notice that I don’t belong there. [Laughter] JAMISON:  I think the biggest thing I took from the book is to not prematurely optimize my code. Now, let me explain what I mean. I’ve been doing Node for the last three years and one of the big pushes in Node is to make your servers fast, make your servers faster, make them really, really fast and faster than everything out there. And so I’ve learned all these techniques like if you manually cache your array link and all these things that make your code faster. And reading the book and reading things like, “Actually, no. You shouldn’t call back synchronously even if it’s slightly faster. Worry more about proper API than just being slightly faster.” It’s balanced me out a little. So, that was useful. DAVE:  That’s good. I think that’s kind of a perennial challenge in programming. Performance is a feature but if you have a highly performed program that’s just doing the wrong thing, it’s not so much use to anybody either. Hopefully sometimes, you can find that you can divide things up so that the really good interfaces, the really well engineered stuff is sort of the external interface to your program. And you can just optimize some part of the internals and get the performance you need without having to sacrifice the right API that your clients are going to really like. JAMISON:  Yeah, it’s a tough balance, like on the ‘don’t callback synchronously’ thing, I’ve been telling people for months, “Well, there’s some cases where it’s okay because you really need the performance.” And I’m sure that’s been misunderstood to mean that you can callback synchronously from an async function. DAVE:  Yeah. JAMISON:  Because I mean, there are cases where it makes a huge difference in performance, especially if you don’t have a really fast Nextick or Setimmediate or something like that. DAVE:  Yeah, it’s a tough one. And hopefully, if this becomes enough of a bottleneck, the platforms can kind of do better than Set Time Out which is throttled to four milliseconds and just horrible from a performance perspective. But yeah, with this exact issue, I think I heard it came up in the Windows 8 API where they have a promises library that sometimes does callbacks synchronously. And I imagine that decision was made on the basis of performance. But I’m not sure it’s not going to come back to bite them. JAMISON:  There’s another similar one you have later in chapter six, you distinguish between arrays and array-like. And I mean, that’s a gotcha. How many times has someone tried to push onto their arguments and there’s no push method? I mean, if performance didn’t matter, you were just always trying to do an array or change the language so that arguments is always in array. DAVE:  Yeah. That’s true. JAMISON:  Instead, we just document clearly. This thing is array-like, this thing is a real array. I had the same argument for callbacks, like this async function can call back synchronously, it’s documented, be warned. Maybe that one’s not worth it even. I don’t know. DAVE:  I think that one’s useful even if you’re not thinking about the performance aspect of it, just to know the difference between whether an API’s expecting a true array or an array-like because otherwise, you’ll just possibly pass it the wrong thing. So that’s sort of, at the least, about kind of clear documentation JOE:  It kind of echoed your own sentiment about structural typing too. JAMISON:  Another thing I really liked that Tim kind of touched on is JavaScript can feel like an easy target for people to pick on sometimes. Like all of the crap double equals and triple equals and sometimes they do different things. And sometimes, my variables don’t get declared when I think they will be and I don’t know. There are lots of things that are different about the language and people coming from other languages tend to look at it and say, “Those are awful things because they’re different than what I expected, because they’re terrible.” And you just kind of clearly explain the rules. You’re not like, you don’t apologize. You just say, “This is how the language works.” And lay it out very clearly without pandering to that, “JavaScript is crazy. WTF JS,” kind of thing. I don’t know. JOE:  The worst he gets is to say it’s unfortunate. [Laughter] DAVE:  Yeah. Don’t get me wrong. I think there are some mistakes in JavaScript and there are some that, behind closed doors, I’ll get pretty upset about. But the fact is I think it’s a lovely language and I think you can do a lot of great things with it. And it got some really important things right. You know, the fact that you got closures right, and that it has just really beautiful little syntax for erase functions and object literals, you can go so far with just that core of the language. And yeah, this book is not about apologizing for JavaScript. This is like, you’re using JavaScript whether you don’t have to worry you’re not using it so this is how you use it well. JAMISON:  Yeah, you might as well know it if you’re going to use it. MERRICK:  So you said that sometimes you get angry. Do you just like to march into Brendan Eich’s office and have it out? DAVE:  Brandon said he’s past apologizing. [Laughter] MERRICK:  How cool is it to actually work at the same place as that guy? DAVE:  Oh, man! I don’t want to idolize him too much but it’s just been an incredible privilege to work with Brendan. I’ve actually known him now for seven years and I’ve worked full time at Mozilla for about three and I can’t say enough. It’s amazing to work with him. He’s an incredible person. AJ:  Yeah, he seems like a genuinely good guy. The amount of, I guess, people are just being tools to him. He takes it all pretty professionally. DAVE:  He does better than I do. It just rolls off his back which I’m impressed. Please don’t take that as encouragement to give him more crap. AJ:  I agree. I hate to digress just too much but one of the things I really liked with the array and the array-likes kind of stuff is you also touched on the difference between using the number constructor and the implicits. It was really interesting to me to see how JavaScript almost has like a sibling class structure for those primitives, that it leverages. DAVE:  I’m not sure I know what you mean. AJ:  When you do a primitive, like say you type in the number 15, it’s not the same as doing new number 15. DAVE:  Absolutely, the primitives versus the wrapper classes. AJ:  Yeah, the wrapper classes. That’s what they’re called. I’m sorry. Scala has a similar notion of those, so I’m trying to not connect the words. But yeah, that’s right, the wrapper classes. DAVE:  I think Scala probably inherited that directly from Java because, and JavaScript definitely inherited that from Java. Back in the day, JavaScript, despite the fact that in this day and age, people really just think it’s unfortunate that it has the word Java in it because the languages are so different. But originally, it really was designed to be a companion language to Java. So in some ways, they sort of tried to keep them in sync with each other. Java had this concept of primitive types that were not objects because basically, it was a compromise for performance. This kind of goes back to Tim’s point of premature optimization, it’s this sort of pan full distinction that there are these special, not quite object values that sometimes act like objects and sometimes don’t. And another way that people can design a language is actually to really go all the way and say that everything really behaves as an object. But JavaScript and Java, at least back in the day, they were able to get better performance by having these special primitives. AJ:  Yeah. JAMISON:  I think it would be a shame to go a podcast without talking about semicolons. And you boldly approach this issue, this mind field and talk about the rules of automatic semicolon insertion. Was this your reaction? Like did this happen after that debate kind of blew up? DAVE:  I think I was writing it after the debate blew up but I already knew that I was going to write about it. The fact that there was this debate probably affected the way I wrote about it. It probably was getting on my nerves enough that I decided not to pick a side. To tell you the truth, I’m just going to go ahead because, “Hey, why not? Let’s debut Dave Herman’s opinion of ASI on JavaScript Jabber.” My preferred style is probably weird enough that nobody else in the world wants to use it. I actually use semicolons basically everywhere except if it’s at the end of a block. So, if the next token is a right curly, I always drop the semicolon. It makes no sense at all but somehow there, it just seems so clearly unnecessary. MERRICK:  It feels so awkward there. TIM:  How many parsers have you written? [Laughter] DAVE:  I think another part of it is, sometimes you’ll write like an array.map with a callback function, and the callback is just doing some pure computation like maybe you do, array.map function X, return X+1. And what I really, really want there is an expression syntax rather than the clunky return statement. And leaving off the semicolon makes it feel just a little bit more like an expression. [Laughter] DAVE:  But anyway, my golden rule is be consistent with whatever the house rules of the code base I’m working on. JAMISON:  I fell like this section makes everybody happy because it explains why automatic semicolon insertion happens, and it explains the rules of it really simply and concisely. But then, you also, I don’t know, still show semicolons and talk value using it. It feels very non-partisan. CHUCK:  That’s the big thing with the rules is, you follow the rules until you understand why they’re there and then you can start deciding when to break them. DAVE:  The one thing I think is inexcusable is people going around and claiming that, “Oh, it’s straightforward. You don’t have to use semicolons.” [Laughter] DAVE:  It’s simply false, like you have to know the rules because if you just leave off your semicolons, there are gotchas. So, it’s fine if you want to take advantage of semicolon insertion but if you don’t know the rules, you will get bitten. CHUCK:  Yeah. Alright, are there any other angles we want to cover before we get into the picks? JOE:  Yeah. I just want to ask one more question. Why is it that you didn’t cover -0 (negative zero) and +0 (positive zero) in your book? DAVE:  I can’t remember if I thought about including that at some point. I mostly try to get by as if there is no such thing as -0 (negative zero). And even === (triple equals) treats it as the same as 0 if I’m not mistaken. So by and large, you can mostly just pretend that it’s the same. There are a few examples where it’ll make your program behave just slightly differently. But maybe, I just haven’t come across the scenarios where it bites you. So I think mostly, it just kind of didn’t make that first level list. JOE:  So you just didn’t feel like it was worth the space on the page because it’s just not that big of a point to understand? DAVE:  I feel like you can get by never even knowing there’s such a thing as -0 (negative zero) but I may be missing some critical gotcha that means that that’s not true. So, I encourage anybody who’s listening, who knows better than I do, to educate me about that. TIM:  Just really quick, I want to mention that there is one thing. There’s just one tip about checking for an auto number and how the IF and AND function is kind of broken because it can coerce stuff into things that are actually not a number. I don’t know. So, it can have inconsistent behavior. And I thought that it was so cool that I Tweeted about it, “Here’s how you actually check if something is a number or not. Check if it equals to itself with the triple equals.” And so many people were like, “Ha…ha…dude, that’s nice but you know there’s an IF and AND function, right?” It’s just funny, it’s not widely known and it’s really useful. I thought that was cool. DAVE:  Yeah. That’s one of those like, where I’d use the word unfortunate in the book but IF and AND should not coerce its argument but it’s too late to change. CHUCK:  Alright. Let’s go ahead and get into the picks. Tim, do you want to start us off? TIM:  I’m going to do some shameless, self project promotion today. And I’ve been designing a new language for the last two weeks and it’s on my Github under Jack. And a lot of the things I like about JavaScript are in the language, a lot of things I don’t like aren’t in the language and who knows if it will ever become anything real but it sure is fun to make something up. CHUCK:  Cool. We’ll put a link on the notes. DAVE:  Does it run? TIM:  Does it run? CHUCK:  Will it blend? TIM:  It’ll run soon. I keep changing the syntax every other day because people give me feedback and I realize it was terrible. CHUCK:  What, the feedback or the stuff you did? TIM:  No, the feedback’s good. Although certain people at Mozilla keep trying to get me to make Lisp, not Dave. Goes by Gozalla, not Lisp, Closure. DAVE:  Yeah, it’s Raco. He’s a huge Closure fan. TIM:  Indeed, and Closure is a nice language but it’s not the language I want to make. CHUCK:  Somebody else already made it, I think. TIM:  Yeah. And they implemented in on JavaScript and Java and what else? It’s got a bunch of back ends. Anyway, so I guess my pick really is, making languages is fun. And maybe I can link some resources to that and maybe Dave knows a bunch too. DAVE:  Making a language, it’s probably good. I don’t know. These days I’ve been recommending to a lot of people SICP, Structure and Interpretation of Computer Programs. It’s not like when you finish that book, you’re not going to know how to make a language. But it gives you a lot of ways of thinking about writing interpreters and building languages. CHUCK:  Cool. AJ, what are your picks? AJ:  My technical pick is Putting Constants on the Left, because if you don’t put your constant on the left, it will never ever, ever, ever, ever, ever, ever be accidentally assigned to. It will throw an exception. God Bless America! And God Bless every language that can support that, which isn’t C++. CHUCK:  Okay. AJ:  Also, I am starting to do some screencasts and I’m putting them up on YouTube. And I’ll put a link in the show notes tomorrow where I’m talking about Amazon Web Services and just showing how to sign up for their one year free VPS type thing that they call EC2. And I am doing consulting. So I want to pick me and my screencasts, start looking out for them, they’re coming. Hopefully, they’ll have some cool stuff. And if you’re looking for somebody to hire, I’m available for short term work. CHUCK:  Cool. Jamison, what are your picks? JAMISON:  Okay, I’ve got two. I need to get back to some non-programming picks. These are both programming picks again. One is this blog post called ‘Notes on Distributed Systems for Young Bloods’. I guess ‘young bloods’ is what they said instead of like beginning programmers or newbs or something, I don’t know. And it just talks about all the tricky problems that come in writing Distributed Systems. And as someone who’s running into these problems, it was really good to see an overview of some of the ones we’ve already found and some that are moving ahead of us, just laid-out really clearly and concisely. It’s a great read and I think it will be probably one of those classics that people post around for a really long time. And then, my next one is just a Gist. I’ve been doing a lot with Ember lately, not putting full time into it. So, I get into it for a while and then leave and come back for a while and stuff. And it’s really powerful. It’s also really frustrating at times. So, this is Polotek, I can’t remember his real name again. But he talks about his experiences using Ember and some of the gotchas he’s found and the tricky things. And then Tom Dale, one of the core Ember guys, comes in and comments on the Gist and just goes through all of his comments and really nicely says, “Thanks for the feedback, and you’re right about this. We need to change this.” It’s just really cool, and then corrects some of his misunderstandings. So, it’s really cool to see this interaction between two people talking about this framework I use a lot. And I also learned a bunch of things about it. So, I’ll post those in the show notes. If you use Ember, you should look at the Gist. If you don’t, you might not care that much. But the Distributed Systems one is really good for everybody. CHUCK:  Alright. Merrick, what are your picks? MERRICK:  I’m going to pick this Hip Hop artist named Grieves. He’s just awesome. He’s from the Northwest and he’s just got some good jams. And aside from that, I’m going to pick the Scala programming language. Learning Scala has just taught me tons. It’s kind of a happy mix between object-oriented and functional programming that has really affected the way that I write JavaScript. CHUCK:  Cool. Joe, what are your picks? JOE:  My first pick’s going to be on a music artist, Antoine Dufour. He’s a guitarist. And he just has the most amazing, it’s kind of like a mix between sort of a classical and Spanish mostly, and then maybe a little bit of New Age. Just instrumental, no words, no singer. He does some duets with some other people and it’s just fantastic music. And for anybody that’s listening, if you do happen to listen to him, he has a song called Tango Agricole, and I’ve heard that song in a movie somewhere. And for the life of me, I can’t find out what movie. So if anybody out there figures that out, please let me know over Twitter what movie that song was in because it’s just driving me nuts. Then I want to pick, Torchlight II, the game. I picked it up over the Christmas break and I’ve been playing it a bunch and it’s a sweet game. I like it a lot better than Diablo III. I like the cartoony style of the graphics. It’s been a really fun game. And for my third pick, I want to pick the Appliness Magazine. It’s just a digital magazine and they have a lot of really cool articles in there. You can get it on your iPad for free or I think you can read it online as well for free. But it’s a really sweet magazine, all about development topics. CHUCK:  Alright, sounds good. I’ll go next and then we’ll let Dave go last. So, my first pick is something that my wife got me for Christmas. It’s called The Powermat and it’s one of those magnetic induction charger device things. And so, you can get what they call doors, they’re just these little magnetic squares that let your device charge. You can get them on phone cases and stuff or you can just get the Powermat. It’s kind of a universal one that has a mini-USB and adaptors for most of the devices out there. And I really like it. I just wind up switching my devices off of it all day. And so, everything’s always charged and it’s really kind of nice. I’m not sure how well it travels though it will probably go with me next time I go anywhere. My second pick is something that I got at CES. They gave me a review copy. The only issue that I really have with it is that it doesn’t have the lightning adaptor for my iPhone 5. Instead, it’s got the 30-pin adaptor so I can use it with my iPad. And what it is it’s — the company is called Fuse Chicken, and you can find them at fusechicken.com. What it is, is on one end, it has the USB plug and on the other end, it has the 30-pin adaptor for the iPod or whatever. And it’s this flexible, bendable charging cord. So you can use it as a stand if you don’t want to plug it in, or you can plug it in and then use it as a stand anyway, to hold up whatever it is that you want to have up and off the desk and kind of up where you can see it. Anyway, those are my picks and I’ll put links to them in the show notes. And we’ll throw it over to Dave. Dave, what are your picks? DAVE:  Well, I’m going to be greedy and take three. The first pick I want to talk about is, we mentioned it briefly I think, the Rust Programming Language. This is a language that my group has been working on at Mozilla Research for a couple of years. It was originally started by Graydon Hoare and the team has grown and it’s just an incredible team. The way to think about Rust is a replacement for C++ that has sort of the same performance level that C++ does but that’s safer and better at concurrency and parallelism. So, Rust is at 0.5 right now. We’re going to hit 0.6 probably this quarter. And our hope is to hit 1.0 by the end of 2013. So, it’s still changing a little but it’s definitely stabilizing and it’s definitely at a point where you can start playing with it and trying it out. And the reason for Rust’s existence, the reason why we’re doing it at Mozilla is, my second pick which is another project I’m really excited about, a project called Servo. Every browser has its engine. At Mozilla, we use Gecko. A bunch of browsers use WebKit but all these are kind of based on aging 90’s era technology and there’s enough competition that they are moving quickly. But Servo is really about rethinking, redesigning the entire guts of the browser to try to take advantage of modern hardware and to try to be more secure. So, Rust was designed to support Servo. Servo was implemented in Rust. So that’s just kind of getting started. But we already have a little bit of functionality. You can render some basic pages with it. I expect to see a lot more activity in Servo in 2013. TIM:  Do you anticipate Firefox switching over to that eventuality? DAVE:  Servo, right now, is a research experiment. And we’re not really limiting it to what its future could be. It could end up being a totally separate browser or it could end up being a part of Firefox. But one of the things we want to be open about is how much we can break with its compatibility. Within Firefox, we have to be absolutely web compatible. But if we’re thinking about possibly a new browser for the future, maybe we can say we can get much better performance if there’s some things that we break compatibility with. So basically the answer is we’re not going to commit to that until we know better how well it works. TIM:  Very cool. It looks like, maybe for the mobile feature, you guys are working on too. That’s really cool stuff. DAVE:  Absolutely, yeah. With mobile, multi-core and JPUs are just as important. So, that’s really high level. But basically, the nature of hardware is completely changing from what it was ten years ago and that’s happening across the board – desktops, laptops, tablets, phones. We’re already seeing eight-core phones coming out this year. So, software has to change to keep up with the hardware and that’s really what these projects are about. So, my third pick is not about Mozilla at all. My wife and I are expecting our first child in about a month. And Rick Waldron, who is a totally cool guy, sent us this gift. We’re not actually telling people what sex of the baby is. But he got us this little gender-neutral gift called ‘The Roominate’. The Roominate, I think, was designed by some Engineering women from Stanford who wanted to create something that would be kind of appealing to both boys and girls. I think they might have been focused more on girls but it could be just as good for boys. It’s like an engineering toy crossed with a doll house. So, you get to like play house but you also get to put pieces together and make things work. And I think it’s such a cool toy that I’ve been buying it for all of my friends who have kids. CHUCK:  That looks really, really cool. It looks like it is aimed at girls but I think my son would like it just as much. That’s great. Alright. Well, we’re going to go ahead and wrap up the show. Thanks for coming, Dave. And thanks for the writing the book. It’s an awesome book. DAVE:  My pleasure! Thanks for having me on the show. CHUCK:  I don’t think we have any announcements of anything coming up. I did set up a mailing list for the podcast and eventually, I will start emailing out in advance so that you know what’s coming in future episodes. So, go sign up for that and hopefully, we can start sending those out soon. And if you’re interested in learning Ruby on Rails, I’m going to be teaching that course starting in March. You kind of get unlimited access to me for eight weeks in learning Rails. And you can find that at railsrampup.com. Other than that, it looks like AJ has something that he wants to announce real fast and then we’ll wrap up the show. AJ:  Yeah. I just wanted to let everybody know that Open West Conference is coming. It used to be called Utah Open Source but now it’s being expanded to be a regional conference. There’s a wide variety of topics that you can choose from, basically anything open source-y. So, I want to see you there. CHUCK:  Alright, sounds good. Go sign up, Open West Conference, it’s openwest.org/cfp. That’s it. We’ll wrap it up. We’ll catch you all next week.

x