JavaScript Jabber

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

Subscribe

Get episodes automatically

066

066 JSJ Transitioning to JavaScript


Panel

Discussion

01:10 – Making the transition from one primary language to JavaScript

01:30 – Merrick’s Experience

03:32 – Joe’s Experience

07:46 – Moving from C# to JavaScript

  • Misconceptions

09:25 – JavaScript Misconceptions

10:59 – Chuck’s Experience

14:25 – Rails and JavaScript Avoidance

15:25 – Microsoft and JavaScript Avoidance

16:58 – JavaScript Development in General

  • Browsers and Problems

23:38 – Libraries and Tools

24:45 – Code Structure

27:03 – node.js

28:00 – Learning core concepts behind JavaScript

29:11 – Understanding Clojures, Scoping & Context

29:53 – Testing

31:35 – Deviating off the common path

33:10 – Idiomatic JavaScript

Picks

Book Club

JavaScript Allongé with Reginald Braithwaite!  He will join us for an episode to discuss the book on August 1st. The episode will air on August 9th.

Next Week

Testem with Toby Ho

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

CHUCK: Yeah, I can pretend I’m getting better at JavaScript. [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.] [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK: Hey everybody, and welcome to Episode 66 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE: Hi there. CHUCK: And Merrick Christensen. MERRICK: Hey guys. CHUCK: I’m Charles Max Wood from DevChat.TV. And this week, we’re going to be talking about, I think it’s kind of a blend of making the transition from one primary language to JavaScript, it usually happens through web development, and some of the mistakes that people make when their primary language is not JavaScript. Let’s go ahead and get started. Merrick, you’re kind of the expert guy that I always look at and go, “Man, he’s awesome at JavaScript.” So, I’m wondering, did you start out at JavaScript or did you come in from somewhere else? MERRICK: Oh, that’s really nice of you, man. I actually started out with ActionScript. I really loved Flash developments, but it’s the same thing, really. They’re both based off of ECMAScript. So, I guess you could say I’ve always done JavaScript. JOE: So, ActionScript is nearly identical to JavaScript? MERRICK: Well, not anymore. ActionScript 3 developed classes and they typed it and they did some interesting things to make it more of a full-featured language. It’s got more [inaudible] than JavaScript now, I think. But I ended up getting into JavaScript when I was like 17 or so. I came across the MooTools framework and ever since then, it’s been all JavaScript all the time. CHUCK: You’re pretty young. Wasn’t that last year? [Laughter] MERRICK: Close. No, about six years, five years of JavaScript. JOE: You’re also, though, like a real student of languages. You love studying other languages. MERRICK: I love programming languages, yeah. JOE: I think you’re a pretty funny, not necessarily unique, because I think there’s a lot of people that are taking the same path as you nowadays, but it’s pretty unique for people. Nobody with ten years of experience has done this, but learning JavaScript first and then moving to or learning other languages. MERRICK: [Laughter] JOE: That’s a pretty unique, sure path. MERRICK: Yeah, that’s true. I have always wanted to build things for the web. At first, it was flash because you used to couldn’t do the things you can do with JavaScript now that you could do with Flash. So, whatever building rich experiences on the web is, is what I’ve kind of been interested in. But lately, I’ve been, I guess, broadening my horizon into things that other people are leaving, like backend and compiled languages and things like that. JOE: Right. CHUCK: Yeah. And then Joe, you worked for Captain Picard and the Enterprise, right? You did [inaudible]. [Laughter] JOE: I did. [Laughter] That’s a funny way to put that. CHUCK: [Chuckles] JOE: Yeah, I worked for Bill Gates. CHUCK: Oh, yeah. MERRICK: [Chuckles] Captain Picard and the Enterprise. That’s amazing. JOE: Yeah. MERRICK: In layman’s terms, Joe came from .NET. CHUCK: Yeah. JOE: Yeah. I was one of the Bill Gates sheep, although I never really considered myself to be a sheep. I have said this before and I do think that there’s a problem that too many .NET developers don’t realize that you can do .NET but you don’t have to do 100% of what Microsoft shoves down your throat and still be a .NET developer. A while ago, there was this movement called ALT .NET and it really died. But I always kind of felt like that was really in line with how I felt. All of the things that Microsoft did well, I loved. But I was really open to the fact that they didn’t do everything well and not 100% of .NET developers are like that. I don’t know what the percentages are, but I know that there are developers out there that just accept what Microsoft says and that there are developers out there that realize that there are other alternatives for different pieces, other technologies that work great, that aren’t built by Microsoft but still work well with Microsoft. And Microsoft as a company, thankfully, is starting to admit that and really embrace. They’ve embraced Node really well. They’re embracing web technologies that they don’t really own. I think it’s nice to see Microsoft responding to that. CHUCK: Yeah, I’ve met some hardcore .NET developers that I swear, when they wake up, the boot song from Windows plays in their head or something. [Laughter] CHUCK: You try and talk to them about anything else and they always hark back to the custom controls that Microsoft gives you for web and other development and they have no idea that what it really boils down to so that it works on the browser is that it’s a control that’s built in JavaScript that has some hook to the backend. JOE: Yeah. I think in my career, I’ve seen that that’s a slight minority, that most people are more aware. But I think it’s helpful when people point out the fact and help others to know that you can blend in other stuff. There’s a lot of great Microsoft developers out there that understand how wide the world is. I think I was one of those guys. MERRICK: I love that any time somebody tells me they’re using Knockout, I can be like, “Oh, so you got a .NET backend?” And they’ll be like, “Absolutely.” [Laughter] CHUCK: Yup. JOE: Yeah. That’s awesome. CHUCK: Yeah. But my biggest issues with .NET really come down to the fact that you have to pay through the nose in order to get a Windows server and pay through the nose to get Visual Studio and stuff. Other than that, the tools are fine. The server is fine, the OS is fine. But I really have problems coughing up that kind of money. JOE: Those licensing fees never bothered me. CHUCK: Because somebody else paid them, right? JOE: Exactly. MERRICK: Plus, there are open alternatives, right? Isn’t there? JOE: Yeah. CHUCK: Yeah. MERRICK: What is it? The, I don’t know, there’s some C#. JOE: There’s Mono. MERRICK: Mono, that’s it. JOE: I’ve said this many times when people brought that up, to defend Microsoft because I do think that they do lots of good stuff. But by the time you get to any reasonably sized project, tiny ones, it’s different. But for any reasonably sized project, the licensing fees are such a small percentage. It’s kind of like buying a car because of the tires. Picture using a big car based on the brand of tires. “I’ve got to have Toyo tires so I’ve got to buy this particular brand of car.” MERRICK: My problem is that if I want to change my color scheme, I’m kind of stuck using Visual Studio. JOE: [Laughter] Hey, the new one I think comes with four color schemes. MERRICK: Four color schemes? JOE: Yeah. CHUCK: Woohoo! MERRICK: Touché. JOE: No, I think the new one is a bit better. I haven’t actually used 2012, but I think it’s a little bit better and they’ve responded to the fact that there are so many people out there that live and die by whether or not it’s cream or two shades lighter than cream. MERRICK: So Joe, what misconceptions need to be shattered to move from fulltime C# to JavaScript? JOE: That’s a big question. So, I made a pretty typical transition, right? I started doing fulltime C# and then we were doing web. We didn’t do any JavaScript and all the JavaScript we had was what Microsoft put down there. And then I slowly did more and more JavaScript to make my pages do more and more. Then one day I thought, “I just like doing web stuff and I might do full JavaScript.” So, the misconceptions that I had as I moved to JavaScript, one of them was that JavaScript was a garbage language. I think that was my first misconception, which is kind of an opinionated thing. Sometimes, even I’ll say that, being a fulltime JavaScript developer. We’ve said that before, the best thing about JavaScript is the fact that it’s so versatile you can plug the terrible holes in it. MERRICK: Yeah. JOE: But I think that was the first misconception, was that it was a pain in the butt to learn and that it was a garbage language and C# is so nice and neat and orderly and it fits into these little square boxes and JavaScript doesn’t. And so, I think that was my first misconception I had to get over, was just the language of JavaScript, that it was actually approachable. Once I just forced myself, I had this page that I just could not do with postbacks, which was the Microsoft way. And so, I had to do full JavaScript. I had to learn JavaScript for real. There was no more than 20 lines of JavaScript on the page. It was actually several hundred lines. Once I forced myself to do that, all of a sudden I realized, “Hey, this is a pretty approachable language and pretty easy to learn.” And I could really get some stuff done. MERRICK: Yeah. JOE: I know that you’ve seen this a lot. People come from another language and they don’t do idiomatic JavaScript, right? MERRICK: Yeah. Well, one thing that’s really frustrated… [Laughter] MERRICK: One thing that’s really frustrated me as someone who’s been in the JavaScript world for a long time, is seeing people act like JavaScript had nothing structured or orderly at all until Angular was invented. I’ve heard that so many times now. And I think in the long run, it’s going to be really good for JavaScript to get more developers into the scene. But I’ve seen so many people be like, “Oh yeah, I couldn’t test JavaScript until Angular came around.” JOE: Oh, wow! MERRICK: Or like, “JavaScript had no structure before Angular came around,” et cetera. And I’m glad that Angular made it more approachable for those people, but sometimes that can be super frustrating for me. CHUCK: Well, I heard people say the same thing about jQuery or about Prototype or pick your favorite poison. I’ve heard people say it about RequireJS, “I just couldn’t deal with it until I had modules.” MERRICK: Yeah, it’s true. It’s so interesting how just certain tools make things seem or make things more approachable. JOE: That’s a great misconception that can come to those who move to JavaScript, is that without some big huge tool in place, that JavaScript can have no structure, or can’t be X, can’t be tested, can’t be structured, can’t be ordered, whatever. Before we go too far, Chuck, I was hoping you would do the same thing that I did and kind of talk about your background and maybe name some misconceptions that you’ve seen as you’ve moved into the JavaScript world. CHUCK: Okay. Man, I got started programming in college. We did some Java, but I really didn’t do anything with web stuff until I was working at Mozy. I was working with them. I was running the Tech Support Department actually. We were building a tech support portal and that’s how I got into Ruby on Rails and web stuff. Interestingly enough, Rails, I don’t know if it still has it because I never use it because it was a pain, but they used to have this thing called r.js which was a Ruby-esque way of writing JavaScript. And it wasn’t JavaScript proper. It was actually more Ruby. And it also used to have a whole bunch of built-in stuff for actually doing all the AJAX calls for you. So, you would just tell it ‘remote=>true’ and it would handle it all for you. But I’ve moved away from that as well mainly because I like to have the control. And a lot of times I don’t just need it to post back to the backend. I actually need it to do something with the response, or things like that, which is where r.js was supposed to come in. But anyway, a lot of people for a long time spent a lot of time in Ruby and Rails trying to abstract away JavaScript. I think eventually, it just got to the point where people started using things like jQuery and realize that jQuery would let them do most of the common things that they wanted to do without too much trouble. That’s kind of how I moved into things. My first Rails contract, we were using PrototypeJS and script.aculo.us. And then, the next project, we were using jQuery. And from there, I just kind of picked things up and started writing my own JavaScript where I needed it. And for the most part, if you come from like a C programming background or anything like that, the syntax is pretty straightforward. And so, if most of what you’re writing is procedural, and that’s really what I was doing was writing procedural JavaScript, I wasn’t really taking advantage of eventing or anything like that, it was pretty simple. I didn’t really have a big problem with the language. But I’ve heard a lot of people talk about JavaScript and they’re just like, it’s kind of the unsavory portion of their application. And I kind of see it from the standpoint of about the tenth time you get dinged because you didn’t put a semicolon in or you forgot to add these curly braces, because Ruby doesn’t have them or doesn’t use them that way, you kind of get frustrated. But you get used to it. You get used to the evented model and you start to realize that there’s a lot of power on the frontend. And that’s kind of how I moved into it, was doing that. Then the other thing that really pushed me ahead was when I started attending the users’ group. So, the Utah JS Users Group that we all are a part of made a big difference because then I can go and talk to other people who are interested in JavaScript and learn some of the other idioms that surround it. But I’m still not fulltime JavaScript. I’ve only had one project that was 100% JavaScript. I’m looking forward to using more, actually. I’ve been playing with Node quite a bit lately. MERRICK: Here’s a question for you and this isn’t me trolling. It really isn’t. It seems like the Rails framework, since its conception all the way up to even today and going forward, do everything they can to avoid JavaScript. CHUCK: I think that’s partially true. I don’t think it’s completely true. But I think they try and provide alternatives. A lot of it is colored by David Heinemeier Hansson and his opinions of what should be done and how. But yeah, you have plug-ins that pull in the JavaScript libraries and put them in place for you so you don’t even have to do that part. MERRICK: Or like the way when you post, it’ll send back JavaScript to execute. So, you could potentially be downloading the same JavaScript over and over again. Well, I guess you cache it. Or like Turbolinks or how they make CoffeeScript the default. CHUCK: Yeah, all of those things, and yes. JOE: That’s very Microsoft-y. Microsoft is that way, to the nth degree. They send out all those JavaScripts and it was all these crazy quantities of JavaScript. They were trying as hard as possible to keep you from doing any JavaScript. Really, the meaning was having to do any JavaScript, but really what they were doing was insulating you from power that you could get. So, you do things in a dumb way, do these terrible horrible postbacks. MERRICK: It’s fine for the common case. But when you start to scale your app up, then it really starts to snowball into a really bad idea. JOE: I would say the simple case, not the common case. I think there are way too many [inaudible]. MERRICK: Yeah, it’s true, the simple case. JOE: A server developer with a good server technology like .NET, like Rails, will avoid doing something that should be done in JavaScript because they don’t have to. They can kind of avoid it and therefore, do something that’s far less effective for the users and for the application. MERRICK: It’s so funny because I fall into the trap on the opposite end of the spectrum. It could be done on the server but I’m like, “Oh, I’ll just do it on the client.” You know what I mean? JOE: Yeah. [Laughter] CHUCK: I do that sometimes. It really depends though, and I think it’s interesting what Joe said in the sense that what’s best or most powerful for the user. A lot of times, I’ll opt for the frontend or the backend based on how easy it is for me to build it there. JOE: Right. CHUCK: I have more control on the frontend. So, it’s much easier for me to build there, so I’ll do it. And other times, I have more control or I have more of what I need on the backend to just make it happen, and so, I’ll do it there. JOE: And sometimes, you’ve got to consider cost. I do believe that JavaScript development, in general, is a lot more expensive than server-side web development. MERRICK: It is. JOE: But I’m excited because I feel like the industry is steadily closing that gap. The more JavaScript frameworks move, the more we get new versions of JavaScript. MERRICK: The easier it becomes to test. JOE: Yeah. And I really feel like in the next five to six years, we’ll see that gap get so close that it just makes so much sense to do a lot more frontend development. CHUCK: Yes and no. And this is one of the fundamental issues with JavaScript in my opinion, is the fact that in general we have to maintain backward compatibility to these browsers that were written ten to 15 years ago. The language, yes, it can move forward and yes, it can give us powerful constructs for working around some of the issues that some of these browsers have. But it still has to give a way for the older browsers to do the thing. MERRICK: But here’s the thing. With ECMAScript 6 becoming something like a transpilation target, they want people to compile to ECMAScript 6. I think we, as developers, are going to write more to an abstraction of what the browsers run, rather than directly to the grain of the browsers. So, we might all be writing ES6 and that would transpile as much as possible to ECMAScript 5 or ECMAScript 3. You know what I’m saying? I think at some point, the tooling will catch up to a point where — for example, when you write Java, you are able to run on all sorts of platforms because you have this JVM. And I think we’re going to see something similar with JavaScript because you’re going to write the high-level language and you’ll have some sort of compilation target that’ll run on all these older browsers. CHUCK: Yeah. So, you’re talking about having some kind of library that fills the gaps and provides the APIs or are you talking about actually having it compile ES6 to ES3? MERRICK: I’m talking about actual compilation. CHUCK: That’d be interesting. I guess my question then becomes how do you manage that? Because then, the browser has to be aware to know which version of the library to pull, which is compatible with it? MERRICK: That’s true. That’s solvable, though. That’s easy. CHUCK: It is. But it’s still an extra step and that’s the thing. But at the same time, we’ve been writing to abstraction layers that take away all that pain for years with things like jQuery or Prototype or what have you because they know the quirks of the browsers. So, they just program around them. They do browser detection or whatever they have to do, find a common way to do it, and then they just take care of it. So, when I make an AJAX call or I manipulate something in the DOM or I do one of these other things that the library provides for, it knows if I’m running in IE6, then I need to work around it this way and if I’m running in Opera, then I need to do it this other way. JOE: Yeah. I’d like to generalize that and say I feel like smart people are going to solve a lot of problems and just make things a lot easier. The frontend of the web is the Wild West. There are so many unsolved problems to solve. As those problems get solved, it’s just going to make development on the frontend cheaper and cheaper. CHUCK: Yeah. But ultimately, if you’re writing at low-level JavaScript and you’re doing specific things that work differently in the browsers, or work certain ways in older browsers that don’t work the same way in newer browsers, we still have to maintain that backward compatibility unless we want to break the functionality for those older browsers. JOE: Right. MERRICK: Right. I do think though that you could transpile a lot. There are some features that you can’t, like you just can’t get tail-call optimization. Well, you may be able to do it through a series of complex for-loops, but there are some features in the language you just are going to have a real hard time, let alone impossible time transpiling. JOE: But let’s be honest. All we’re talking about here is IE. That’s really what we’re talking about here. MERRICK: No, there are bugs in Firefox. CHUCK: No, not entirely. JOE: Yeah, there are bugs, but it’s been evergreen for a while. MERRICK: Chrome, all these things. JOE: And they’re getting more and more evergreen. The number of people running a non-evergreen version of Chrome is tiny. MERRICK: IE is a big culprit, but the truth is the ubiquity of the web creates fragmentation in the platform. JOE: Right. MERRICK: And that’s a good thing. JOE: Yes. MERRICK: Because you get the ubiquity. But consequently, you’re writing in multiple platforms. So, I think this is a JavaScript problem. I don’t think this is an IE problem. I think IE’s the biggest culprit of it because they fragment further than anyone else. But I don’t think it’s fair to… JOE: That’s true. But my point was, IE’s our biggest culprit and as time goes by, they’re getting better. And I hope someday, they’re going to figure out and make a decision that they’re going to make versions of IE that aren’t dependent on the OS. They say that IE is evergreen. Well, it’s only evergreen so long as you stay on the latest OS. Once you stop and you’re an old OS, your version at some point is going to be capped. That’s what they’re doing right now and I think they’re going to figure that. They’re going to change that. I hope they change that policy at some point. We’ll have a truly evergreen IE. MERRICK: Yeah. CHUCK: Yeah. The other thing is that with most of these browsers, you get kind of the incremental update. So, I’ve got Firefox on here and I use it just often enough so that every time I fire it up, it says there’s a new version which is every month or so. Chrome just updates itself. I don’t even pay any attention because it just does it automatically and I don’t even see it. In a lot of these cases, since it just handles that, you don’t have to worry about it. That’s the other issue that I really have with Internet Explorer, is this like you get IE10 or whatever and you get these minor patches to it but you’re stuck on the main engine for it until they come out with a new super major update. MERRICK: Isn’t that because it’s integrated into the OS? CHUCK: Kind of. It’s kind of integrated into the OS. I’m not sure how deep it goes, but it seems like some things it does are things that — it works like an independent application. And some things it does, it seems like it ties back into a lot of other things. So, I don’t know. MERRICK: Yeah. All I’m saying is we could be asking a lot of Microsoft. [Chuckles] JOE: Yeah. MERRICK: You know their other codebase, right? JOE: Right. And I’d like to switch and move back to the whole migrating to JavaScript, since we’ve definitely segued here into browsers and the problems. But move back into as you’re moving to JavaScript, what are great ways to move to JavaScript? What are misconceptions? MERRICK: I think misconceptions are that JavaScript is unbearable without certain libraries or tools. JOE: Yeah, that’s definitely a big misconception. MERRICK: Because I totally agree that abstracting away the platform is nice, with things like jQuery. But I think people really cripple themselves by not actually trying to understand the language itself. JOE: Right. MERRICK: And reading that book, or listening to the episode with Dave Herman, Effective JS, I think gives a wonderful point of view with like some of the interesting things you can do with JavaScript as a language. JOE: Right. MERRICK: I believe even if you’re just writing to jQuery all the time, it’ll make your jQuery life better. JOE: Yeah. CHUCK: Yeah, and I highly recommend to people to go read it. And then when you’re done reading it, go read it. MERRICK: Yeah. [Laughter] MERRICK: It was an excellent book. It really was. JOE: So, I feel like my migration to JavaScript, if I could do it over again to make it more effective, the things that I would have done is spend more time right at first learning how to structure my JavaScript code because the misconception that JavaScript can’t be structured is definitely wrong. But it is true that if you don’t spend time structuring your JavaScript code, then you end up with crappy code. And that’s easier to do in JavaScript than a lot of languages because it is harder to structure code. They don’t give you very good structures, even building a class up. MERRICK: The language itself doesn’t have any code sharing mechanisms yet. JOE: Right. Yeah. CHUCK: Yeah. I was going to say that in languages like Ruby or Objective C or some of these others that I’ve been playing with, they give you very strong idioms. MERRICK: Structures. CHUCK: Structures, yes. In the language that really give you a way to put your code together. And if you do it the other way, you can. But once you move into classes or once you move into some of these other structures, you really figure out fast that this is a much easier way to do this and it’s much easier to reason about. And yeah, JavaScript just doesn’t have those strong, I don’t know if I want to call them opinions, with the structures that it gives you. But the structures are so flexible that it doesn’t necessarily always say, “Do it this way.” MERRICK: Yeah. You could write a fully object-oriented system with JavaScript with ease. Well, you’ve got to be good at it or you have to understand the language or prototypes, at least. CHUCK: Yeah. MERRICK: But you’re right. It’s less obvious to people. CHUCK: Well, and I have to say that things like Backbone, I haven’t really had a chance to play with Angular — sorry, Joe. But they were a big win. I mean, JQuery itself was a big win in the sense that it kind of gave me some ways of structuring, because they have some patterns that they show you when you start using it. And then, Backbone really gave me a good way of handling that. And again, it’s because they provided the structures that I needed to organize my logic. MERRICK: Yeah. JavaScript is trying to mitigate that problem. They’re actually going to add class semantics. It’s still prototype, prototypal inheritance, but they’re adding a class keyword to ECMAScript 6 to try and make that more obvious to people coming from other languages. JOE: Yeah. So, that’ll be a big help for sure. CHUCK: One other thing that I’ve seen a lot of people moving to with Node.js, is that they found that certain areas of their application like chat rooms or workflow management or things like that, they work really, really well with an evented system like Node. And so, what I’ve seen is that people have written JSON APIs into Node or into a Node application and they pass it stuff and then it does its work in an evented fashion. And when it’s done it spits it back out. I’ve seen some stuff go on like that where they kind of take a hybrid approach. And so, part of their application’s in Rails or Sinatra and part of their application’s in Node.js. JOE: Right. MERRICK: Interesting. CHUCK: So, that’s another transition point on the backend that they add some payoffs. JOE: Yeah, very interesting. Very interesting. What about you, Chuck? As you’ve looked over your move to JavaScript, how would you do it differently if you could do it over again? CHUCK: For the most part, I think what I would do is just find a way to really learn the core concepts behind JavaScript. I kind of got into it from a, “I need to solve this little problem on my webpage.” And so, I’d go look up some code and copy it over, go look something up on jQuery.org and copy it over. I really wish that I had understood deep down what was going on because I think I could really have more powerfully used the features around the language itself. JOE: So, I agree with that. But I do think that often times when you tell people that, and this is true even after having been in JavaScript for a long time, JavaScript is a deep language with a lot of deep holes to go down and learn. So, I would say that’s true. But I would say that there are a handful of things that you should definitely learn and learn those and then worry about learning the other things later, right? CHUCK: Yes. JOE: And so, I think that if it was me and I was making that list, I would say that understanding closures, understanding hoisting, and context are probably the three big things that you should learn. I don’t even think that… MERRICK: I’d take hoisting out. JOE: Really? MERRICK: Oh, yeah. Closures, scoping. JOE: Scoping. Maybe scoping’s better than hoisting because hoisting and scoping are — when I say hoisting, what I really mean is scoping and understanding where variables start and end. CHUCK: Yeah. JOE: Closures, scoping, and context. I don’t even think that understanding the prototype’s inheritance system is that important when you’re first getting into JavaScript. That becomes important as a second level, for me. CHUCK: Interesting. MERRICK: I think if I could do it all over again, I would definitely learn about testing sooner and test driving code. That was something… JOE: Awesome. I can’t believe you said that before me. CHUCK: [Laughter] MERRICK: Yeah, that’s a byproduct of working with Joe. But test driving code make a huge difference in terms of just the type of JS I write. CHUCK: So Joe, when are you going to have him brainwashed into paying us? [Laughter] MERRICK: True that. JOE: That’s another great one, is not being afraid of testing JavaScript. That’s another either misconception or thing that should be learned because it’s code. You should be testing it. In fact, I think it’s more important to test JavaScript than it is to test your server-side code because it’s so much easier to go wrong in JavaScript. It’s a fast, free, loose language. And there’s a lot that goes on under the hood. It’s hard to understand especially when you’re first getting into it. It’s so much more important to test your JavaScript. CHUCK: Yeah. One other thing that I wish I had time to learn a little bit more about is to go and learn some of these other languages that transpile into JavaScript. So, I’ve done quite a bit with CoffeeScript, no surprise there. But go and learn TypeScript and Dart and some of these other languages and not just learn them for the sake of understanding the languages, but understand what they’re really trying to solve in JavaScript. So, what the problems that they see in JavaScript are and why they’re giving you this other alternative to do that, to write in those languages and then transpile it down to JavaScript and then just understand why those are weaknesses or not of JavaScript itself. MERRICK: Sure. JOE: Interesting. Yeah. What are the common mistakes might people make as they move to JavaScript? Not testing being a big one. CHUCK: I think a lot of times, people are afraid to just deviate off of the common path. They use the common functions out of jQuery or they use the common functions out of whatever MVC framework they’re using. But they’re kind of afraid to do more than just that and some basic procedural stuff instead of really looking at, “Okay, what does it mean to put an event on this and why would it help me?” JOE: Right. I’d say that was my number one most common mistake I would list, is just doing jQuery and then thinking that jQuery is JavaScript and only thinking in JavaScript in terms of jQuery, learning JavaScript through jQuery. If that’s how you learned JavaScript, you definitely need to take a step back and learn the language a little bit bigger and make jQuery just a piece of your JavaScript. Structure your JavaScript code and then have your jQuery just be one little piece of that and not have jQuery be your JavaScript. I’ve mentioned before, I worked at a company and this worked fairly well for them. But everything that they did in JavaScript was actually a jQuery plug-in, everything that they did. And it worked out. It worked out just fine for them. But I think they could have actually got a lot more advantages if they had come up with a structure that was JavaScript and jQuery was just mixed into that. MERRICK: True. JOE: So, that would be one of my biggest mistakes, is thinking that jQuery and how jQuery does things is really how JavaScript does it. Another potential mistake is, and I’m actually on the fence about this one, but idiomatic JavaScript in lots of anonymous inline functions, lots of closures. I had a conversation with somebody about, is a closure a code smell? I had recently learned that C# supports closures. I had known it supports basically this feature of lambdas for a long time, but you never closed over variables in C#. I never had and none of the code that I’d ever looked at had ever closed over a variable. So, when I found out that in C#, you can actually close over a variable identically to the way you do it in JavaScript, I was like astounded at the fact that you could do that. But nobody does it in C# and I think the big reason is because in C#, your context is fixed for functions where in JavaScript it’s not, so people close over variables and have access to them. MERRICK: Because in JavaScript, that’s all you have to scope things. JOE: Yeah. MERRICK: Everything’s a global or you… JOE: Yeah. That’s the only way to get it in there, is close it over. But is a closure a code smell? Because if you close over a variable, you’re coupling your function implementation to that variable and there’s no clear declaration of that. You’d have to actually look inside the body of the function to see, “Hey, I’m referencing this variable that’s declared outside of it.” So, is that a code smell? So, that’s kind of idiomatic JavaScript to close over things all the time, when there are ways to get around that. You can bind a function invocation to the value of the variable and then invoke the function that way. So, there are ways to get around it. I’m on the fence about certain pieces of idiomatic JavaScript. But I definitely think that if you’re coming from a server-side language trying to write JavaScript like whatever server-side language you’re familiar with is a mistake. You should learn to write JavaScript as JavaScript. CHUCK: Yeah, I think it’s interesting you brought that up. Ruby also has closures and blocks, procs and lambdas. They’re all closures. JOE: Oh, really? CHUCK: Yup. JOE: And you can close over variables and it’ll hold the value within the invocation of the function? CHUCK: Yup, unless you override it as a local variable or a parameter. JOE: Right. Okay. I didn’t know that you could do that in C# until I actually tried it, just because it’s just not done. Nobody does it in C#. CHUCK: Yup. Alright. Well, I think we’re running out of time. Are there any other things that you want to bring up to kind of mention on the show before we end it? MERRICK: Nope. JOE: I just want to say the word testing one more time. [Laughter] CHUCK: Now, I’m going to go crawl in a hole with my guilty conscience. You guys can do picks. I don’t test my JavaScript as often as I ought to. [Chuckles] CHUCK: Alright. Well, let’s do the picks. Merrick, what are your picks? MERRICK: I have a pick that is probably going to be an unpopular one because everyone loves to make fun of this. But I want to pick Dart, the language, and the tools and libraries that they’re creating. I think if you looked at Dart at first and you’re like, “Oh man, this thing sucks,” you’ve got to give it a second look. They’re adding some really interesting things like bindings directly into the language. Well, using libraries, but bindings with observables like you find in Angular or Ember. MDV, the Model-Driven Views, the shadow DOM, they have an import structure. So, you can import code like a module system. It’s pretty cool. They’re doing some interesting things and that’s DartLang.org. Then the other thing that I wanted to pick is the ECMAScript 6 Wiki. It’s awesome. There are just all sorts of great information about the upcoming set of JavaScript. And I think the best entry point for that is this ES6 Plans. So, if you found it impenetrable, I think that’s the best page to start with. So, those are my picks. CHUCK: Awesome. Joe, what are your picks? JOE: My first pick is going to be the TV show Defiance. Actually, I’ve been DVR-ing it up, but I think the season’s over. I have no idea if it’s being cancelled or not and I hope it’s not. But I actually just watched the first two episodes of it and really, really liked it. So, it was a cool show. It’s no Firefly, but I really enjoyed it. It’s a cool show, cool sci-fi show. Speaking of which, Under the Dome just started. I’m interested to watch that one. I’m also going to pick America’s Got Talent. We watch that as a family every week. And it’s just so cool seeing these crazy things that happen. Somebody steps on stage dressed like a homeless bum and sings better than Pavarotti or can juggle better than the best jugglers in the world. It’s just so cool to see these crazy things happen. And you just sit there and go, “Holy crap! I can’t believe that happened.” This last episode we just watched, there’s a woman on a six-foot unicycle and she was riding the unicycle with one leg, and with the other leg she was kicking bowls onto another bowl that was on top of her head, like salad bowls. CHUCK: [Chuckles] Oh, jeez! JOE: Just kicking them. She had three of them stacked up on her leg and she kicked all three and all of them fell altogether onto this bowl on her head. It was unbelievable. How could a human do that? And what would ever make you think you’d want to learn that? CHUCK: [Laughter] I was going to say, “How do you figure out you’ve got that talent?” JOE: Yeah. It was unbelievable. And then, my last pick is going to be eSports, specifically StarCraft II eSports. I love watching StarCraft II tournaments. I feel like it’s just like every other sport. You don’t have to actually play to enjoy the sport. I think understanding it is definitely important, but you can understand it by watching. But it is an absolutely amazing sport to watch. I love watching the StarCraft II tournaments and watching the best players in the world compete and play, learning new underdogs and then the dominant forces. You want to see the underdog beat this guy who’s been winning every tournament. MERRICK: All the go-to Koreans. JOE: Yeah, the Koreans that dominate the world. I love watching StarCraft II eSports. So, that’s going to be my third pick and final pick. CHUCK: Awesome. Well, as far as TV shows go, I’ve actually been watching Continuum, which is on the Syfy channel with Defiance. I keep seeing commercials for Defiance, so I’m assuming it’s still running. So yeah, I really like that. I’ve also been watching Fringe with my wife. We just finished Season 4, so I’m now looking at ways to get Season 5. Another pick that I have is CleanMyMac, which is an application for the Mac. Basically, the reason that I have it is I bought, I think it’s a 256GB solid state drive that I run my OS off of. Makes it boot a little bit faster and things. But I tend to fill it up. So, CleanMyMac will go and identify large files that you ought to look at cleaning up off of your Mac. It actually cleans up some of the caches that build up on your machine and deletes old versions of applications and things like that. It’s really, really good. I usually wind up cleaning up somewhere between 10Gig and 15Gig off of my hard drive every time I run it. And it’s stuff that I’m not using. So, those are my picks. It was a good discussion, guys. JOE: Cool. CHUCK: So, thanks for coming. We’ll catch you all next week. MERRICK: Thanks. JOE: Yeah, thanks.

x