JOE: Let’s roll.
[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $1,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you’ll get a $2,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/JavaScriptJabber.]
[Let’s face it. Bookkeeping is hard and it’s not really what you’re good at anyway. Bench.co is the online bookkeeping service that pairs you with a team of dedicated bookkeepers who use simple, elegant software to do your bookkeeping for you. Check it out and get your free trial today at Bench.co/JavaScriptJabber for 20% off today. They focus on what matters most and that’s why they’re there. Once again that’s Bench.co/JavaScriptJabber.]
[This episode is sponsored by Rangle.io. Rangle’s been working with Angular 2 for a long time and they are now putting together an eight-hour, 2-day course designed to help Angular developers learn how to write apps in Angular 2. If you’re looking to level up your JavaScript and Angular 2 skills then go to Rangle.io/training and click on the link for Angular 2 training. If you’re looking for other training in React or JavaScript, they also have that available at Rangle.io/training.]
JOE: Hello everybody, and welcome to episode 220 of the JavaScript Jabber Podcast. Today on our panel we have Aimee Knight.
AIMEE: Hello.
JOE: And Jamison Dance.
JAMISON: Hello, friends.
JOE: And I’m your host, Joe Eames. And we have a special guest, Kyle Simpson.
KYLE: Hello everyone.
JOE: Kyle, we always like to start off with a little bit of an introduction to our guests, so could you take a minute and introduce who you are and what you do and why we would care?
KYLE: Well, most people are going to know me as getify online, on GitHub and Twitter and all those other places that matter. So, if you are looking for me, that’s how to find me. I have been on a journey with JavaScript for about 18 years. And that journey first had me as a developer. And about four years ago I transitioned that journey to teaching JavaScript. I’d been searching for a long time in terms of how I’d be able to give back to the community. And I realized that I could take the experiences and the perspective that I have which frankly a lot of people that follow me know is kind of a little off the beaten path. But I could take that and give back by teaching, so that’s what I do. I teach JavaScript.
JAMISON: Where does the name getify come from?
KYLE: [Chuckles] Yeah, I get asked that frequently. I wish it was a more interesting answer. But back in 2006, late 2006 or early 2007 the Ask.com search engine, I don’t even know if anybody remembers that, but Ask.com…
JAMISON: Oh, yeah.
KYLE: [Chuckles] They for whatever crazy reason decided to do a series of TV commercials. And the theme of that TV commercial was the word ‘getifaction’, like getting things and being satisfied with them. And the very first time I saw that I was immediately inspired with the verb form of that word, getify. And I started thinking about how that can kind of describe what I see myself doing which is going out and getting information, bringing it back, and making it useful and acceptable and accessible to people. So, getify became my company name and when you’re just a one person company, the company name becomes your personal brand, too. So, that’s where getify comes from.
JAMISON: Sweet.
JOE: Very interesting.
JAMISON: Well, it worked out really well for Ask.com. So…
JOE: [Laughs]
JAMISON:
[Chuckles]
KYLE: It’s worked out alright for me, too. [Chuckles]
JAMISON: Glad to hear it.
JOE: Yeah. Jamison, you still use Ask.com, right?
JAMISON: Yeah, yeah. A couple of times…
JOE: Big fan. [Chuckles]
JAMISON: A couple of times a day. Yeah.
So, I’m interested in what made you… I guess you touched on it a little bit but were you kind of getting bored of development or were you just excited about the idea of teaching? What made you decide to make that change?
JOE: And as a ride-along to Jamison’s question I’m not sure if you specifically said this but do you teach full-time now? What do you do active development wise?
KYLE: Yeah, good questions. So, let me answer the second one first since it’s the easier answer. I full-time devote my attention to multiple channels of teaching. So, some people probably know me from a series of books that I wrote on JavaScript. I’ve got quite a few online training videos that are availability through Frontend Masters and other platforms. They’re syndicated on Pluralsight and some others. And I also do as my main work that pays the bills teaching corporate workshops. So, companies all over the world hire me to come in and teach three, five days, maybe two weeks at a time to do a workshop on the core mechanics or JavaScript or on applying it to specific language-oriented tasks. And so, I come in and teach those workshops. And that’s how I spend most of my time that is getting money or getting paid, is based on the corporate trainings.
So, how did I get into teaching? Well, I had actually been a developer for quite a long time as I said. And I noticed that I was not a very good employee to be honest. I had a bunch of different jobs that I switched, I kept moving from job to job to job and I wasn’t happy at them. And I don’t think they were as happy with me as I would have liked, which just meant I wasn’t a really good fit. And I kept thinking, “Well, it’s their fault.” They interview me, they say this is great. And then six months in I’m not a good fit and I leave. And I kept trying to blame that on the employer but after the 20th or so job jumping around it started to occur to me that maybe there were some things that I was missing. It should have occurred to me a lot earlier, probably. But it occurred to me that when I look back there were several things that I was trying to do with where I was working. I had a strong desire to give back to those companies and to try to push them forward with different ways of thinking about things.
And because I was very strong with JavaScript it was attractive to a company to hire somebody as a JavaScript expert to come in and really lead the effort on revolutionizing the way they approached things. So, that was mutually attractive. I said, “Great. I’ll go in and do that.” And then when it got in there, we realized, “Well, there’s a lot of politics involved. And oh, well we said we wanted to change it but really, we don’t.” And so, I got frustrated. But after reflecting back over all of those jobs I realized that what I was trying to do was teach. But I didn’t have a packaging for that at the time. So, I was… that wasn’t the job title. That wasn’t the job description. And that’s why it wasn’t being received well.
So, I was actually an independent consultant and out of the blue, this guy named Mark contacted me. He had started a company called Frontend Masters. And he said, “I’ve seen you do some conference talking. And you’re pretty good at that. Would you ever consider teaching? I actually had some experience, quite a bit of experience teaching but entirely in a different realm of my life, not in the tech industry. And so I said, “Well, I’ve never really thought about it or given it much serious thought. I don’t know if I’d have enough to teach an entire day. But maybe.” And he said, “Well, I want you to come up and teach a one-day workshop because I think you can do it. So, I flew up to Minnesota and the night before I was terrified that I wasn’t going to have enough slides. I was very paranoid about running out material after only a couple of hours. And I stayed up really late and worked on everything.
And then the next day as I was presenting, sometime around the middle of the day I looked out while the students were working on one of the exercises. And I took stock of where the slides were and where we were in terms of progress. And we were right on track. We were exactly where we needed to be. And I knew at that point that we were going to table or continue and finish out the whole day. I saw the students working on the stuff that I was presenting and I saw those light bulb moments happening with the questions that they would ask. And I realized, this is what I’ve been looking for, is that opportunity to give back in a way that would be well-received. And that’s what clicked. And I said, “I want to do that from here on.” So, I’ve been teaching ever since.
JAMISON: What did you teach before?
KYLE: Ah. I actually was a volunteer youth pastor in my church for a number of years. So, I taught junior high students. And I think if you can talk to junior high students and keep their attention for 15 minutes and them not try to shave your head then you can probably talk to just about anybody in the world.
AIMEE: You are really talented at teaching. I think there’s, you could say you are a teacher and you’re just sharing knowledge. But I feel like from reading your material, you’re not just sharing knowledge. You have figured out ways to break down complicated topics in a way where they’re very easy to understand. So, I don’t know. I just thank you for that. And [laughs] I don’t really have a question there. Just like, a statement for people who haven’t looked at your material yet. I frequently get questions from junior developers about what they should learn and what are some good resources. And every single time I point them to your stuff, because I feel like there are a million different blog posts about closure and things like that and reading your stuff, hoisting, reading all of your material makes it crystal clear. [Chuckles]
KYLE: That’s very kind of you to say. I appreciate that. I would expound on that a little bit just to give a little bit of background here. I was growing up, my dad, he still does this, he’s a financial planner, investment sort of person. So, he works with people’s taxes and businesses and stuff. So, I grew up around that. My sister went into that same line of work. So, I grew up around people talking about money my entire life. And money is one of those areas that my dad always used to say people don’t know enough about how to manage their money. And they don’t just want to walk into an office and give a bunch of their money to somebody and not know what’s happening. They don’t understand it but they can’t go to school to become an accountant or something. They need somebody to break it down for them.
So, he had that heart of a teacher and that was his way of treating his clients with respect was to say, “I believe that you deserve to understand how we’re going to manage your money and how we’re going to it well.” So, he always taught me that the best way to share with someone, the best way to be useful to that person is to teach them, not to condescend them, or not to believe they can’t possibly get it so just skip by it like, “Okay, I’m the money guy. You let me do it and don’t ask questions.” He did the exact opposite. So, from a very young, early age I felt like teaching other people was part of an ethic that was built into me, to give back, to share what I know.
And then when I got into college I further learned the value of teaching. And I enrolled in a class, an engineering physics 3 class in my freshman year which was a really dumb idea because I wasn’t ready for it. But the AP test said that I was ready so I took it. And the professor walked in the first day and he was like, “I’ve been asked by the CS department to weed out 80% of you and I intend to do my job.” He sort of set the expectation…
AIMEE: [Chuckles]
KYLE: That this was going to be a really difficult class, and it was. He was being honest. And most of us in the class were probably destined to get really bad grades or not pass at all. But I saw that as an opportunity, as a challenge. And so, I went and hired one of his former teaching assistants to be my tutor. And every week on Tuesday I’d get together with that tutor for an hour and a half and that tutor would sit there and show me how to solve problems from that professor’s previous tests. He would explain the principle and how to think about the problem and how to solve the problem. So, that tutor would teach me for an hour and a half. And then every Wednesday night at 8:30 we got together for two hours and I ran a study group of other students in my physics class. And I shared with them the same thing that the tutor had taught me just the day before.
So, what that taught me was that I was really learning it not because of what the tutor was doing but because of my experience teaching other people. That’s how I really learned it. And it turns out that it was pretty successful. I didn’t know what I was doing really at the time. But it was successful because I ended up being the only student to get an A in that class. But that is not because I knew this stuff ahead of time or I was somehow innately a genius or anything like that. It’s just because I decided to make sure I really learned it. And one of the most effective tools for that was teaching other people. So, when people say that old adage like you don’t really know something until you can explain it to somebody else, I deeply believe that. I really, really deeply believe that that’s the most effective way to learn. And if you can’t do that, then you should be looking for opportunities.
So, even though someone like me might have the job title of teacher and it may seem easy for me to teach, I actually maintain that everybody can teach as a matter of practice of the way that you conduct yourself. Whether that is the code that you’re putting out on GitHub, whether it’s at your job running a brown bag lunch because you spent some time learning or reading a blog and then you want to teach other of your coworkers, whether it’s using code review in the culture of your company as a way to teach and help everybody learn and all boats rise with the tide sort of thing, and half a dozen other ways. There are all different kinds of ways for us to go outside of ourselves and to explain to others the journey that we’re on.
So, when I stand up in front of a class and I talk about JavaScript I think it’s really important to know that I believe that I have not achieved some sort of JavaScript mastery because I don’t think you actually do. I don’t think there’s ever a moment where you get the certification in the mail and now you say, “Okay, I’m an expert.” That isn’t how it works. I describe knowledge kind of like the mathematical concept of an asymptote where you never achieve it but you get closer and closer. So, I’m on this curve of knowledge and I’ve dedicated myself to trying to understand it better, more deeply. And the way I’ve done that is to teach other people and bring them along. So, rather than saying I’m an expert on JavaScript, what I do is open up. When I stand in front of the class I’m opening up and saying, “This is the journey that I’m on with JavaScript and I’d like you to come along with me.” And that really is the mindset that I take.
AIMEE: That’s awesome. You’re making a difference in my journey as a developer. And I know first-hand some of my friends as well. So, that brings me to another question I have. I think the very first time that you really came up on my radar was actually a friend of mine, Sarah [inaudible] who lives in New York. And her and I were doing some stuff together on Saturday morning. And she said, “Oh, you need to check out these books by Kyle Simpson.” And at that point I had already, I felt like I had really understood the prototype chain from the process of going through a million blog posts and finally finding one that clicked. But as I was reading through your material on it I was like, “Oh my gosh. If I had read this the first time around instead of the trillion other things that I had read beforehand, I would have saved myself six months, something like that.
So, I was wondering if you could talk about how you go about explaining the difference between inheritance and delegation and why you think that delegation is a better way to explain how the prototype chain works in JavaScript. Because I feel like that’s how I understood it and then reading your material on it solidified, “Wow, somebody else. Actually, this is how they’re explaining it, too.” So, it’s really beneficial for people to hear.
KYLE: Yeah. I’d be happy to dive into that. So, we can get into more of the nitty-gritty about JavaScript. For those that are interested in reading more about what this is, one of the books in my book series does cover this in detail. But I’ll be happy to kind of give some meat here for people to chew on.
So, there are lots of developers that have spent many, many years, sometimes even decades not really questioning how the mechanisms in the language work. Just simply using the mechanisms, the way that everybody that they’ve seen has used them. So, if the majority of blog posts and books on the topic of JavaScript all reinforce a certain pattern, a certain idiom, a certain way of thinking about something, most people are just going to accept that as face value and say, “Okay, that’s obviously what it is. That’s what it ought to be called. That’s how we ought to describe it.”
And what’s different about me, whether this is a good thing or a bad thing is debatable, what’s different about me is that those things don’t really fit with me. I don’t just read something and say, “Oh, well that automatically fits with the way I think.” I have to digest that, break that apart into a whole bunch of pieces, reassemble those pieces, those basic principle and concepts and I have to reconstruct it. And many times when I reconstruct it, it’s going to end up looking quite a bit different than just the way that it’s always presented to everyone.
So, that’s what I did in my trying to understand the prototype system. I was awful at it and I asked questions of other people that knew how it worked better. And I felt looking back on it I felt so embarrassed because there were so many silly questions that I just, I would ask dumb questions over and over. And I couldn’t, I kept banging my head against this thing. And I think one of the reasons why it was so difficult for me was because just like most other people they had that particular feature of the language had been presented in a very specific perspective. And that perspective is: use this system to emulate the mechanisms, the pattern of class orientation. So, I kept trying to emulate classes and I kept trying to fit that with what I already knew about classes because I happen to have some to JavaScript through some experience with other languages. I had experience in C++, in Java.
And so, I kind of knew what classes meant. I also had a CS background so I had some formalized academia and some pedagogy around the notion of classes. And so, I kept wondering why my understanding was dissonant with what I was seeing from the behavior of JavaScript. And I kept breaking it down further and further and further. And when I built it back up there was a whole bunch of extraneous crap that I didn’t put back into the picture, if you will. And what I built back up in my mind was I realized fundamentally that what we were looking at was a mechanism that allowed one object to connect to another object. And it’s that connect to relationship that everything is wrapped up in. What does that connect to relationship actually mean?
When you think about what actually happens in JavaScript, when I have object B that is connected to object A, the way they’re connected is called the prototype chain. So prototypically, B is prototypically derived from or inherited from, those are all the terms people use but I want to say B prototypically delegates to A. And what that means is when you ask for a property or a method, if you use one of those property or method accesses on object B and it doesn’t exist on object B, by default what JavaScript does is walk the prototype chain one link up to the next connected object, in this case object A, and it asks the same question again. It says, “Is that property or method on this object?” And if it is, it uses it and if not it keeps going on the prototype chain. So, that is a description of how it works.
And then I started researching, “Does this have a name? Have other people talked about this?” And it turns out there is a name for it and that name is delegation. There’s a Wikipedia page for it. I read some old computer science text that kind of mentioned this topic. And I realized, “Hey, what JavaScript has and what this thing over here that people are describing in academic text, those are one and the same.” So, why not call JavaScript what it actually is? It’s a delegation system.
Now to take a step back for a moment, the reason why many people make the claim that this mechanism is the same thing as classes in JavaScript is because if you look only at object B and you don’t pay any attention at all to the fact that there’s a live link happening and that it’s walking up the chain every time a call is made, if you ignore all of the actual implementation details it looks like object B is a composition of all of the behaviors that both B and A have. So, it looks like B has “inherited” from A, because you have access to it on B. So, this is a classic case, to use a pun here, this is a classic case of if you just simply use something without understanding it then you reinforce that same pattern that everybody else has talked about. It looks like B inherited from A. But really, the word inheritance has a lot of meaning, a lot of baggage that comes with it, from other languages.
And so, in my teaching and in the books and in the writings that I’ve done, I try to draw these distinctions and say, “These are not two sides of the same coin. They’re entirely different coins.” One is the normal classical inheritance pattern. In languages like Java and C++ it means that we take the stuff in A and we copy it down into B. And then that’s the way Java and C++ work. But in JavaScript we don’t copy those things down. Instead we leave them separate. We connect the two together. They are connected through the prototype chain and there is a live delegation that happens.
So, then we fast-forward to what’s happening with ES6. Because you can model something similar to classes on that delegation system and just hold your nose or squint at it when there’s weirdness or behaviors that don’t make a lot of sense. But then you start laying other syntax on top of it because you want to get rid of all those syntactic weirdnesses. So, now we have the class keyword being added as of ES6. And I see that as a doubling down on the misrepresentation that this mechanism is a class. And my evidence for that is that there’s, if you actually dig in, if you don’t just take classes at face value but if you dig into them, there’s a whole bunch of weird corner cases that are totally inexplicable unless you understand the fact that we’re really just trying to put some nice pretty makeup on top of something that’s just fundamentally not a class system. They really are opposite.
JOE: Are any of those corner cases things you could talk about now?
KYLE: Sure, yeah. Absolutely.
JOE: It sounds super interesting.
KYLE: Yeah, so again this is getting really nerdy. But in classical inheritance one of the most important principles of classical inheritance, the way we design software, is to do what’s called polymorphism which is to take a method and define it in A and then in B define a method of the same name and override that behavior in B and perhaps even access the behavior in A. And the way we access relatively up the class chain is to use the super keyword. That’s how we make what’s called a relative polymorphic reference. We take whatever level of the class inheritance chain [inaudible] and we just simply go up one level and ask for the version of that behavior, that method, at that level. So, you’ve certainly seen, if you know class [inaudible] code, you’ve certainly seen the use of the word super either in the constructor or in one of the class methods to refer to the parent version of that constructor method.
Well, JavaScript adds the class keyword and of course they probably want to add the super keyword. Because if you’re going to try to design software with the class design thinking, you’re going to want to do the same things in JavaScript or very similar things in JavaScript that you do in C++ and Java. It’s a very natural extension. So, they add the super keyword which is supposed to represent the object that B will immediately delegate to. So, if we’re going back to the way JavaScript concretely works, B connected to A through the prototype chain, if we’re talking about a method that exists on B and they say super in it, then super has to reference A.
Well, that’s all well and good except for the fact that the performance of creating a relative polymorphic reference called super is really terrible. And the JavaScript engine developers on TC39 said, “We’re not going to implement super if it has to be dynamically calculated. It’s got to be statically calculated because the performance is going to be really bad otherwise.” So, they said, “Well, okay. Here’s what we’ll do. We will say that the super keyword gets determined or calculated at the time that the object is declared,” in other words when I declare class A and then I say B extends from A, that’s when we’ll determine what the super keyword points to. And we will statically fix it and you will not be able to change it. That will make the JavaScript engine developers happy because they know that they can statically calculate it once instead of dynamically recalculating it.
Okay, great. Except for the fact that a whole bunch of people [in] JavaScript for 21 years now have been used to being able to take objects and dynamically rebind the this context and use methods in other object contexts. That is, there’s a lot if rich history in JavaScript of doing that. And that’s actually something I’m very much a fan of, is being able to take a method and borrow it for other object contexts. The this keyword is dynamically calculated. So, if you have a method on A and you try to use it against C for example it will dynamically switch to the C context. That’s great. Except the super keyword is not dynamically calculated. So now, if you have a method that uses both the this keyword and the super keyword, you will be surprised when you find out that the this keyword nicely switched its dynamic context while the super keyword stayed statically fixed to the time that it was calculated at declaration time.
Now, those are the kinds of nuances that you only really get into when you start trying to push the language in the direction of utilizing all of its capabilities. So, where we come down to is if you use JavaScript classes, the ES6 class keyword, only as prescribed and you don’t really care to think too much about how it’s working or pushing on any of the corner cases or anything, you’re probably going to be okay. But that is antithetical to the way that I approach understanding JavaScript and of course then approach teaching others. I want you to understand how it works. And as soon as I start explaining stuff like what I just explained, people’s heads start to explode. And they’re like, “Wait a minute.”
JOE: [Laughs]
KYLE:
“I don’t understand this.” And then what we realize is that the class system, this is my own personal opinion, but the class system is so fraught with these corner cases and exceptions, the duct tape to try to keep pretending that it’s a class system when it isn’t, that it becomes unmanageably unteachable. So, you can use classes but you can’t teach them. At least you can’t teach them in the way that I like to teach which is deeper understanding. So, that’s my beef with it, is [chuckles] we’re really painting ourselves into this very difficult corner where JavaScript the language can be used but not understood. And I don’t think that’s a healthy direction to go.
JAMISON: Yeah, I have so many questions off of that. One is that almost seems like the natural evolution of long-living technologies. C++ is kind of incomprehensible, right? Like if you just wanted to sit down and learn C++ today it would be a difficult task because of so many things that have been added. And do you see a way around that? How do you evolve a language and add new things and grow what it can do without just running into these weird edge cases or just the additional complexity?
KYLE: Yeah, so I run the risk of sounding like a crotchety old man that doesn’t want progress. Just give me the old JavaScript that we had in 2000. That was good enough. That’s not at all the message that I want to portray. In fact, I’ve had the opposite message. There have been many people that have said, “You should only learn a tiny part of JavaScript,” and that was famously called “The Good Parts.” And everybody knows that reference. We all know what we’re talking about here. And the premise of that entire book and that whole way of thinking is JavaScript as a whole is fundamentally flawed in its design but there is this golden path, this smaller subset that you can learn. And if you stick to the smaller subset everything works great. But if you venture out into the badlands, good luck to you. So, when I came up…
JAMISON: I also like how it’s like, “And by the way the part of JavaScript that I like, that’s the good part.”
KYLE: Yeah, exactly.
JAMISON: It’s kind of a book that…
KYLE: It is very biased, right?
JAMISON: A little bit of judgment there. [Chuckles]
KYLE: Yeah. Right. So, the problem, that was the problem that existed in the JavaScript community. And when I decided to write a series of books about JavaScript basically my attempt was to be the anti-‘The Good Parts’. And that doesn’t mean that I’m writing a book series about the bad parts. It means I’m writing a book series about all the parts. I want you to understand all of JavaScript. And I think at this point JavaScript is still a tractably learnable language. It takes effort. It takes a lot of investment of time. But I think you can learn it. And furthermore, if for whatever crazy reason you choose to make JavaScript your career, I think you ought to. Because developers in other languages even though what you said may be true that it’s harder and harder to know C++ for example, I think developers in those languages take that a lot more seriously than we do. Most JavaScript developers that I encounter, well-meaning and good at their jobs but they really just stopped as soon as they knew just enough to get their job done. They didn’t have that drive and that curiosity to understand it more fully.
So, other developers outside of JavaScript do seem to value more deep understanding of these things. And I think that’s a good thing. I think that’s something that we could learn in the JavaScript community from. So, I wrote that ‘You Don’t Know JS’ book series to challenge people to learn all of JavaScript. I want you to understand all of it. And I want you to see that every single feature has a way that can be used that is useful and profitable and will make your code more readable, more understandable, more explainable. But there’s also ways to use these features in crazy ways or in ways that are very overly clever but make it very hard to understand.
So, if we’re coming back to feature evolution of the language, the question before I get too far afield, there’s a whole bunch of stuff that was added to ES6 that I’m a huge fan of. And I’m out teaching it and promoting it and talking about it. For example destructuring. That’s a complex feature. It takes a lot of time to learn. But the payoff is huge. Because we move many of the more noisy and confusing parts of our code into a much more declarative form. It makes code easier to understand. So, I’m a huge fan of things like destructuring and other declarative mechanisms. I’m a big fan of some of the capabilities that were added, like for example generators and things like that, to give us declarative state machines instead of the imperative form. So, there’s a whole bunch of stuff that was added.
And I would love to be coming on this podcast and saying the class keyword fixed all of our problems and now we can understand it. But what class did as I said just a moment ago is it doubled down on a set of misconceptions. And it essentially comes with the premise, you ought to just use this thing and not really try to understand it because all the things that you need to make it work, we’re going to do a bunch of ugly plumbing underneath the covers. But don’t worry about any of that stuff. Just use it at face value. So, there are a lot of people that that works perfectly fine for.
But for people like me that are curious, that want to understand and want to be able to explain it to others, I can’t break down something like that and then represent it in a way that makes sense. So, I have to essentially come in the teachings and in my books to the conclusion that the prototype system is very useful, very powerful. There is a way to use it. I call that OLOO, objects linked to other objects. And if you embrace that core of JavaScript with that part of the feature, I think you get a lot of benefit. If you go down the other road and you try to use class-oriented design, I think you’re asking for either more abstraction or more confusion. But there’s no way to address both of them.
So, I don’t think that the language has to stagnate. But I think we should be bringing to the discussion table, and this isn’t meant as a criticism of TC39 at all because I know many people on there. I’m a big fan of many people. I don’t want their job. I wouldn’t want it at all because it’s very hard. But I do sometimes feel like the teachability and learnability aspect of the language is the last thing that gets considered in the design of the language. And that bothers me. I wish that were more front and center. If I had my way, that would be the most important design feature.
JAMISON: That makes sense.
JOE: Yeah, what an interesting perspective though. I’m sure you’re right. Who when you’re designing a language really considers, “How teachable is this?”
KYLE: Yeah. Again, I’m not meaning at all to cast aspersions on the people that are on TC39 and that are running the design of the language. I see some things that they come out with and I’m like, ‘That’s brilliant. That’s awesome. That’s going to be much more helpful. There’ll be ways to teach that.” And I see other stuff that comes out and I’m like, “That’s just, that’s more like confusion. That’s more duct-taping over the problems instead of fixing them.” And those are the things that kind of keep me up at night, if you will.
JOE: Right.
AIMEE: So, another topic that I think that you do a really good job talking about that a lot of people shy away from is, if I can even say it correctly, coercion. Am I saying it correctly?
KYLE: Coercion, yeah. That’s [inaudible]
AIMEE: Coercion. Thank you. Okay. [Laughs] Embarrassing. Anyway, I am curious if you’d be willing to talk about that a little bit. Because I feel like for the longest time until I started digging into your material, I just thought, “Don’t use this part of the language. Always use triple equals, no questions asked.” But you kind of advocate for knowing the power of it and actually using it as a feature of the language.
KYLE: Yeah, absolutely. This is, like we’re talking about, this is one of those declared bad parts because some guy said, “This is a bad part of the language,” and everybody else said, “Yeah, you know I find that thing confusing too. So, let’s just all collectively agree we’re going to completely avoid it. And then we’re going to go on writing blog posts and books and go on podcasts and we’re going to make fun of JavaScript for having this really terribly designed feature.” And the feature of course that we’re talking about is coercion.
So, I might be like the only one. But when I started trying to break down the type system in JavaScript and understand how it works, I actually found a lot of really cool stuff. And I, just like with the prototype system, when I reassembled those pieces I started recognizing several different ways that I could improve the understandability, the readability of my code. And so, I started advocating that people ought to learn the coercion system. That hasn’t changed anything because the vast majority, 99% of developers still say, “No, no, no. Coercion is bad.” But…
JAMISON: Snark always sells.
KYLE: [Chuckles] Yeah. So, I’m in the position of supporting a feature of the language. Many times I’ll criticize a feature like I was just doing before. But here I’m supporting a feature of the language that many people don’t think ought to exist. They think it ought to have never been put in and they ought to somehow remove it from the language. Now I want to say off the bat that coercion is not perfect. There are definitely some parts of this that I hate and there are mistakes and they are the kinds of things that give me gray hairs. But on the whole I actually think that coercion’s a very powerful mechanism. And if JavaScript didn’t have it, I wouldn’t be writing JavaScript. It’s that important.
So, let me fill in the blanks a little bit to help listeners understand what I’m talking about. What does coercion mean? Coercion is the, for the class of languages that are what we call dynamically typed, so it’s important to understand dynamic typing. There’s actually a difference between weak typing and dynamic typing so you might want to do a little bit of Wikipedia page reading if you’re interested. But just briefly there’s this notion of weakly typed which is that a value can be changed into another, same representation of that value in a different type, that that can happen implicitly. That’s what weak typing means. So for example, if we have the number 42 and it was used in the context where we needed a string like if we were printing it out to the console, that it can be automatically converted to its string representation. That’s called weak typing. And in a weakly-typed language, the way that type conversions happen, that is given the label coercion.
Now, coercion actually comes in two forms. There’s the explicit kind and the implicit kind. Most people when they talk bad about coercion, what they mean in the back of their heads is they don’t like implicit coercion. They tend to prefer things that are more explicit. To give you an example, if you were to make the case that there should be no coercion at all which I’ve heard people say, it’s kind of nonsensical. If I hear somebody say that, I really just think to myself that person hasn’t thought critically about the problem. Because to remove all coercion would be to see there is no type conversion at all. And you cannot make a program without type conversion, period. You have to have a number that you can print out to the screen. A conversion has to occur from number to string. You have a string input on a web page and then you need to do some math with it. You’re going to have to convert from the string form to the number form. There are other, boolean is another example.
So, you’re going to always have to do some sort of type conversion if you want to have any kind of non-trivial JavaScript program. So, we need a conversion mechanism. And that’s why I divide that line. Then I say, “Well, what about explicit versus implicit?” Those that come from statically typed or strictly typed languages, they know about type conversion where nothing happens implicitly. You have to be explicit about it. You have to say string of 42 to get the conversion to happen. So, I get the impression that JavaScript developers would prefer to have everything be explicit and have there be no implicit or in some cases accidental type conversions occurring.
Now that would be great except for the fact that the most vocal of those proponents, for example the Doug Crockfords of the world, they will say until they’re blue in the face, “Don’t use coercion,” meaning don’t use implicit type coercions. But then if you open up Doug Crockford’s code, guess what you find? You find examples of them using implicit type coercions. Because the fact of the matter is, that’s a powerful mechanism that used in the right way actually makes code easier to write, easier to understand. If you have to go always through the explicit path and never through the implicit path, you can make it work. But the code is harder to understand. So, there’s not such a clear dividing line between explicit and implicit. And I think that people should think critically about it instead of having a linter that simply tells you always use triple equals and never thinking about it. I think you ought to think about the cases where coercion can be helpful and places where it might get you into trouble.
So, let me just briefly give an example of a place where coercion would be useful. If you have a piece of your code that you need to decide whether or not somebody shows option three for whatever that means. There are three options available and you need to do something if somebody chose option three. There’s potentially two possible ways that they chose option three. One would be that they picked a drop-down or they typed three into a text box or something. And so, you have option three represented as the string representation of the value three. So, you have literally “3” in some variable. Another possibility is that that was from some saved preference in a JSON object that came from the backend database. And now it’s represented as the number 3.
So, we have the question of, I’m asking is it, option three is what I’m asking when I’m thinking as a developer. To actually code that in JavaScript the linters of the world would tell me that I should write a statement that says something like ‘if option ===
3 or option ===
“3”’. So, what I would say is happening there in our goal or our task of trying to be explicit, not allowing any type conversion or coercion to occur, what we’ve done is we’ve actually cluttered that piece of code with an implementation detail that’s actually irrelevant to the program. Because the programmer at that moment does not actually care whether it’s represented as a string or a number. All they care about, the logic that’s trying to be self-evident in the code is whether option three was picked.
So, what we ought to have is a mechanism where we could just simply say, ”Is option three picked?” and abstract away the implementation detail of whether or not it’s a number or a string. One way you could do that is to write yourself a function called ‘is option three’ and you could pass that value in. And inside of that function you could do that double checking thing, that ‘option ===
3’ thing. And then your if statement now says ‘if is option three’ and they pass in the value then I do this logic. That’s one way of abstracting away the unnecessary implementation detail. What I simply argue is the double equals operator does this for us. It’s built into the language, the ability to abstract that type difference. The double equals operator will allow us to compare the string 3 and the number 3 to be coercively equal to each other. So, I can simply say ‘if option double equal to the number three’ and either the number three will match it or the string three will match it. But null is not going to match it and an array is not going to match it and nothing else is going to match it. But the number three and the string three are coercively equal to each other.
So, what I’ve done is I’ve used my knowledge of the language and one of its features which I argue is powerful in a way that actually makes my code simpler to read by hiding unnecessary implementation details. In this case, hiding them inside of the JavaScript engine because the feature is already built in. now, there’s lots more nuance here. There are lots of places, there are lots of corner cases where you can get off track. And so, I’m not saying use double equals everywhere unconditionally. There’s more to it than that and I’ve written a lot about it. But that gives you an example of the thinking that I bring to this question. I believe we ought to trust developers to be smart enough to make those kinds of critical decisions.
And furthermore, you’ve heard me say this a bunch of times now, I think we ought to have as one of our most important design decisions about the way we write our code, we ought to embrace the idea that code is communication. Code is how we communicate with humans. It’s not about instructing the computer nearly as much as it is about communicating effectively with other humans. So, we should be looking for every opportunity that we can to make the code make more sense, have it be more understandable and more readable.
And in the case of saying ‘if option triple equal three or option triple equal string three’ what we’ve done is clutter up that where anybody that reads that in the future has to then think about all those cases. Like “Hmm, I wonder where it could come as a string. I wonder how could it ever be a number?” And then they’re completely distracted from the whole point of that code. I don’t want us to write code that is overly verbose and then distracting. I want us to write code that is as clear in its communication as possible. And this is an example of using a built-in mechanism of the language to hide implementation details so that the code speaks for itself.
JAMISON: That whole philosophy kind of reminds me of one of my favorite presentations ever called ‘The Politics of JavaScript’. It’s by Angus Croll and it’s about that same idea that there’s a lot of rhetoric about what you should and shouldn’t do and carving off and making chunks of the language illegal. As part of that, I think he talks about with and how at one point Firebug was heavily making use of with to do some of the debugging stuff it was doing. But yet, that was a taboo thing that no one could use.
KYLE: Yeah, absolutely. So, I’m actually a huge fan of Angus. He’s kind of my spirit animal. And I’ve never gotten to meet him in person. I’ve tried a number of times and it just didn’t work to meet him in person. But he’s a great guy. A lot of the similar perspectives we bring to things. So, if you’re looking for more of that, I totally recommend reading all the stuff that he’s written. He’s written probably one of my favorite most entertaining books about technology ever which is ‘If Hemingway Wrote JavaScript’. On that particular topic, just since you brought it up, he’s right that there’s a lot of politics involved in why people tell you not to use the with keyword.
Here’s an example where I’m going to agree but for a different reason with those that say the with keyword is bad. So, this is kind of like in math class. Whenever you had a test and you answered the test but you didn’t show your work and then you got it back and the teacher marked off points. You got the right answer but you got points marked off still because you didn’t show the correct work. And you’re like, “Why does it matter what work I show?” It matters how we get to the conclusion. It doesn’t just matter that we get to the same conclusion. So, I agree with an awful lot of the JavaScript community when they say that the with keyword is a bad idea. You shouldn’t use it. But there’s an entirely different reason. It’s got nothing to do with politics. It’s got nothing to do with whether or not it was a mistake in the design of the language or any of that stuff.
There’s a very specific set of things that the with keyword does to our program that we should not be doing. I talk about this in my ‘Scope and Closures’ book. But the with keyword creates a lexical scope at runtime. And the JavaScript engine, that’s a tremendously expensive operation to perform to create a lexical scope. And also, that operation implies that a lot of the optimizations the JavaScript engine would normally do with your code that is caching all of the lexical scope lookups, it can’t do those because it can’t necessarily assume the same things anymore when you’re going to start creating dynamic scopes all over the place. So, what the JavaScript engine literally does, and I’m not making this up, it literally does a quick scan to see whether or not the eval keyword or the with keyword show up in your code. And if they do, regardless of how you use them, they just simply don’t do those optimizations.
So, what that means is your code is going to run necessarily a little bit slower just simply as a result of having that presence in your program. I don’t think that’s a good idea to opt into mechanisms that are going to make your code run slower. So, the negative of that far outweighs any possible potential benefit. There’s a bunch of other problems with the with keyword but that one I think is kind of an incontrovertible argument. It’s going to slow things down because the engine is going to skip over some optimizations that it would otherwise have available.
JOE: Huh. Crazy. I had no idea it did that.
JAMISON: So, I want to channel my inner Angus and push back on that a little bit. If it runs slower and now instead of doing 2 billion operations a second you can do 200 million operations a second, there are plenty of cases where that does not matter. And yeah, you get this abstract feeling like, “Oh no, my code is slower.” But it’s not a user-facing thing. And there are things that you can do with with and eval that are difficult to do other ways. So, yes it has tradeoffs but isn’t that part of the point? That you should be aware of those tradeoffs so that you can decide when it’s worth it to make them.
KYLE: So, a couple of things. Yes, absolutely. I am encouraging people to think critically about these things, not to just simply take some quote that they hear from me on a podcast and say, “Okay, that’s the new rule.” I’m encouraging people to understand these same things for themselves which is why I teach them over and over in classes. It’s why I write them down in books. It’s why I talk about them in conferences. It’s why I come on and explain them on podcasts, because I want you to know it and I want you to make the decisions for yourself instead of just simply quoting something that I said and not thinking, taking that without critical thinking. I don’t think that’s healthy for any JavaScript developer.
On the other hand, let’s dig in specifically to the question of the with keyword since that’s what at odds here. The with keyword does not just simply pollute its own usage. It pollutes the entire file because of the way the implementation works. So, it is the entirety of your program that is going to run slower as a result of simply using the with keyword once somewhere within that file. So, if you have a file that has 10,000 lines in it and only one line has the with keyword, it has virally polluted the optimization benefits that would be available to all the rest of that code. That’s one observation to make. If it were only that the with keyword itself were slow and it had no effect on anything else, you wouldn’t hear me making that case as strongly. But it’s because it affects everything else that I’m making that case in that way.
But even if we take performance entirely out of it for just a moment, the with keyword has a behavior to it which is one of the worst evils in all of programming design and all of language design which is that it is impossible to predict its behavior until the runtime occurs. You cannot statically analyze and predict its behavior ahead of time. And you have to run it. And what I mean by that is this. You use the with keyword to say with obj, with object, and then inside of it you say something like ‘a equals two’. Well, you would like to believe that what that is doing is setting the a property on the obj object to that value two. Unfortunately you cannot predict or know whether that is going to happen unless you know what the shape of obj is. Because if obj already has an a property then it will indeed set it to the value two. But if obj does not have that property yet, the with keyword will not add it to that object. Instead the with keyword will treat that as a failed lexical scope lookup for a variable named a and it will then walk up the scope and look for a variable called a in the outer scope, in the outer scope.
And then because you’re using the with keyword you’re going to be in non-strict mode. And so, when you get to the global scope you’re going to end up creating an accidental global variable called a. That behavior of not being able to predict or validate how something is going to behave, not even being able to look at the code as a human and understand what it’s going to do because you don’t know the shape of obj, that’s a terrible design. And it creates much, much harder to understand code. So no matter what kind of benefits you might be able to cite about not having to say ‘obj dot’ over and over and over again for example, they’re not going to end up in my mind countering that argument which is it’s creating these effects at a distance because you can’t predict its behavior.
JAMISON: That makes sense. I have kind of a more general question to get back to the education stuff we were talking about at the beginning of the podcast. It seems like there has been a huge rise in the amount of resources and institutions devoted to education in programming. And especially the bootcamp movement where there are just places all over the place springing up to teach people how to code. And some of them seem to put a little less emphasis on teaching skill I guess than others. Some of them will really emphasize “Our instructors are successful industry engineers who worked at this famous company or this famous company,” and not as much focus on, “They learned how to teach here.” And do you see that as a problem I guess that there are so many more people teaching but that we don’t as an industry talk that much about the skill of teaching? It just seems like it’s kind of assumed. If you know how to do a thing, then clearly you can teach it. Like you built some system, you can teach other people how to program.
KYLE: Yeah, that’s a great question and a tricky one to navigate well. So first off, disclosure. Most people probably know that I’ve spent quite a bit of time working with the curriculum with MakerSquare. So, I actually have first-hand experience at a developer school. And so…
JAMISON: And lots of them are fantastic, too. I don’t mean to say that… like, none of them…
KYLE: Yeah.
JAMISON: But there’s definitely a mixed bag.
KYLE: I would actually re-frame this debate a little bit. So, I think it’s definitely true, the observation that you’re making that not all coding schools are the same. And not all teachers are the same. There are teachers that believe deeply in the process of education and pedagogy and knowing what you’re talking about and being accurate and making sure that everybody gets what they need. And there are teachers that just sort of gloss over, reinforcing the same stuff that you’ve heard everywhere else. And they are very effective in that manner. So, not all teachers are the same and not all schools of course are going to be the same. You do need to pay very close attention to that.
But I’d also, to push the debate even further I’d like to re-frame it slightly and say that I think part of the problem that exists right now with developer schools and really developer education as a whole is that the industry has forced these coding schools to do things that otherwise they wouldn’t really naturally want to do. Because the developer industry, the business industry that hires these developers has said, “I just need you to make sure that they can invert a binary tree on a whiteboard,” well necessarily then because that’s the way most interviews happen, guess what the developer schools do? They optimize for making sure that the developer can pass those interviews. [Inaudible] they spend at least some of the time instead of teaching them how to really understand the code, they spend some of the time just teaching them how to pass that interview. Why? Because they paid $20,000 as a transaction and one of the promises is that they would get a job. That they would get interviews and they’d get a job.
So, part of the reason why we have really terrible tech school grads or if there are grads that are coming out and they don’t know stuff, part of that blame is on the school but part of that blame is on the industry that’s being hired into by wanting the wrong things. Optimizing for the wrong things, incentivizing entirely the wrong things. If we could change what we look for in the interview, if we could say that we value looking for people that are critical thinkers, that are really deeply problem solvers and not just people that are good at coding on whiteboards then I think you would see a new revolution of these developer education programs producing developers that are more optimized for that. Because those developer schools, right or wrong, exist for the purpose of getting somebody into our industry. And they are looking specifically to the companies that will hire their graduates to set the pace and to set the lead.
I ran up against this a whole bunch so far in my time at MakerSquare. We’ve run up against this, banged my head against it because there’s a tension there. I come to this notion of building curriculum from we ought to teach them how it really works. But I also know that if I spend all my time teaching how it actually works and I don’t spend any time teaching you how to answer the interview question in the way that that person is likely to want to hear it, you’re not going to get a job. So, we need to fix those problems. And I think that will then trickle down to allowing the people that care the most about teaching in developer education space to do it. We also need radically different models for teaching than what we… and I don’t mean that the developer schools need to go away but we need lots of other approaches to teaching. So, that’s a lot of the things that I spend my time thinking about, banging my head against these days, is how do we improve that. And I think one of the things we have to do is advocate for employers to start hiring for the right things.
JOE: Well said. Well said. I wish we could spend a whole episode just talking about that.
AIMEE: [Inaudible]
KYLE: Well, I can certainly come back at some time and we can talk about that. You can probably tell I have lots of thoughts on it.
JOE: Right.
AIMEE: You can do your part, too.
JOE: Yeah. Okay, well we should definitely wrap up here. We’ve hit our hour mark. You got places to go and people to see. So, I’m sure everybody’s excited to get to the picks portion of the show. Let’s start with Aimee. How about you?
AIMEE: I have one pick this week and it is a book. So full disclosure, I have not read the book yet. But I did watch the TED talk and the book is called ‘Your Code as a Crime Scene’. But there’s also a TED talk that goes along with it so I’ll put both links in the show notes. But even the TED talk was really, really good. So, the guy has a background in forensic psychology. And he uses that to analyze where bugs show up in your program. He uses the principles that he learned studying forensic psychology and applies that to tech debt. So, I just really, really thought this TED talk was super interesting. And I’m sure the book is probably amazing. It’s on my list of things to read. So, that’s it for me this week.
JOE: Awesome. Jamison, how about you?
JAMISON: I have, let’s call them four picks today. The first one is an episode of an NPR podcast. And it’s on the history of the Open Office. The Open Office is a pet peeve of mine. I really dislike them. [Chuckles] And it was interesting to me to hear about where it came from. It was basically just this architect working at a fancy advertising company that was like, “I don’t know. I’m going
