SPECIAL ANNOUNCEMENT at the end of this episode. Don't miss it. Kyle Simpson, author of the You Don't Know JS Yet series joins the JavaScript Jabber panel to discuss the origins and approach to his book series. The discussion varies to the basic parts of JavaScript, the parts you should know, and how to learn them.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Kyle Simpson.

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

DAN_SHAPPIR: Hey, hey from Tel Aviv. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: I'm Charles Max Wood from devchat.tv. And this week we have a special guest and that's Kyle Simpson. 

KYLE_SIMPSON: Hey, I'm in Austin. 

DAN_SHAPPIR: Woo, Kyle Simpson. Yeah. 

AIMEE_KNIGHT: So excited.

CHARLES MAX_WOOD: I know it's always fun to talk to Kyle. Do you want to just remind people who you are? 

KYLE_SIMPSON: Oh geez. How long do we have for that? 

CHARLES MAX_WOOD: About an hour. Oh, just for that. 

KYLE_SIMPSON: Most people know me as Getify. I've been around the speaking and open-source circuit for quite a while. So in the, if you've been around JavaScript a long time, you may have known me from earlier projects like LabJS I was pretty well known for, but I think most people listening in will have at least heard of the You Don't Know JS books. So that's me. I'm the You Don't Know JS guy. 

CHARLES MAX_WOOD: Nice. And we're going to talk about the books. But I just want to let people know that we have an announcement we're going to make at the end of the episode. So hang in there. 

 

If you're a front end developer looking for remote work, then I recommend G2i, a React and React Native focused hiring platform that will connect you directly with their clients that need your skill set. What makes G2i a unique hiring experience is that they spend the time marketing you to their clients of your choice. G2I is a team of engineers that technically vets you upfront. If you pass their vetting, their clients have agreed to skip their initial interview process, saving you time and energy getting your next gig. They take care of all the hard work for you so you can get focused on development. To join G2I, go to g2i.co and apply. 

 

AIMEE_KNIGHT: At my last job where I was coaching a lot of the newer devs, we did a retreat. And I used your front-end masters courses as the worktop for the retreat. Can't say enough good things. People who have been listening to this long enough know that, but I give you my full endorsement. 

DAN_SHAPPIR: Yeah, and I would also- 

KYLE_SIMPSON: Thank you, I appreciate all of those shout outs. 

DAN_SHAPPIR: And I would also like to add that you have some amazing videos on YouTube from various conferences that you spoke at or keynoted or whatever, and I highly recommend those as well. 

CHARLES MAX_WOOD: Yeah, so go Kyle Simpson out, folks. 

DAN_SHAPPIR: Yeah, we're all fanboys here. Or-

KYLE_SIMPSON: We should do this more often where people get around and talk about the stuff they like from you. 

CHARLES MAX_WOOD: Yeah, well, it's funny because every so often someone will be like, we should get Kyle Simpson on and then everybody else goes, yeah, yeah, yeah. And then we get you on the calendar and then eventually someone will see it and they'll be like, yeah! I get this email and it's just like, oh good, oh good, oh good. So anyway, I'm kind of curious. I think we've talked a little bit about some of the ideas around, you don't know JS, but I'd love to get like kind of the origin story there, right? Where, where did this come from? 

KYLE_SIMPSON: So there, um, there's a lot of different parts to the origin story. And as with all good origin stories, some parts of them are better myths than others. Um, but I'll, I'll, I'll give you the truth behind it. So I was South by Southwest in 2011 and I met a book editor at O'Reilly named Simon St. Lauret and I was working with one of his authors to help write the HTML5 cookbook, which we ended up publishing at the end of 2011. So this was at the beginning of 2011. We worked on it that year, but I met him. He was our editor and I was brought on to that project to help write the JavaScript parts of what you were going to talk about with all the new cool HTML5 stuff. So I helped with that project and kind of enjoyed the process of writing, getting my ideas out. And then at South by Southwest 2012, a full year later, Simon and I, and since South by is here in Austin, it was convenient that he would come and visit me here, but he, uh, he and I were out having some drinks and he said, Hey, listen, I would love to have somebody write a short little book on the topic of closure, maybe like 30 to 50 pages. Would you be up for that? And I said, I actually have been thinking about writing not one, but a couple of books on very specific topics like that. And I said, I have two or three maybe that I would like to write that would be like 30 or 50 pages long. And so I counterpitched him on, I would do the one on closure. If you let me do one on a couple of other topics too. And he thought that sounded great. So we started chatting with O'Reilly about a series of three short books. I told O'Reilly at the time, I don't want to do the traditional route where you give me some thousands of dollars advance and we have no idea if these are going to sell and then maybe I never even see any royalties as a result. That sounds like a bad plan. So here's what I want to do. I want to do a Kickstarter campaign to judge whether or not people are actually going to be interested in very specific and in-depth books. Cause a lot of JavaScript books are either the David Flanagan, like 2000 page, you know, deep dive, or they're just very surface top level of the books and I was kind of trying to go somewhere in between. And I said, well, let's just judge if people will do that. So they agreed, um, to put up a kick, to let me put up a Kickstarter. And I did, and that was fairly successful. And it definitely convinced me that there was a good audience out there that would be interested. So I began planning out those books and very quickly it grew from three to four and then four to five and eventually from five to six over the course of that next year, this was early 2014 by the time we were actually doing this. And by the end of, by mid 2015, all six books were out and it ended up being a total of about 1100 pages. So it was a whole lot more to say about JavaScript than I thought I had to say. But we kind of went through every topic that I think makes up the core of the language. And I chose not to touch on the very adjacent topics that a lot of books cover, like how it works in the browser or even Node.js or whatever, just wanted to focus on the core language. Now, as part of the origin story, everybody asks, what does the title mean and where does the title come from? So the original, the first edition series, You Don't Know JS, where does that come from? Well, I was searching for a catchy name to use in a Kickstarter campaign. And I had always been a fan of the, you don't know, Jack, uh, trivia games from back in the nineties, which predates a few of our listeners, I'm sure. But that was a thing back in the day. And I liked the, you don't know, Jack and the joke of, you don't know, Jack, you know, I thought that was a funny little joke. And so I put up a doctored image from the, you don't know, Jack, the bald-headed back, the back of the bald-headed guy, I put up a joke image of that for you don't know JS up on the Kickstarter campaign and it would, it got a lot of attention and that's part of what helped the campaign go. It also got the attention of the lawyers at the company that owns you don't know Jack and they contacted me with a cease and desist saying that I couldn't do that and I told them I'm going to do it anyway, but we, we basically went back and forth and they agreed that they don't actually. They tried to pretend that they owned the, you don't know whatever. And I was like, no, you don't, you don't own that. So I'm going to keep doing it, but I will at least not use the back of the bald-headed guy, cause that's obviously their branding. So I needed to come up with, um, a logo. And so I threw something very quick together and put it up on the Kickstarter campaign and a year later, the artists at O'Reilly were like, we can't come up with any, any better logos who are just going to use it. So a thing that I threw together to make the lawyers happy turned out to be the sort of iconic logo for the first edition. But the name itself, the meaning and where it came from, it has several layers of meaning. So there's obviously the joke about you don't really know what you think you know. But the actual honest truth is that where that phrase got embedded in my mind was a couple of years before that when I was interviewing at Twitter and I had gone through a day long interview exercise and you several people on the team and we thought everything was great but they ended up deciding not to hire me and when I pressed them for the reasons why I just wanted to know You know, how did I not match up to what you were looking for? one of the interview people sent back a piece of feedback to the Recruiter that said we just didn't think you knew much about JavaScript and of all the various feedback that I could have gotten as an international speaker and author on the topic of JavaScript, I thought that was rather ironic. And so that's actually a big part of where that was born was the idea in the back of my head was, oh, I'm going to write this book series and I'm really going to like show it to them. I'm going to like send them a copy. 

AIMEE_KNIGHT: I love this story. 

KYLE_SIMPSON: Yeah. I never did actually send them a copy. 

DAN_SHAPPIR: I wonder which part of JavaScript that interviewer got wrong that caused him to say, you don't know JavaScript. I know that soon. 

CHARLES MAX_WOOD: Well, and back to the idea of you don't know Jack. It's, it's ironic that it came out of Twitter, right? Cause you don't know. 

KYLE_SIMPSON: That's a good point. I hadn't thought of that layer layer of meaning too. While we're on the topic of the meaning of it though, I want to set the record straight a little bit because it did create some waves and I did it a little bit on purpose, I wanted to kind of catch attention and not just be like, you know, the guidebook to JavaScript or whatever boring phrase that anybody typically uses. So I did that on purpose, but it offended some people. And even to this day, there's still Reddit threads about people that talk about how they are offended by the title because the reaction that people, some, some people get is, well, who are you to tell me that? I don't know. You don't know whether I know JavaScript. I know everything I need to know about the language. So there were people that were, that were a little offended by it. And the second edition that came out, I added the, the word yet onto the end. So the second edition is you don't know JS yet. That was, that's intentional to suggest that my, my point all along was not, you don't know something, but rather do you actually know it, maybe you should re-examine this and maybe fully knowing JavaScript isn't the thing that anybody ever gets to, maybe Brendan doesn't fully know it, I certainly don't fully know it. And maybe none of us do but maybe there's still something to go and relearn. So that's the intent. It's not more like an insult. It's a little bit more like a nudging to get you to think about it and to look into it deeper. 

DAN_SHAPPIR: I totally agree with everything you said. I mean, I've been using JavaScript on and off seriously since around 98, which makes me definitely a JavaScript old-timer. Again, probably before some of our listeners were born. And I recently, I have this kind of thread on Twitter where occasionally I post JavaScript riddles and I recently posted one that I actually called out to Kyle because I posted the riddle because I knew what the answer was. I just wasn't sure why that was the answer that I was getting. So even after all these years, JavaScript can definitely surprise me. Let's put it this way. 

KYLE_SIMPSON: Yeah. Yeah, that's definitely true. And...True to my form, what did I do, Dan? I sent you a link to the section in one of my books where I covered that particular ridiculousness. 

DAN_SHAPPIR: Yeah, and I read it. So thanks for that. Yeah, I'm still not 100% sure that I fully understand what's going on there. Maybe I'll post a link to that riddle in the picks and see what our listeners think of that riddle. Anyway, it was interesting. 

CHARLES MAX_WOOD: So I'm curious because I look at the books and for me it's a compilation of stuff that I should understand about JavaScript and how it works. But what was your source? Because my source is you. So where did you go to compile all this information? And it also seems like there are different implementations of JavaScript and some of them are slightly different. So how did you deal with that? 

DAN_SHAPPIR: I'm guessing he ran the V8 source code in his head and that's how he knew all the answers. 

KYLE_SIMPSON: Simple, right? It's simple. Okay, so let me answer Charles. Let me answer those questions in reverse. Let me start with there are different implementations because this is a very common, but I would, I would characterize this as a misconception. If you went back to 2002, the reality is that there were actually different implementations of JavaScript and that JavaScript might actually legitimately run differently, a program written in one might not run in another. That is no longer the case and really hasn't been true since say 2009, maybe 2010, when the last of the IE browsers that were running the J script, which was Microsoft's version, their forked version of JavaScript that went away. We really have not since that time had different implementations and by different, I mean diverging implementations and ES5 actually technically 5.1 that was voted in in 2009 and then officially canonized in 2011. ES 5.1 brought forth what TC39, the committee that runs the language, they call the 1JS principle, which is that they agreed that from that point forward, all different major JavaScript engines being the browsers or anybody else that's like a player in the space of JavaScript engines that they would all have a seat at the table of TC39 and that nothing would make it into the specification unless all of them gave consent to the idea that they agreed to faithfully implement it according to the spec. So if any one of those players vetoed it and said, we were, we are unwilling to implement that, then it simply wouldn't make it in the spec. And the idea was that there would be one specification, many implementations. And I'll cover in a moment why that's useful to have many implementations. Actually, the more, the better, but that there would not be any divergence between if a feature existed and was fully implemented, that it should be reliable in all implementations. That's the agreement that everybody signed up to. And I would say for the most part, that is still absolutely true today. You know, almost a decade later that every JavaScript implementation from Node all the way up through all your browsers and your mobile browsers, the vast majority of everything that you interact with that is JavaScript, the language, that is implemented faithfully in all those engines. Now there's a couple of things to be aware of. Number one, because there are so many different implementations, it might very well be the case that one implementation has a feature before another implementation does. They're allowed to go in whatever order they want to prioritize work, to implement things that are not yet standardized, but are on the track to being standardized. So you may have Chrome with a feature and Firefox not or vice versa. So that is a divergence in the sense only of timeline, but it is not going to be the case that arrow functions work differently in Firefox's spider monkey versus Chrome's V8 that once they get arrow functions, they're going to be the same everywhere. The other thing that trips a lot of people up is that there's a bunch of code that we write and interact with especially in browser environments, but even in Node, there's a bunch of code there that looks like JavaScript and isn't actually the JavaScript language. It's interfaced through JavaScript, but you're actually interacting with web platform APIs, for example. So all geolocation and the WebRTC and the camera and all the things that you, you know, even stuff like document and the DOM and all that, all that looks like JavaScript. You call JavaScript looking functions but it's not really JavaScript and it's not controlled by the JavaScript spec. So the divergence that you see between IE 11, for example, and Chrome 82 is much more accounted for in all the web platforms who do not, by the way, have a one JS or one web packs the way JavaScript does. So ironically JavaScript is actually way more consistent than any other web technology. It's way more consistent than all the web platforms. It's way more consistent than CSS, than HTML. All of those do not have the same principle that JavaScript does, which is if you're a conforming spec compliant engine, then you completely agree to do this faithfully. So we interact with a lot of code that looks like it's JavaScript and when it behaves differently in one versus another, we blame JavaScript when actually that's not really JavaScript's fault and there's nothing JavaScript can do about the fact that a web platform API, you know, may differ between browsers. So I would just say Charles, uh, the good news is that when you focus, like I did on only JavaScript, it's a lot easier because there's just the one JavaScript to talk about, and that's kind of why I chose that was I wanted to focus on the language itself, those, that is universal everywhere that you go, that you're going to write JavaScript, you need to know the language, you need to know all the ins and outs of it. And if you invest the time to learn JavaScript, the language, that learning is completely portable to every JavaScript environment. I can't do anything about the fact that browser APIs work differently than node APIs. That's also stuff that you should learn and get good at, but at least I can tell you, if you learn how an arrow function works, it's going to work the same everywhere, but backing up a little bit to your, your bigger question of the 

CHARLES MAX_WOOD: of the why, 

KYLE_SIMPSON: yeah, the, the why behind choosing this. I personally feel that there's a lot of focus in the broader community on a lot of things. I don't mean it at all to say that they're not important, but I think they get a lot more attention than the language itself. And that is the broader ecosystem. There's a lot of focus on frameworks. There's a lot of focus on tooling. There's a lot of focus on libraries. And I basically said, well, how come nobody's really focusing on Fully fleshing out the language. Um, that's the part that I felt was underserved at the time. And I even still feel today that it's underserved. So my choice was deliberate to say, let everybody else play in specialized in view and react and angular and a million other things that there's a, it's a big tent, there's plenty of room for all of that. But what I want to be known for and what I want to be really good at is knowing JavaScript, the language. I essentially said, I will work on learning JavaScript until I've learned everything I need to know about it. And we're, I don't even know how many years in, but I've still got a long way to go. Got a lot more to learn. So when you wonder where does, where does all this come from? Like, how was I able to say all of this stuff in the book, uh, about JavaScript? Well, there's a couple of really important answers. Number one, I went to the source of authority on the language, which is the specification. And when I first started trying to read the spec, I was terrified because the wording and the language and the organization felt like Greek to me. It felt like I needed to have a PhD to understand what was going on. And in fact, you know, one of my hangups was that I, for years had tried to understand the spec and tried to participate on the standards list, for example, to suggest an idea. And I would hear them throw a bunch of terminology or an acronym at me. Like my favorite one that was thrown around all the time was MOP. And I saw that probably 250 times over the course of several years, thrown around on various threads on TC39 discussion lists. And people would just say, well, mop this and mop that. And I had no idea what that was. And that's not a particularly easy acronym to Google for. So I had no idea. And then one day I accidentally stumbled on a blog post that explained what mop was. It's the meta object protocol. It's the way that objects work in JavaScript. But the people in TC39, they haven't. It's been so long since anybody there ever remembers not knowing what that meant, they throw it around like it's English. So it was, it was tough for me. I was, I was coming up against a lot of really entrenched tribal knowledge that they knew this stuff, but they didn't know what it was like for people to not know it and I was the outsider trying to come in, so it was very, very challenging. I'm tremendously grateful that at the time that I was tackling all of this, I was friends with Alan Wirf Sprock who was the editor of the ES6 spec. He also was a major contributing editor to ES 5.1 and ES 3. So he's been around JavaScript forever, but he was the main editor of the ES6 spec. And so as I was trying to figure out what the heck I was doing reading the spec, I asked him a million and a half questions and he was tremendously generous with his time to answer and indulge. A lot of questions and a lot of like pushing back and I was kind of an asshole sometimes. I was like, you know, doubting that it should be that way or whatever, but he was, he was very generous with his time. So I went to the source authority, I read the spec and I had to learn a lot to just to be able to understand what it was. Now I don't mean to say that to like turn people off. I actually think every JavaScript developer out there by the time that you're say six to 12 months in, you probably should start to look at and read parts of the spec. I think you should start to get comfortable with that. And usually, when I ask a room of 100 developers, how many of you have ever read any part of the spec, I get like four hands. So I think more people should read it, but I agree that it is a tall order to read. So what I said about to do with the books is I was realizing how hard this was is to say somebody needs to write a guidebook to figure out how to navigate through this. A lot of books. Take one perspective, which is I'm not going to talk at all about the spec. Not going to use accurate terminology. I'm just going to use a lot of aphorisms and a lot of like mental metaphors and just whatever. And I'll just describe JavaScript in a very intuitive way. Some books do that. Other books are like textbooks where it's all terminology and it's all specification speak. And what I wanted to do was do something in the middle, something between the encyclopedia and the Cliffs notes a guidebook for the journey of figuring out JavaScript. So in essence, the You Don't Know JS books are me illustrating to you, the reader, how I figured out how JavaScript works by primarily by reading through the spec and by testing everything that I could figure out, writing, testing, trying it out, seeing how it would break, taking it apart, doing different sorts of snippets. It is just an almost obsessive level of detail of that where I would try something. And when it worked, I didn't just stop there. I said, well, how did that work? What's the reason for why it did that when this other thing did this? And I would ask that question and wouldn't stop until I got that answer. And that answer led to another question. So basically I just got really good at asking questions of the spec. I want to know why it does that. And then I would go and learn whatever it took to learn that. And then I would go write a, I hope, approachable guidebook on how to learn that stuff without having to become a master at the specification. So that was, that was my approach. That's how I did it was I figured that stuff out. I relied heavily upon smart people like Alan. I relied heavily on good resources like MDN, but by and large, I read the spec and I tested all that code and then I figured out how to explain it. 

DAN_SHAPPIR: I'm curious since you went over such a breadth of the language, which part of JavaScript do you consider to be the most confusing or misunderstood? 

KYLE_SIMPSON: That's a very loaded and interesting question. I'm glad you bring that up. So confusing and misunderstood are actually very different in my book. There are parts of JavaScript that I think, even though I have read the spec, even though I know specifically how to explain why it does something. I don't have any sort of advice or intuition as to why it ended up that way. There are historical reasons, like, you know, we were constrained by a bug in one browser that caused us to do it this way and what, you know, there's weird and stupid historical reasons for why a lot of things land that way. There's a lot of political reasons for why things land a certain way, like lots of different people on the committee and what can we get people to agree to and have consensus to. And committee-driven design, even with champions like TC39 does committee-driven design, oftentimes does end up with things messier than we would love. So the why behind a lot of those questions isn't always satisfying. Um, so when I say confusing or things that I think you should learn and then not, not do, you know, Dan, what you brought up, we can go back into the idea of Functions function declarations and blocks. How does function declaration hoisting work when a function is declared? Inside of a block that is one of those areas where I would label it as the RB dragons. I know exactly what it does and it you can with pinpoint precision. Specifically explain it just like a doctor or a scientist can explain something and then you can still as I do sit back and say WTF. How on earth did we get to this point? Why is it that way? And what on earth are we supposed to do with that in our programs and not trip over it? And legitimately the answer to that that I have come up with, and it's exactly what I say in my book is just don't do it literally. Just do not, you can, it is legally allowed. I strongly recommend you don't put a function declaration inside of a block because what you're going to get is nonsense. In particular, in this case, the reason why it's so nonsense is the spec says one thing, and then there's this little exception in the spec, which is called appendix B appendix B of the specification is where they detail intentional deviations in the web browser based JavaScript engines. They carve out a niche that says web-based JavaScript engines, which most JavaScript engines are. Web-based JavaScript engines are allowed to violate the spec in the following ways, we're listing those out and there's political and historical reasons why. But here's the list of violations that are allowed. And guess what? Functions in blocks is allowed to be undefined, meaning you can get different behavior in different engines if you're in a browser-based JavaScript engine. And it's because long before the spec had an answer to that, different browsers did different things. So we're stuck with. One of the frustrating things, which is that even though I said there's one JavaScript and it's predictable everywhere, there's always exceptions to these rules. And it turns out that appendix B is kind of our, uh, our horror trail guide map to where those things get really weird in different scenarios. So that, that to me is the answer to your question of where, where are things confusing? Another example is the sparse arrays question, like the idea that JavaScript intentionally allowed you to have an array with an element that is unfilled. It doesn't have any value at all, but it sort of pretends like it's there in some cases and not, that's just, it's just, that's crazy. Like we shouldn't have that. That's totally nonsensical language design and it's frustrating. That's what I mean by confusing misunderstood is an entirely different category and a lot of the language is there. I, if I had to pick one thing that I think is most misunderstood. It's probably not a surprise that when I tell you it's the type system and coercion by far, I think it is the most hated or under understood and therefore most likely to draw ire part of the language. I think most JavaScript developers would tell you they don't like JavaScript's type system. They think it's bad. They think it's buggy. They think it's poorly designed or whatever. And respectfully speaking, I think they're all completely wrong. I think JavaScript's type system is actually one of the most beautiful and powerful type systems of any language in existence. I think it's completely and totally discounted and unfairly so. And I think we actually should be embracing it to write what I would consider to be much better JavaScript. That is what I call type aware. That's a, that's a recent advocate CEO on my part is to suggest that we should write type-aware programming, but that doesn't mean I think we should write TypeScript. It means I think we should write JavaScript and use JavaScript's types in the correct way. So I'm just, you know, people will find things to disagree with me on and that's okay, as long as you're talking and analyzing, then I'm good with that. But that's the thing that people tend to disagree with me the most on, is when I suggest that I really think there's a lot here that you're not. You're leaving off the table and you really should come back to this and you really should learn this better. That's the one area that I think is most misunderstood about JavaScript. 

CHARLES MAX_WOOD: That JS remote conf Douglas Crawford did a Q and a, and people asked him about TypeScript and flow and his answer was, well, as far as the typing system goes, that's a problem I haven't had with JavaScript. So he more or less came down in the same place you did. Right. The type system is fine. It's great. It does you know, more or less what I want it to. You know, there are some other areas. I mean, you mentioned the RB Dragons in a couple of other areas and yeah, and he kind of advocates for working around those in specific ways. But yeah, it was, it's interesting that, you know, some folks who have done some deep dives into the language and how it works have come back with some of these same conclusions as you. 

KYLE_SIMPSON: I don't know that I would say that Crockford and I have the same conclusion. Probably. It's probably fair to say that Crockford and I are at least as well known for our strong opinions. I think that is fair to say he and I are pretty divergent on a lot of things. And on types, we are divergent in the sense that Douglas's answer to when JavaScript is difficult or it's hard to understand his answer is essentially, well, that's a part of the language you shouldn't use. And where I may take, where I may take something very specific, like an example of function declarations and blocks and say, you probably just shouldn't design your software to need that. He will take what I consider to be whole cores of the language and throw them out. And coercion is one of them. So when he says, when he says that he hasn't had the types problem, it's mostly because he advocates only using triple equals and not worrying about coercion. And I'm actually in the completely opposite direction, which is I don't have the same problems because I actually know how the types work. And so I use coercion quite, quite effectively all day. And I will just say that his, I will just point out that his response in being asked about TypeScript, it sounds like he has a more, shall we say politically correct answer. Now his feeling on TypeScript used to be, and I imagine there's probably still some of this in the background is he was asked. Years ago, I was at the conference and speaking right after him. So it's, I distinctly remember it. He was asked in the audience, what do you think about TypeScript? And his response was effectively TypeScript is for braindead developers who can't think about types correctly. I'm glad he doesn't think that anymore, or at least he doesn't say that anymore. And I don't think that is true either. I think TypeScript is good. I just think it's not JavaScript. I think it's a different language. And I would like to advocate that there's other ways to be type aware in our programming that embrace JavaScript. So he and I have different opinions strongly on how we ought to use types, but we both agree that TypeScript is not the answer. 

 

Hey folks, are you trying to figure out how to stay current with React Native? Maybe you heard that Chain React conference was canceled and you're a little bit sad about that. Well, I borrowed their dates and I'm doing an online conference. So if you want to come and learn from the best of the best from React Native, then come do it. We have people like Christopher Chedot from Facebook. He's gonna come and he's gonna talk to us and answer questions about the origins of React Native. We're also going to have Gantt Laborde from Infinite Red and several of the panelists and past panelists from React Native Radio. So come check it out at reactnativeremotekonf.com. That's reactnativeremotekonf.com. 

 

DAN_SHAPPIR: You brought up an interesting point and I'll deviate to TypeScript a little bit, even though this discussion is about JavaScript, that I recall an early – when TypeScript more or less came out as a public project, there was an early interview with Anders Helzberg, who, for those of you who don't know, is like the creator of TypeScript before that, the creator of C Sharp more or less. 

KYLE_SIMPSON: He's created a lot of languages. He's been around for quite a while.

DAN_SHAPPIR: It's interesting, he created a lot of variations of languages, more than like fresh languages, let's call it that way. But interestingly, he said in that interview that TypeScript, he didn't call it a programming language, he called it a tool. And it's a means to create safer programs using effectively JavaScript. So he referred to it as a tool on top of JavaScript making it more friendly with editors that have auto-completion and generating more correct code and so forth. And at one point in time, it essentially evolved from being seen primarily as a tool on top of JavaScript into its own programming language. And it's an interesting transition that I don't think a lot of people actually thought about as it was happening, but I definitely agree that it's now gotten to the point where even though it's a subset of JavaScript, it's a different program. 

KYLE_SIMPSON: A superset is how it describes itself. 

DAN_SHAPPIR: Yeah. It's a different language, in a sense, kind of like, I would say that maybe C++ is definitely a different language than C. So in sort of a similar way to that, I think. 

KYLE_SIMPSON: So here's why, I'm glad you bring it up. Here's why I don't think it's appropriate to think about TypeScript as just a better version of JavaScript or an improved augmented JavaScript or a superset of JavaScript. Here's why. Because when you talk about something as fundamental as how values are treated and the intrinsic behaviors that they get based upon their, their fundamental types, like a number behaves differently than a string, for example, when you start talking about that sort of stuff, you are basically talking about the entire ergonomic surface area of a language being affected by the choices. When a language chooses to be a dynamically typed language, almost every other decision is therefore affected by that decision. So if you took a step back and you said, I'm going to design a new language, one of the very first questions that you should ask yourself is, uh, how am I going to handle types? Am I going to go with the static typing or am I going to go with the dynamic typing? 

DAN_SHAPPIR: I'm sorry. I have to interrupt you because I do think our listeners need a definition from you of dynamic typing versus static typing. So I apologize if I interrupted you, I had to explain explaining that, but you have to explain it. 

KYLE_SIMPSON: No, it's a, it's a good, it's a good question. And it's a segue that I planned to explain that decision-making takes you down one of two very different routes. And before I explain why, why you choose those routes or what those routes mean, let me just finish the thought by saying that the route that you go down, the path that you go down, these are, these are divergent roads. You end up with a very different language at the end when you started with, I want to design by answering the question with static typing versus the language you get when you design thinking about dynamic typing. What we're trying to do quote-unquote with TypeScript is go all the way down the path 20 plus years down the path of language design with the assumption of dynamic typing and then hop over to the other train track. And I think that's just a terrible idea. What we have in JavaScript is a language that was designed to do dynamic typing. And we have a perpetual process where nobody decided to like, evangelize that the dynamic typing was good. So everybody just complained about the dynamic typing. And then we said, well, why don't we just like completely course correct with this thing, TypeScript? I just think that TypeScript is in some ways the worst of both worlds because it's a language it's put on top of a language that was designed to be dynamically typed and then it awkwardly sticks the static typing on top, and I think it doesn't work. So to, to, to walk backwards then and explain what that means or put more color into that dynamic typing is about saying that the important thing is what type does a value have when it enters an operation? Like for example, I have a value that's coming into the plus operation. I have two values because it's a binary operator. I've got two values that are coming into this operation. What are the intrinsic types of those values at that moment? And if both of them are compatible to be numerically added, then we'll do numeric addition, right? That's dynamic typing. If one of them is not compatible, what do we do with that? Do we throw out an error or do we, as JavaScript and other languages do, do we try to convert it to something that can be numerically added together? That's what dynamic typing is. The focus is on the values and the operations and the expressions that are happening. Now on the different side of the world. There's a way of solving or at least articulating the way types work, which is not focused really as much on values and on operations. And it's focused on what I would call the containers, the variables, the properties and objects, the arguments in function calls, all those things. Those are all containers. And what we could say is we're not going to worry so much about the type of the value. I mean, values have types, but we're not going to focus on that. What we're going to focus on is the container type. We're going to say this parameter can only ever hold integers and this variable can only ever hold strings and this, whatever this object property can only ever be arrays of numbers or whatever. So what we're going to do is type annotate. We're going to strip strongly and strictly annotate what this container is allowed to hold. And what we're going to do is answer the question that a programmer has, which is, is my program correct? We're going to answer that question in part by saying it cannot be correct because you have an X that you said is supposed to hold integers and this operation results in strings. So your program cannot be correct. So what we're doing is we're saying, let's create a way of having the tool, the compiler tell me that my program is not correct by telling me that the expectation, the contract that I set up, that this should only ever hold numbers. That contract is being violated. So that's one very important set of questions that, that a developer wants to ask is, is my program going to do what I want and can the tool tell me yes or no? And we've constructed a whole thing like static typing where we type the variables to answer those questions. Now, if you go back to the dynamic typing, there's a different set of questions that developers are asking, but they're not really that different. I'm still asking, is my plus operation going to result in a useful number for me? Is it going to result in something sensible that I want? I'm not asking, is my parameter going to be a number? What I'm really saying is, did two plus two actually end up equaling four? So they both, both type systems, both ways of thinking about typing, answer fundamental questions that developers have. They just tend to go about them in very different ways. And because they go about them in very different ways, You net, you necessarily should design your language differently. If you're going to pick answer the questions being asked and the quest and the answer is being given. You need to design a language differently based upon that choice. You just shouldn't try to mix the two. And so I really think it's a bad idea to, to 20 plus almost 25 years later, come back and say, no, let's, let's undo that decision from 25 years ago. And take this language, which has been designed for the last 25 years to be dynamically typed and just artificially bolt on top of it, the static typing. What we, I think should do is recognize that some people and some problems are better, well suited, more well suited for being solved with languages that are statically typed and that frame their questions and answers in that mindset. And there are other problems that I think are more well-suited for a tool that asks and answers questions in the dynamic typing mindset. And those should coexist in the world. And I don't think that mixing them makes a lot of sense. So that was probably way more detailed than anybody was interested in, but that's what I think about the typing systems. 

DAN_SHAPPIR: I actually enjoyed it a lot, and I agree with what you said. We have several projects going on at Wix which use TypeScript, and I've seen people on the one hand really enjoy TypeScript, being more expressive about types, but then run into situations where they're trying to express in TypeScript things that are legitimate operations or expressions in JavaScript. And not too difficult, but it turns out that expressing them in TypeScript and not just putting any type any on them because that basically just puts you in JavaScript land all over again. 

KYLE_SIMPSON: That's your escape hatch. 

DAN_SHAPPIR: Yeah. But then you're basically, you're basically just doing..Yeah, you're basically just doing JavaScript, so what's the point? So they're trying to express it with types, with generic types, and stuff like that, and they run into incredibly complex and complicated type expressions. And the funny thing is that when you run the compiler on it, all these type expressions essentially evaporate. So they are spending a huge amount of time on code that ultimately is like totally erased by the compiler. So what in fact are you working on, spending all that time and effort? Now again, I'm being like a bit cutesy here because there is a purpose, they're trying to be more type-safe. But still, like you said, if it were a language that was designed from the get-go to being statically typed, like I don't know, like a Reason ML or something like that, then I would be on board. With TypeScript, I have issues very similar to the ones you listed. 

KYLE_SIMPSON: So there's two things at play. I'm glad you brought those points up. And there's two things at play that I want to call out. Number one, what you say is totally true, that what ends up happening almost necessarily is that as you get more and more into the nitty gritty of an application, it's not ever at the first architectural layer levels where you run into these problems. It's when you get into the real nitty gritty of like. You know, pulling some stuff from, from 14 different Ajax calls and munging it in the DOM and all, you know, it's real, it's down in the, it's near the bare metal when you run into these problems, you end up creating such complex type expressions to handle all of the different dynamically type things that can happen in the runtime of a JavaScript, just to account for all those things. You end up creating such wonderfully complex type expression or type annotations that I think the, if you took an objective step back, you would say, I am working for the tool instead of the tool working for me. The whole purpose of a tool is it's supposed to work for us, but we end up getting into such complex scenarios where we have to work for the tool. And I think we've, we've, we've lost sight of the purpose of the tool at that point. So it would not be a concern of mine if somebody wrote a TypeScript program where they had a couple of colon ints and colon strings in various places. But that's not what you see in most modern TypeScript. What you see is when you start dealing with the complexities of a waiting, a promise that could be an array of several different values that came in, the type expressions that people have to write to try to express that complexity are so far beyond what most people can process and what they can think that the types themselves become a whole separate language. And that's where I think we've gone way beyond what a type system should be. The second thing that flows from that is the reason why that happens, I think, is because you have a dynamically typed language, which expresses an awful lot of its types at runtime and a statically typed language is saying, I don't want to deal with the type question at runtime. I want to completely deal with the type questions entirely at compile time. That's why you'll see that TypeScript, as you said it's a compiler that compiles all that stuff away. It complains at you at compile time. When you're in your editor, it never does anything about what's going to happen at runtime. It's going to assume that the runtime is type safe because it's going to assume that you dealt with all your type questions at compile time. And if the thing successfully compiled, therefore no type problems can ever happen. That is a tremendously flawed assumption. Like maybe the largest, the biggest, most flawed assumption that you could possibly have is that there is some way to write JavaScript programs where you know all of the type questions have been completely answered at compile time. In my opinion, some of them can be thought about at compile time and analyzed and reported to you at compile time. But there's a whole set of type questions that can only properly be dealt with at runtime. And what you see in the complexity of something like Flow or TypeScript is an attempt to try to wrangle runtime complexity at compile time. And I think it's this giant red flag that says you're doing it wrong. If you have to go to that level of complexity, what we should be doing is looking for a tool that embraces type aware programming in a dynamically typed language like JavaScript that embraces that some typing can be determined and validated and checked and error reported at compile time. But you also need a type system that is present and working for you during the runtime. TypeScript says, nope, we don't need a runtime because we're going to find everything out at compile time. And it is up to you, the developer, to jump through all of the hoops that you can to make that true. I would like to say we need to do this a type system in both, we need to type system at compile time and at runtime. And I'm not just spouting hot air here. A system like that can exist. And in fact, not that I'm here to like promote it, but it does exist. I have built it. I have been working on this for almost a year, an alternate way of doing type aware programming with a tool that embraces both static and runtime typing. That can exist. It's just that the big marketing budget is behind TypeScript.

DAN_SHAPPIR: So say what it is. Come on. 

KYLE_SIMPSON: It's called, it's called typo T Y P L. And if you search on my GitHub, you'll find typo. It's about 80% of the way to a 1.0 release. And I'm just so busy that I haven't finished it, but it does most of what I just said already. So. 

CHARLES MAX_WOOD: Nice. Wow. We, we deviated all the way into that. And I mean, it's brilliant. Yeah. And I love kind of the exploration of what it means and what the trade-offs are and things like that. I would like to push us back a little bit to the books and the book content for a minute. How did you decide to organize all this stuff? Because there's a lot in how JavaScript is put together, right? And some of it feels like it's, oh, we need this kind of thing. And so they just kind of bolted in, right? So, yeah. So how did you wind up organizing everything?

KYLE_SIMPSON: So originally in the first edition, the organization was around the three core pillars. I said I wanted to write three short books. They were gonna be on what I called the three pillars of JavaScript. The first one is the scope system, the lexical scope system, which brings with it the topic of closure. The second core of the language is the object system, which brings with it both the this keyword and the behaviors there, but also class-oriented or class-styled coding. So that's the second core. And the third core of the language is how types work, the types and the coercion system. So the three cores were the three books that I was going to write. As I got partway through the third of those three books that I was writing, I realized that the first book jumped the scope and closures book jumped right into the deep end of the pool. We started talking about compiler theory. I realized that the series itself would not be as approachable if we didn't have some sort of onboarding, if you will. So I went back after having written those three, or actually I think after written, right, writing four, I went back and wrote the intro book, if you will, the up and going book to say, let's start from nothing and work our way quickly to the deep end of this. Cause when you dive into scope and closures, it's going to get deep. Let's work our way up. So I started with the three cores. I added the up and going book to onboard people. The last two books in the series five and six, if we're going numerically, book five is on async and on performance. I felt like the area that was most likely to create confusion at the architectural level of virtually every JavaScript application in existence was fundamentally that our brains are not taught to think the way asynchronous programming requires us to operate. And if our brains don't work that way, then the language is actually working against us. It's not helping us express what we want. And that's probably the source of virtually all bugs in programs, is that we think a certain way and the program works a different way, because that's how computers work. And the divergence, I've said this famously many times, the divergence between the way your brain works and the way the computer works, that's where bugs enter. It's right at that junction point. So what I felt like was we've got to have some book cover how asynchrony works, how that really works. It's not like teaching threaded programming. You need to understand concurrency in an asynchronous event loop system like JavaScript does. So we needed to cover promises. We needed to cover iteration and things like that. And I also wanted to talk about a lot of misconceptions around performance because a lot of people think they understand that this operation is faster than that one, but it turns out almost all JavaScript performance assertions that humans make are wrong. Basically almost every test that was ever written on JS perf is wrong. It's flawed in some way and it gives you the wrong results and you probably should just ignore it. So I wanted to talk about exists. I think though, I think it came back at some point. I don't know if it's out there still. I think it was gone for a while. I think it came back. I don't know, but basically people are really terrible at benchmarking JavaScript and only, only a select few are, and I'm not in that group, a select few of which I am not part are qualified to really actually benchmark JavaScript. The rest of us should just think intuitively about other more important things like, does my code explain what it's doing? We shouldn't be getting into the weeds of is, is plus plus I faster than I plus plus cause it turns out the JavaScript engine is not going to do either one of those. So stop thinking about that stuff. But, so I wanted to cover that. I wanted to cover some misconceptions, mostly some myths about JavaScript performance. The final book, this was a really important and strategic one. And I pitched this from the very beginning of the series that we would need a book that was kind of the nod to the fact that this is not a language that's finished. This is a language that's going to continue to go. I didn't think that I would write updated versions of books one through five. What I expected to do was come back and write second, third, fourth, 20th editions of that last book. And so I called that last book ES6 and beyond, because the point was this is going to cover, if we've covered the core of JavaScript, this book is going to keep getting updated with everything that keeps happening new to JavaScript. That was my plan with first edition. Now as it's played out, I went a lot longer between the first edition and second edition work than I had hoped. It was nearly five years from the time the last book came out to when I started working on the first book of this second edition. And this time, since I know the six books, I know the order that I want to go in. So I started with the intro book and I thought, well, kind of like edit this a little bit, try to make it a little bit easier for people to understand. I ended up completely rewriting the book from scratch. It ended up twice as long, very different, not different tone. Like it's the same gettify talking all the time, but like a very different approach to the topic. Uh, a different strategy for who, who was my audience and all that. So by the time I had written this new book, I knew it needed a different title. So it had to be called Get Started instead of Up and Going. And I realized that that was going to be true of all the books, that this wasn't just going to be a single book that needed to be updated, but really all the books needed to be rewritten from scratch. So that's when the second, the full second edition series, which I now call You Don't Know JS Yet, that's when that was born was saying, I guess I'm going to need to rewrite all six of them. And do some things differently, shift some focus. I'm five years further along in my understanding of how to explain JavaScript and how to ask the right questions. So as I go back over the books, I cringe a lot at like, Oh, did I use to say that way? That's not that helpful. And I appreciate the fact that thousands on tens of who knows how many people have have benefited from the books, but it's not. Today, how I would explain those things. I have a different and I think better way of explaining them. So the second edition books are complete rewrites from the ground up. I'm just deleting everything and starting over on each book. Largely the organization is about the same. So we have a get started book that helps you understand the overview of the language and get ready for the rest of your journey. We have a scope and closures book. That one's title is the same. And then books three through six are going to track. Similarly, but with different focus. So book three, which I haven't written yet, but book three is not called this and object prototypes anymore. It's actually called objects and classes. And that's a nod to the fact that the reality now is different than it was when ES6 was still being formed, which is whether I like it or not, class oriented programming is a fact of life in JavaScript now and a book that doesn't cover it in full detail is a book that is doing readers disservice. So even if I personally don't love the idea of class-oriented coding, the book needs to cover that. So that is now a first class topic rather than kind of an addendum-ish topic in the previous book. So objects and classes will be book three. Book four is going to be the next one. 

DAN_SHAPPIR: Wait a minute. Before you move to book four, you mentioned classes. I was going to make a comment that haven't you heard we're not doing, we're not using classes in JavaScript anymore. We're using hooks instead. And I'm, and I'm making it, and I'm making it jokingly because I know that you've, you've dabbled in that as well. 

KYLE_SIMPSON: Yeah. So that won't be covered in that book. However, a whole separate book that's not part of this series that I wrote on functional programming, a sequel to that book is out on the horizon. And when that sequel to functional. Uh, like JavaScript comes out, it's going to cover hooks. So that's a bit further out, but it's on the horizon. It's already part of my master plan. I'm going to cover classes in a full faith attempt to explain them. Even if my opinion is that I don't think that they're very useful for what we do in JavaScript. I think like TypeScript classes is an attempt to post-hawk change the nature of the language to be something different. And like TypeScript, the change to that nature is that classes want to make the typing decisions static decisions. They want to get away from dynamic typing decisions. That's at the heart of how classes were designed for JavaScript. So if you're a big fan of static typing, you probably are also a big fan of the class keyword. Because I'm not a big fan of static typing, I'm not a big fan of the class keyword, but I'm going to give it a full-throated and a good faith attempt at explaining it fully so that you can use it properly if that is your choice. I don't want for my books to say, don't do it. What I want for my books to say at all times is, here's the full and complete story and I want you to choose what's best for you. Instead of following what the blogs say, what the popular conference speakers say, I just want you to be empowered with both sides of the story. Let me give you the debate. Let me make the case for what this is my opinion. This is where I think you should go. But at the end of the day, do the exact opposite of what I say, as long as you own it, as long as you really believe and can articulate why you want to do it. Great. Do that. That's a win for me. I don't want people to follow blindly what I have to say. I want them to own that decision. So I'm going to fully explain classes and I'm also going to fully explain why I don't think you should use them, but that's what book three is about. 

DAN_SHAPPIR: I'm going to be more explicit than you are. Please, please, please don't create deep class hierarchies. Yes. Then there be the road to hell. 

KYLE_SIMPSON: Yeah, I agree with you. The vast majority of all JavaScript classes, they don't use the extends keyword. I bet the extends keyword is used in 0.1% of all JavaScript programs. It's almost never used and certainly not multi-level. So I agree with you, Dan, that that is the road to pain. And I would suggest. If you know it's the road to pain and you don't want pain, just don't even get on that road. But anyway, so we could do a whole other episode on what I think about classes, but let's, let's move on to where I'm talking about the books. Uh, book four is tackling that whole types and coercion system. What I have different now, I, a lot of people think that I never changed my opinions. I actually have very different opinions now, even than when I wrote the books the first time. So I have different opinions, which is part of why I need to rewrite books. But my opinion now on types and on how to use them properly in JavaScript is not, let's just ditch types and forget about them because they're terrible. And let's just go do TypeScript. My opinion now is actually instead of having it be a sort of a subtle thing in the first books, I suggested that it was kind of a subtle and behind the scenes thing that you should be aware of, but not really interact much with. I now think type aware programming, the types that you're using and what you're doing should be front end center. And so I have a very different narrative that I want to give to this topic. And that needs a whole new book to do so. The conclusion is still going to be learn JavaScript's type system and use it. It's not going to be go use TypeScript, but I'm going to talk about how I think even without the tool that I'm building, I'm going to talk about how I think you can use type aware programming and JavaScript and get the most benefit of it. So that'll be a book four, book five. We're still going to talk about asynchronous, but the shift is now to really hone in on the difference between synchronous programming versus asynchronous programming. So book five is called sync and async, and we're going to compare and contrast that topic through a bunch of different features in the language. And then book six, the forward future facing one is now called ES next and beyond, because I don't know what the number is and I want it to live longer. So the book six will be called yes. Next and beyond. 

DAN_SHAPPIR: Isn't, isn't it, but well kind of yes next means that there is no beyond though. I mean, yes, next is everything that is beyond. 

KYLE_SIMPSON: Are you trying to, are you trying to like call out my puns that my puns aren't good enough? Yes, next is the, is the catchall term for stuff that we know is likely to land in the next numbered version of the spec. So we have a set of stuff that we expect to land in es 21 because it is either already reached stage four after ES20 was cut, or it's in stage three and it's headed to stage four by the end of the year. So we have a set of things that we are pretty sure are going to make it into the language and we generally call that stuff ES next, meaning like immediately next. Then we have other stuff that's going to come later or maybe never come at all, but it's still worth knowing about. It's on the horizon. It's stage zero, one, two. Maybe it's been in stage two forever and we're hoping that the log jam will come out. That's what we call beyond. So yes, next is the stuff that's a little bit more likely and immediate. And beyond is the stuff that's a lot less likely and a lot less certain, but we should still talk about it. 

DAN_SHAPPIR: I'm curious of advanced features like iterators, generators are going to be in there or, or what 

KYLE_SIMPSON: that's going to be covered in the sync and async. I want to fully cover the question of iteration because there is both synchronous iteration and asynchronous iteration. So that all is going to be covered fully in the sync and async book. 

CHARLES MAX_WOOD: Awesome. We're kind of getting toward the end of our time. So I think we ought to make our announcement. And then go ahead and do picks. And I'm just going to give a little bit of context here. So there was something that I wanted to learn relates much more to sponsorships and running the podcast network, but I wanted to learn it. So I started picking up books and ran across this challenge. And it was a four week challenge where they gave us coaching calls. They gave us kind of a place to congregate. They used a Facebook group, which I don't always love, but they had a members area for us that kind of walked us through the exercises we were doing every day. And at the end of the time period, we had learned a ton of stuff and we had something to show for it at the end. And I thought, man, this would be great for JavaScript. And so I started looking around and I'm like, you know, what framework is out there for people to learn this kind of thing? Right. Because at the end of the day, right, I want people to have leveled up in a significant way with JavaScript. And the first thing I ran into was Kyle's books. And I'm like, oh yeah, these were terrific. Right. When I read them, I loved them and they explained a lot of the stuff that I didn't even know I didn't know about JavaScript. And so I emailed Kyle and I said, look, I want to put together this challenge. I want to base it on your books. I want to make sure that, you know, people have this framework for picking up JavaScript and learning them. And it turns out that the first book is really set up sort of perfectly for this. Because as four chapters, it's a four-week challenge. We decided to bump it out to 30 days, like right before the show, somebody threw out an idea and I love it. So we're going to incorporate it. But essentially what we're doing is it's going to be four weeks. And each week we're going to focus on one of the four parts of, of Kyle's book, or is it four chapters? I can't remember. 

KYLE_SIMPSON: There's four chapters plus some, some appendices, but yeah, four main chapters in the get started book. 

CHARLES MAX_WOOD: Right. So, so that's what we're working on. So you're going to get a video training for me. I might rope Kyle into some of those. I'll see if I can make him work, but. Yeah. We're going to have Q and a calls, at least two Q and a calls a week. We're going to have a Slack channel for you to come and get help get an interaction, things like that. I'm talking to a few people about being mentors and being around so you can get help as soon as you need it. We're going to give you exercises every day or at least every weekday. Anyway, the whole plan is just so that at the end of the time, at the end of the four weeks, you will have leveled up and understand or master all the areas that are covered in the book. And then the last two days, we're going to have a hackathon. And I'm going to reach out to some companies and see if we can get some prizes for that but it's only going to be there for the participants. Oh, and I forgot, Kyle and I are also going to sit down and we're going to record eight podcasts, probably two per chapter, that you can get on a podcast feed so that you can actually just subscribe to it. That'll only be available for challengers as well. Now, the regular price on this is going to be $197. But if you're listening to this podcast and you register for the challenge before the 4th of July, it's going to start on July 20th. So if you register for the challenge before the 4th of July, you can get it for $147. And if you use the coupon code JSJABBER, it will get you in for $147. And then like I said, you'll get all the worksheets, all of the exercises, all of the training videos, you'll get access to the podcast, you'll get access to the Q&A calls every week, and you'll get access to the Slack channel. And if you get into the Slack channel early..

KYLE_SIMPSON: You're going to get a free ebook of the get started book. Oh, right. So you'll have it in ebook form. 

CHARLES MAX_WOOD: Yes, I forgot that you will get a copy of the book. So, so I'm, I'm really looking forward to it. If you sign up early, the other thing I'm going to be doing is dropping into the Slack channel, a talk or something public. Some of the podcast episodes that we've done with Kyle, just so that you can kind of get some early level up and prep before the actual challenge. I'm really looking forward to having everybody around. And kind of creating this experience for folks. If it goes well, I'm pretty sure that I can twist Kyle's arm and we can do it for the next book. 

KYLE_SIMPSON: Sure. 

CHARLES MAX_WOOD: But I'm not making any promises for him or for me, but that one might need to be longer than a four week challenge. 

KYLE_SIMPSON: That's a bit meatier of a book. So yeah, I don't need a longer challenge. 

CHARLES MAX_WOOD: Yeah. We'll have to, we'll have to see how that goes, but anyway, so if you want to dive in and take the challenge, we'll put a link in the show notes. You can also go to devchat.tv. And we'll have a really convenient link there so you can just find it and sign up for the challenge. And yeah, then you can level up and you can tell your friends that I used to not know JS yet and now I know JS. 

DAN_SHAPPIR: I have to say that it sounds awesome. I'm really excited about this and I'll probably find some sort of a way to involve myself in it as well because it just sounds so great. I think it's an awesome thing that you guys are doing. 

CHARLES MAX_WOOD: Well my thing is...And just to kind of drive this back home a little bit. So I've kind of evolved what I want DevChat.TV to be over the years. And ultimately what I'm looking for is I'm looking to give people the tools they need in order to excel at what they're doing. And that means both your career and your tech skills and also leadership skills, but that's a separate conversation. So at the end of the day, I mean, I feel like this is one way where people can quickly and efficiently level up in a way that's going to make a difference for them. So that's what we're after. 

DAN_SHAPPIR: Especially in times like these. 

CHARLES MAX_WOOD: Yeah. Yep. Absolutely. 

DAN_SHAPPIR: Where everybody can use any type of competitive advantage that they can get. 

CHARLES MAX_WOOD: Yep. A hundred percent. And then, yeah, we'll, we'll hand out badges and virtual certificates at the end of the challenge, letting you know, letting people know that you finished. But yeah, I'm really curious to see how things go and what you come up with at the end for the hackathon, as you kind of show us, okay, here's what I built. Here's how I use the concepts and, uh, yeah, just make the most of it. So.

KYLE_SIMPSON: I haven't run this by Charles yet, but I'm just going to debut it right here. I think we should call this a book camp. It's not a boot camp. It's a camp over a book. So let's call it a book. 

CHARLES MAX_WOOD: Yeah, we can do that. Go to devchat.tv slash go to devchat.tv slash book camp, and it'll take you right to the registration page. 

KYLE_SIMPSON: There you go. 

CHARLES MAX_WOOD: right. 

 

Early in my career, I figured out which jobs were worth working at and which ones weren't mostly by trial and error. I created a system that I use to find jobs and later contracts as a freelancer. If you're looking for a job or trying to figure out where you should go next, then check out my book, The Max Coder's Guide to Finding Your Dream Developer Job. The book walks you through figuring out what you want, vetting companies that meet your criteria, meeting that company's employees, and getting them to recommend you for a job. Don't settle for whoever has listed their job on the job board. Go out and proactively find the job you'll love. Buy the book at devchat.tv slash jobbook. That's devchat.tv slash job book. 

 

CHARLES MAX_WOOD: Thanks for coming and talking to us, Kyle. We're going to go ahead and do some picks and then we will, we will jet. Dan, do you want to start us off with picks? 

DAN_SHAPPIR: Sure thing. I actually have a few. So I'll actually start with one that's kind of a nod towards the company that I work at. So I work at Wix and just today I found this hilarious video called Wix in the Nineties. There's this guy, it was not affiliated with Wix in any way, by the way, who was just like, created a whole series of videos about various companies, how they would have presented themselves, had they existed and had they marketed their stuff in the 80s or the 90s. So he has a video called streaming Netflix movies in 1995, and Amazon in the 80s and stuff like that. So he created one for Wix, which is called Wix in the 90s, and it's just so funny, it's hilarious. I'm going to put a link to that, I immediately went and shared it all over the company. But I think anybody can appreciate how funny and amusing this video is. Basically uploading stuff over slow bot modems and getting your Wix software on a diskette and stuff like that. It's really hilarious. So that's one thing that I wanted to share. Another thing that I wanted to share, which is kind of both a plug for myself and a nod towards the topics that we were covering this talk, I wrote two blog posts. I haven't written blog posts in a long time, and then I decided to kind of get back into the game. So one of the topics that Kyle kind of mentioned towards the end were iterators and generators, which can be both synchronous and asynchronous. So I actually wrote two blog posts. One that basically shows how to build an, let's call it, iteration and algorithm library over synchronous iterators, and then a second blog post in which I enhance it for asynchronous iterators. So I enjoyed writing these blog posts, but the catalyst for writing more blog posts would be if I get a lot of views and readers. So if you found any of the stuff that we were talking about today interesting. Please go ahead into my blog post and leave comments if you feel like it. I'll definitely appreciate it and it will likely get me to write more blog posts. So those will be my picks for today. 

CHARLES MAX_WOOD: Nice. Very cool. One thing that I'm going to, or a couple things that I'm going to shout out about for my picks. First of all, I've gotten feedback from a few folks saying that they like the new design of devchat.tv. And to be perfectly honest, it was kind of a maintenance nightmare for me running it built on 11DJS because people would poorly format JSON that they submitted through pull requests. I wouldn't catch it. The site wouldn't build. Stuff would go out late. And it was a problem there. And any changes I had to make, I actually had to code. The other thing is, is that I wanted the search to work. There were a couple of other features that I wanted to make work. And it turns out that it's all automatic if you use WordPress. So I have switched back to WordPress. So I'm going to shout out and pick that. A few of the things that I picked up, if you like what we're doing there. The theme is the vlog theme off of ThemeForce. I'll put a link to that in the show notes as well. I really liked it. I'm actually using it on another website for the podcast playbook. And I'm getting that rolling. So I'm pretty excited about that as well. Anyway, it just allows me to do a lot of things. Sort of just install the plugin and then I can tweak things from there to make it work. So I'm pretty happy with that. So I'm going to shout out about the vlog theme about WordPress. I'm self-hosting, so it's on a server on DigitalOcean. 

DAN_SHAPPIR: It's interesting that you're kind of going against the grain, as it were. I mean, everybody's moving from WordPress to use one of these static site generators and you're kind of going the other way around. 

CHARLES MAX_WOOD: Yeah, it's interesting and I have some thoughts on that and I'll just kind of pontificate for about a minute because that's not what this show is about. But yeah, essentially what it boiled down to me was I'm a programmer at heart and I really like tinkering with this stuff. And that's why I wound up switching. And I had a much more complicated setup before I switched to 11d in WordPress because I had done custom development on a plugin that gave me a bunch of custom types and things like that. I found a much simpler way of doing it in WordPress. And when I switched back, it's just, it's become much, much, much more simpler. I don't have to do nearly the amount of work in order to make it work. And this is sort of the dichotomy, I guess, between an implementer and a business owner is that the less time I have to spend on some of the details like that. Because at the end of the day, what my website runs on doesn't really affect how much we make or anything like that. So yeah, moving it back to WordPress is saving me and my team a ton of time. And I don't have to pay for services like Forestry, which I really like because it's already works the way that I want it to in WordPress. So yeah, it just boils down to what you're willing to spend your time and your money on, but mostly in my case, your time. So anyway, that's why I made that change. The challenge is also going to be run out of the WordPress site. I'm using a plugin called LearnDash. And yeah, when you sign up, you immediately get the first lesson, which is, Hey, here's where you get, you know, the Slack channel. And, you know, it'll also be, here's where you get the book. Here's, you know, here's how you get help, things like that. So that was the other part of it that I really liked is that I could, you know, I could integrate all this other stuff and it would just work. So pretty happy with that. Kyle, do you have some picks for us? 

KYLE_SIMPSON: I've got a pick consistent with a theme from our conversation today, where we talked a lot about tools, whether the language is your tool or whether you're using a specific tool. I mentioned earlier when I was talking about the tool that I've been building, typo. That stands for type linter, because I think what we need is a tool that lints our types to help us make sure they're making good decisions. Just a quick moment on in the realm of tooling what linters do. Linters aren't about correctness. Linters are about opinions on what you should be doing and the way that you should be doing it to try to get your job done right now. Linters essentially come in two forms. They come in super opinionated forms where it's like, listen, you just subscribe to like, for example, standard JS and there's very few little tweaks that you can make, you're just going to subscribe to this tool and it just dumps out what you want. The other side, I mean, it dumps out only what it allows and rejects anything that it doesn't allow and you don't have any really say so. The other side is ESLint, which is like the most configurable tool I think I've ever seen. You can either flag different things or if you can't find a flag for it, you can literally just write a few lines of code and extend it through a plugin system. And so the challenge with linters is whose opinions are we going to say are the correct opinions? And that's a, that's an organizational and team-based question that you have to answer, but that's what linters are about. They're about opinions that guide the code to the best form that it can be. It's not about correctness. That's what the JavaScript engine does. It tells you, is your program correct? Your test suite tells you if it's your test suite tells you if it's correct. The JavaScript engine tells you if it's well formed. That's what those tools do. But linters tell you about opinions on making the best choices in your code. And with that, I happen to be a big fan of like ESLint and I want to make linter tools that are very, very configurable. Typal will be very configurable. But I just saw, um, last week, GitHub released what they call GitHub Super Linter and they're calling it the one linter to rule them all, which is obviously a click baity sort of title for a blog post, but essentially, it's a linter that pulls in linting from a bunch of different sources. Not all of these apply to me. I don't write Python code, so I don't need a Python linter. But I do write Markdown a lot, and it would be really cool to have a tool that could lint my Markdown or lint my HTML in addition to linting my JavaScript, lint my CSS, that sort of thing. And as long as it's configurable, I think that that tool is working for me instead of the other way around. So I'm super excited about having maybe the ability to switch to a single tool. If it's configurable enough, switch to a single tool that can work with more than just my JavaScript. Uh, so I wanted to give that a shout-out. I think that's very cool and probably very helpful to a lot of folks. 

CHARLES MAX_WOOD: Yeah. When you get it done, let us know. We'll have you come back on. 

KYLE_SIMPSON: Oh, I'm talking about GitHub super linter. We can talk about type what another time, but I think GitHub super linter is going to be really cool. Maybe someday they'll put typo and get hub suit super linter. I don't know. 

CHARLES MAX_WOOD: Hey, there we go. All right, Kyle, one more thing. If people want to connect with you, what's the best place to do it?

KYLE_SIMPSON: It is very easy to find me because everywhere online that matters, you can find get a fine G E T I F Y. Uh, and if you find a place online that doesn't have a get a fine, it's maybe not that great. No, I'm just kidding, but I'm, I'm everywhere. That's that's my Gmail, my Twitter, my GitHub everywhere. I'm gonna find. So I'm pretty easy to find that those, those various ways. 

CHARLES MAX_WOOD: Yeah. Now I'm tempted to go find a platform. You're not on like tech talk or something and be like, Oh, guess tech talks not in.

KYLE_SIMPSON: No, I'm sure there's people that troll me by registering my nickname on some random site that I've never heard of or whatever, but all the major Dev ones, I'm good. 

CHARLES MAX_WOOD: Very cool. 

KYLE_SIMPSON: On Tinder. 

CHARLES MAX_WOOD: All right, folks. Well, just a reminder, devchat.tv slash book camp code JSJabber or JavaScript Jabber. You can use either one. It'll get you the $149 deal instead of $197 deal. 147 instead of 197. And yeah, we'll go ahead and wrap up here. Thank you both for being here and for Amy who had to bow out early for being here. And until next time folks, Max out. 

DAN_SHAPPIR: Bye.

 

 Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C A C H E F L Y dot com to learn more.