Today we talk with Matt Pocock, who comes from Oxfordshire, England.  As a big fan of TypeScript and maintainer of the Xstate library, we discuss the benefits and downsides of TypeScript.  As the discussion gets a bit heated, we debate the true value of TypeScript, and where it holds value to the programming community.

CHARLES MAX_WOOD: Hey everybody, welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEILL: Yo, yo, yo. Coming at you live from the deep dark purple dungeon. 

CHARLES MAX_WOOD: We also have Steve Edwards. 

STEVE_EDWARDS: Hello from a beautiful and sunny Portland, which is not something that happens a lot, especially this spring. 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. And this week we have a special guest and that is Matt Pocock. Did I say that right? 

MATT_POCOCK: Yeah, you said it good. You said it pretty American. I'm not going to lie. Matt Pocock. I'll take it. I'm coming live from rainy, miserable Oxfordshire in England. 

STEVE_EDWARDS: So it would be the correct pronunciation. We were like, Matt, Paul, cock or a cock. 

MATT_POCOCK: Yes, exactly. Yeah. Okay. Hey, I was closer. Okay. We're going to do another Matt. Pocahontas, you know, Matt, Bocahontas. I'll take it. Yeah. 

CHARLES MAX_WOOD: I don't know. My great grandparents immigrated from England. So anyway, but yeah, let's, let's go ahead and start talking about TypeScript now. Why don't you introduce yourself and kind of talk about a little bit about what you're doing with TypeScript and then we can dive in and fight about, I mean, discuss when and where to use TypeScript. 

MATT_POCOCK: Sounds good. Yep. 

 
Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast and you can actually hear a little bit more about my story, about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. What I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with DevChat.tv and I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want. So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. resources in there and we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com if you sign up before my birthday, that's December 14th, if you sign up before my birthday you can get 50% off the lifetime of your subscription. Once again that's topendevs.com. 

 
MATT_POCOCK: So my background is that I'm a maintainer on a library called XState and part of kind of the team that maintains it and that kind of thing and XState is one of the most complicated time script libraries out there. And I've been working on it for about a year, year and a bit. And based on that and based on my kind of learnings with TypeScript, I'm releasing an advanced TypeScript course, essentially. And my history of TypeScript is essentially, it feels like TypeScript has just saved my life a bunch of different times on a bunch of different projects, and especially there's one I've got in my mind in particular that was just running behind and behind and behind, and we were using JavaScript and it was in a React application and it just was not going well. We put TypeScript in, we immediately kind of almost doubled our velocity pretty much just by reducing a whole class of bugs. And it feels like to me, all the reasons that you think about for TypeScript, like I'm an advocate for those, you know, like it's just an amazing, amazing piece of kit. And I think that it should be in every developer's toolkit or every JavaScript developer's toolkit, definitely. 

CHARLES MAX_WOOD: Very cool. Now I know that not everybody feels this way, but I'm curious. You said that it's basically saved your life on some of these projects. And I'm curious, you know, what is it that has driven that? 

MATT_POCOCK: A lot of it is kind of data related, you know, when you have data coming in from like an external source. We were like a front end team, just doing the front end things, building out this sort of front end. And we had these very, very complex data structures coming in from outside that we weren't sort of like, we had these data contracts with a backend, but when they were through our application and sort of like being drilled down through props and things, it was really sort of easy to make a mistake. And the data contracts kept changing as well. So it was kind of like, okay, yeah, that's a Boolean. That's kind of got a, sorry, now that's now a string actually. Oh, sorry, no, that's an uppercase P, not a lowercase P. And actually having that kind of rolling through your system all the time is not good. And it meant that we actually got a lot of benefit out of the refactors that TypeScript can give you. And so when we adopted TypeScript, suddenly when they said, okay, that's like a lowercase U instead of an uppercase U. We suddenly got all these red lines throughout our system and we were just able to go bang, bang, bang, bang, bang, bang, bang, bang, bang, sometimes even automatically refactor them. It felt super duper good and it just meant that we some tasks that just took hours, you know, testing things, checking for runtime errors could be checked at the type level. And that was huge for us. The data contracts from the backend kept changing. And what that meant was every time they would say, oh, that's actually a lowercase P, not an uppercase P, we would have to go through and kind of like check against the runtime, make sure that nothing had broken. Whereas when we adopted TypeScript, what that meant was we would just get all these squiggly red lines wherever the data contract had changed. And it meant that we didn't even have to test in the runtime anymore. We knew that the types would be okay. And so it just saved us a ton of time. 

AJ_O’NEILL: So I am all for JS doc. I'm a hundred percent in. Oh, by the way, for anybody that doesn't know, I am the resident TypeScript-phobe, skeptic, et cetera. So that's why my position starts out out of the gate that way with that tone is. I hate TypeScript, but I, I love exactly what you're talking about with JS doc. I want JS doc in every single project. I don't want any of the bulk of TypeScript. I don't want any of the complexity of it. I hate what it's doing to the JavaScript community and the complexity of, of code patterns that it is incentivizing, but I love exactly what you're typing talking about, which is getting type hinting throughout the code base so that if you change something, it, it knows, Hey, look, this. This changed, this is different. And so I'm a big advocate of JS doc. I've got a starter repo for anybody that wants to get started with JS doc and have those benefits that I will share in the picks today as well. 

MATT_POCOCK: And so we're talking about the same thing. JS doc is the comments syntax that lets you sort of declare the input and output functions, right? 

AJ_O’NEILL: Yeah, yeah, yeah. So JS doc, this is the problem as I see it is that TypeScript was created by Microsoft as a scripting language for C sharp to repurpose C Sharp developers to be able to become web developers more easily. And they put in an okay effort at making it somewhat JavaScripty, but it's pretty obvious that the primary goal is to have a scripting language for C Sharp that works on the web. And that's even basically what it says on the Wikipedia page. And the problem with JS doc is that JS doc is a port of Java doc. And this is the problem in the community that I said a hundred times. People have heard me say it before. I just fast forward now. But we've never really had a strong community around JavaScript ever. There was a blink of an eye when there was Douglas Crockford and a few other people that really cared about learning and teaching JavaScript as a language. Then other than that, it's always been, here's how to do Java patterns in JavaScript. Here's how to do C-sharp patterns in JavaScript. Here's how to do Ruby patterns in JavaScript. We've had CoffeeScript and da-da-da-da-da-da. My one big complaint with JS doc is that similar to the complaint with TypeScript, is that it's not made for JavaScript for a different language and that very much shows because some of the patterns that are the most common patterns that you would want to use as a JavaScript native are not intuitive in JS doc. So for example, if you want to define an object that has functions, you actually have to type def them as a callback, which doesn't intuitively make sense because you're not actually using a callback. It's just a normal function on an object. So there's some stuff like that where I find that JS Doc is a little obtuse in terms of it's not designed for JavaScript developers, it's designed for Java developers, but it does allow you to get exactly what you're talking about with minimal overhead in terms of having to implement complex design patterns if you so choose to avoid them. 

MATT_POCOCK: So let me answer that, which is my personal take on JS Doc is I don't see a strong use case for it, unless you're... No, I don't see a strong use case for it, basically. Unless I guess you're focused on some sort of old JavaScript application that you want to add some type hinting and autocomplete to it. So there are some useful cases for when you're in config files in JS. This is a potential item to use in SQL. 

AJ_O’NEILL: If you're just saying anything that's JavaScript is old JavaScript, then yes, if you're saying that old means not TypeScript, yes. If you're writing JavaScript, JS doc is the way to go. If you're not writing JavaScript, I mean, unless you know some alternative.

MATT_POCOCK: But if you're saying that what we're talking about is kind of like IDE autocomplete, we're talking about type hinting as you're talking about. Like both of these are methods for allowing your IDE to help you more when you're building JavaScript, right? So JS doc gives you some auto complete, gives you some type safety, that sort of thing. Sounds right. 

AJ_O’NEILL: Yeah, I mean, it more or less, I mean, you're going to use, you're going to use the TypeScript checker when you use JS doc. So you it is it is the alternate syntax for TypeScript in essence. 

MATT_POCOCK: And what you're saying is that the TypeScript syntax itself is a little bit too not JavaScripty for you, basically. Like you're adding some primitives, which kind of what you would say is they don't belong in JavaScript. Keep that out of my JavaScript. 

AJ_O’NEILL: Yeah. So the whole idea of having hierarchies, classes, doing try catch over async stuff rather than using dot catch, which is the JavaScript way, there's just a lot of these patterns that are much more complex and kind of lend themselves to not understanding JavaScript. That's kind of my problem with it, I guess, is that JavaScript is a very simple language that you could learn in a week. And instead, because people always want it to map to something else, they, you know, in essence, JavaScript has failed as a language. It has never gained adoption because people always go to, how do we make this complex? They don't look to how can we use just what the language offers. And so you end up with, you know, people started abusing prototypes, which it's in the name. It is prototype. It is for polyfilling, you know, that it's funny that we had to create a new term polyfill to mean what the language already had natively, which is a prototype. You know, polyfill is just when you add something to the language that isn't ready yet. It's not fully baked in your prototyping at your poly filling it, right. And so people started abusing all these features. So we're going to try to make classes and we're going to try to make inheritance and we're going to and bringing in all these things and TypeScript just embraces that. So let's say let's use the maximum complexity of JavaScript and then let's let's 10x it. So if you look at, you know, how do you define a JavaScript object, just JSON, maybe JSON with some functions where now it's a more true JavaScript object versus trying to define hierarchies and put in all these various weird patterns. It's just, I find it so much nicer to just have JS doc and say, okay, if I want this, this is allowed to be either this type or this type. I just use the enumerate that as such in the JS doc. And I get all the type hinting and I'm not forced into complex patterns or, yeah, things that are antithetical to the JavaScript language itself. 

MATT_POCOCK: So the idea of there being sort of patterns that TypeScript forces you into, I think is a complex question. But I think that if you just took your JavaScript project, any JavaScript project, you can put that in TypeScript without needing to implement any further patterns. So the idea that there are these kind of like things you must do in order to do TypeScript, now you don't really need to, right? You can just cast things as any, you can have blah, blah, blah, blah, blah. You can add the annotations into your functions to make it work, you know? So you don't necessarily need to embrace classes or inheritance or anything like that. And that classes thing, those are in JavaScript before they're in TypeScript. 

AJ_O’NEILL: And... 

MATT_POCOCK: TypeScript doesn't wanna implement classes. So TypeScript has this concept called an enum, right? 

AJ_O’NEILL: Yeah. So an enum is like the classic C-sharp thing, right? The TypeScript team now, I don't think that... 

AJ_O’NEILL: Enums mean different things in different languages. So for my sake and for the sake of our listeners, define what you mean by enum, because that, in every language, it means something different. 

MATT_POCOCK: So in JavaScript, or rather now in Timescript, you add a, it's basically Timescript has added this keyword called enum. What an enum is, is basically a set of unique values that Timescript can either map to, each one maps to a string, or map to a number. So you could have like enum apples, or enum fruit, rather, one of which is I can't think of another fruit. 

AJ_O’NEILL: OK, so you're talking about data enums, not type enums. 

MATT_POCOCK: So enums in TypeScript actually compile down to JavaScript. And this is kind of like a unique thing in TypeScript, which is they really, I think, regret having added the enum. Because the enum itself is like a new thing that TypeScript has added to JavaScript. And I don't think they would do that today. So I don't think if someone proposed an enum syntax, I don't think they would go for it today because the team itself has calibrated itself more to, okay, let's support what you can do in JavaScript as opposed to forcing new patterns on you, which I think you would agree is quite a good idea. 

AJ_O’NEILL: Yeah, yeah. I just, and I agree with you. Yes. I don't know why you would use TypeScript if you didn't want to use all of the complexity because you could just use JavaScript with JS doc and then you don't have to do any transpiling means that you don't have to have source maps, there's fewer things that you have to learn, less cognitive load. But I think that my main gripe with TypeScript is just, I mean, it's just my general gripe with the JavaScript community, which is refusing to learn JavaScript and instead trying to learn a different language and bring that language as a layer on top of JavaScript. So the patterns that you use in C sharp, yes, JavaScript is a very versatile language and you can implement almost any pattern in JavaScript. It's beautiful and deadly at the same time. But why would you want to, why would you want to bring in all of that complexity and that baggage into such a, a beautiful little flower of a language? 

MATT_POCOCK: How did you feel when ES6 came out? 

AJ_O’NEILL: Well, it depends. It depends on what you're talking about. If it was things that were actually part of JavaScript that were just enhancements to the standard library. I'm a big believer in you want a small language that's the smallest language that can do what it needs to do with the most complete and robust standard library that you can stomach. So Go is my example of pretty much the perfect language. Obviously there's a lot of flaws in it. Not every decision that they made was right. They've regretted some. There are things that are stuck in the language because they made it into the language at V1.0 and they have a commitment to not fixing those problems. But in terms of, do you want a language that has very few keywords, very few patterns, very few things to learn? And then you want a robust standard library that gives you the ability to do the things that you're going to need to do. So manipulate strings, manipulate time, just the things that no matter who you are, no matter what you're working in, as long as you're doing business logic, as opposed to say you're only stuck in the world of computer science, you know, as long as you're doing business logic, these are the things that you're going to need. So from the perspective of ES6 providing things that already worked in browsers anyway and that enhanced the things that people needed to do that were just creating conflict and confusion by having various incompatible ways of doing them outside of the specification. I think that most of that is awesome. And I think that when you put in a committee in any place, whether it's in government, whether it's in school, whether it's in a programming language, anytime you have a committee, the problem with a committee is it doesn't expire. That there's no goal of, okay, accomplish this, and once X is accomplished, you've done your job, now you're fired. That would be a terrible reward. And so what happens naturally in any committee is that the scope always expands, expands, expands, expands, expands, because you either have to continue to expand the scope and bring in more complexity and more responsibility, or you have to fire people. Those are your two options. And like I said, firing people for doing a good job just doesn't feel like a great reward. 

MATT_POCOCK: I think the idea that governance, like, Because what you're talking about is essentially governance, right? Like it's, it's people looking after and stewarding a language. It's tricky with a language because you can't, especially one like JavaScript is that there's stuff that we wish that we could change in JavaScript's past, you know, like should type of null equal an object? No, you know, but I guess there's a sense that things should improve over time. And what I'm kind of getting at is that like, if you think about ES6 and the arrow function syntax, for instance, that's new syntax, right? Yeah. Okay. And that's kind of. Right, right, right. So is no progress allowed? You know, like, I see TypeScript as, and by the way, let's bring something new into this conversation, which I saw at JSConf, which was Gil Tayeh or something. I can't remember his last name. So sorry. But he brought together a, wait, did I get his last name right? 

CHARLES MAX_WOOD: I think it was Tayeh. Yeah, Tayeh. 

MATT_POCOCK: Yeah, he spoke about the basically the type annotations in JavaScript proposal, which is a proposal for TC39 that would basically bring in some TypeScript annotations into JavaScript itself. So instead of writing JS doc, you could basically just add these little sort of annotations kind of like, you know, imagine that you have a function with an argument, you could add a little annotation to the right of the argument and it would exactly do what you're doing right now. Instead of using JS doc, you could just run TSC over your JavaScript and it would check it. I'm intrigued by what you think of that. 

AJ_O’NEILL: That's not quite...what it is. So if you stand for nothing, you fall for anything. And I think this is where TypeScript does well. TypeScript says, we are C sharp for the browser. We're bringing C sharp developers to the web. Right. That you're shaking your head. No, 

MATT_POCOCK: I'm shaking my head. Yeah. Yeah. I'm like, you said that about 10 minutes ago and I thought, when am I going to get around to refuting that? It's going to be some 

AJ_O’NEILL: refuted either right here, right after this, but, and, but TypeScript gives people something to rally around TypeScript, at the very least, TypeScript takes a strong position. The problem with the JavaScript committee is that they're, and this was one of the response tweets that I loved to part of that announcement, was that why is it JavaScript's job to be everyone else's favorite language? Why is it JavaScript's job to make every other language feel better about itself? JavaScript, because, and I believe this is just because of the committee nature, it has no position. It has no goal. It has no nothing that it stands for that you can say JavaScript is a great language for blank. The only thing that JavaScript is a great language for is for building transpilable languages in its current trajectory. If we're talking about the real JavaScript that you can write programs in, I think that that's a great language. But when you're talking about just all of these, the features that just stack more and more and more and more, it's so completely inconsistent. Every new feature contradicts a previous feature. So for example, I think the best example is there's all this idea of, oh, we want functional programming, functional programming, functional programming. So the new religion, everybody's got to join in. And then they release the iterators, which are completely useless for almost every situation. I think there's a couple of cases where they'd make sense on the back end and node. They make absolutely zero sense on the front end for any of the things that they've been standardized for, such as query parameters, stuff like that. And then you can't use the iterators with the functional array operators. So iterators don't work with map. You have to do for of on an iterator. So it's those kinds of things where it's almost to me from the outside, it looks as though you basically have people that are bickering with each other saying, okay, well, fine, we'll accept your proposal, but we're not going to make it compatible with the existing arrays because that's what, you know, would make sense and we want to cripple your, your feature. It seems like 

MATT_POCOCK: I would take a more I would take a more generous view than that. 

AJ_O’NEILL: I think sure. 

MATT_POCOCK: And by the way, and this, this is like, we we're straying into like committee and JavaScript here, but I don't see that how that's related to TypeScript at all, actually, because TypeScript is just like, so TypeScript is, is now people saying, okay, we want to add types to JavaScript. We think we have a way to do it. Yeah. 

AJ_O’NEILL: I don't, I don't add any types to JavaScript.

MATT_POCOCK: Yes, it is. 

AJ_O’NEILL: Doesn't even understand JavaScript's native types. It is C sharp first and JavaScript second. 

MATT_POCOCK: I absolutely do not see that at all. So this so the idea of this enum, right? Let's go back to that because that is adding something external to JavaScript. And what that's doing is it's saying, okay, we think we can do something better than JavaScript. And what I'm saying now is that they wouldn't do that anymore. Enum would not get in the language today. And that means that they're focusing in on the thing that TypeScript is really, really good at is inference, right? Inference. So you can say, okay, let's say you have like a variable which you don't know the type of, so you would say it's unknown. Then what you can do is you can say type of thing equals string, for instance. And if that's true, then we enter a new closure in the if statement. Inside that closure, that thing is gonna be typed as a string. What that means is that TypeScript understands JavaScript's type system incredibly well, and it's doing really, really deep, interesting inference and as it goes on, it gets better over time at that. 

AJ_O’NEILL: It is absolutely the best tool we have. 

MATT_POCOCK: Yeah. What better than JS doc? 

AJ_O’NEILL: Well, so JS doc doesn't actually provide the tools for that. JS doc provides the syntax for that. I mean, that's like saying JavaScript, the syntax versus V8, the engine. Right. So without TSC, we can't get any real benefit out of JS doc, at least as far as I'm aware, I don't think that the tooling. No one has ever developed good tooling for JavaScript and TSC because I use it with JavaScript. I see all the failings. I see all the places where it's like, wait a minute. I just returned here. You know that there's no way that this object can be in this state because I just did an if and then a return. And so to me it's baffling because in other languages that have this built in from the beginning, now granted they have it built in from the beginning, but in other languages like go the tooling around these types of things, what you're talking about with the inferences and knowing what state an object is in is literally 100%. The only other, the only times I've ever come across a case where I reported a bug or thought I needed to report a bug, it turns out that I was wrong. The tool was correct and I was wrong. With TSC, I'm always right. I mean, obviously it is helping me fix problems, but when I get to something that looks really weird and I'm thinking, wait a minute, no, I did this right, and I double check it, I'm right.

MATT_POCOCK: You are right about that. It can't give you the guarantees that something like Rust can give you or like, because Rust has different constraints or Go has different constraints, you know, but you're right. It is the best tool we have. And like that feeling that it feels to me like TypeScript right now really understands JavaScript and it gets it and it understands what it's trying to do. And it doesn't impose any, any constraints on what you want to build. You know, you can build literally anything. You can build it. So you can build everything you want to build with JavaScript with TypeScript. Right? 

AJ_O’NEILL: Yes. Yes. TypeScript is a well, okay. You have to turn off TypeScript in order to say that there are some really tricky situations that you can get into, which I will admit are usually an indicator of a bad design pattern. So you may have added something as an afterthought and now what was classifiable as a record type now is kind of a hodgepodge of a record type and a, um, an object type, and then trying to get a union on that may not work out well. And then if you're trying to use TypeScript with JavaScript, so objection would be, are you familiar with objection.js? 

MATT_POCOCK: No. 

AJ_O’NEILL: Okay, that would be my star shining example of everything that can go wrong with JavaScript TypeScript integration. 

MATT_POCOCK: Okay, tell me how, how did it happen? Tell me the story. 

AJ_O’NEILL: I don't really know the story of it, but it's a lot of metaprogramming. It's an ORM, and so it's just metaprogramming out the wazoo. And A lot of some of the features they have are based on draft spec JavaScript that I'm not sure it's actually landed yet. So if you're following that it's based on V8, right? So whatever is implemented in V8, you're supposed to be able to use that syntax. So some of what objection has documented in the first place isn't even JavaScript. It's a made up language that may or may not ever exist, but happens to be implemented in V8 according to some draft spec that ostensibly will one day become JavaScript. So there is that problem, first of all, is you're dealing with something where it's not necessarily TypeScript's fault that's objection is choosing to be, I hesitate ahead of the curve, because I feel like that's too much of a positive affirmation to what they're doing. And I think that unless something's been around for two years, you shouldn't use it except for prototyping. 

MATT_POCOCK: Should we say they're so ahead of the curve, they're on the dark side of the moon or something? 

AJ_O’NEILL: Sure, yeah. And so what ends up happening is because it's all this meta programming with the ORM, If I believe, and I could be mistaken, I believe that if you used it with TypeScript, it would work out. But if you try to use objection in JavaScript with the TypeScript checker, it just goes bonkers. It cannot figure out any of the types. It thinks that it's just too, it's too many layers of inheritance and meta programming where you're, you're extending classes with features that don't exist in the language and, and, and if you look at the TypeScript definition for it, it is, it is so Incredibly just I cannot make heads or tails looking at the typescript definition what it's supposed to mean But again that this is a problem with metaprogramming in general. 

MATT_POCOCK: Yeah, let's take that point Which is that some type definitions are look like an alien language if what you're used to is is JavaScript, right? So as soon as you get into like generics and you get into some of the more kind of crazy Type scripts for instance keywords, you know, like extends and infer and in there in all these weird positions closing sort of like triangle brackets as well in these funky places. It can just look bamboozling and terrifying. And yeah, you're right. It is meta programming. It's essentially trying to grab the types and sort of infer them from different places and then drive JavaScript's inference from TypeScript. Like this was a lot of what I had to do at XState as well was kind of like we have, we try to do as much sort of inference as possible to help kind of people use our tool. We want the TypeScript experience to be really, really good. What that means is that we have to really bend over backwards and go deep into the language. And my colleague, Andres Drake on Twitter, who you should definitely follow if you're into TypeScript stuff, he was the one really sort of diving deep and often actually reporting bugs in TypeScript based on what we found too. So, yeah, we've been down that rabbit hole and like there are features in TypeScript that I think probably you would say like this is evil, like get it away from me or I don't know, based on what you've said so far kind of thing. And I think those, what this is the result of needing to, cause JavaScript essentially doesn't have a type system and often just like lets itself go, right? It's just hyper, hyper loose. So if you return something from a function, you can do whatever you bloody well want with it. 

AJ_O’NEILL: Yeah, it does have the disadvantage of being both dynamically typed and loosely typed, which I think is absolutely disastrous. If there's something that strict mode should have fixed or that we should have some sort of flag for, that would be awesome if it were native in the language, it would be to have strict inferred typing rather than dynamic loose typing. 

MATT_POCOCK: Yeah, and that looseness is what TypeScript is trying to patch on top of basically. And again, it's doing a pretty good job. Like a lot of work is going in in the language at that level, you know, to improve it and to make sure the edge cases are sort of fixed. And so every minor version, there's usually some new thing that you can use if you're into that stuff. But to be honest, most people and most TypeScript users are not going to be dealing with generics really, like maybe a couple of sort of basic stuff. But they're not going to be doing the really complicated TypeScript work. That's kind of the whole, like the work of library people, essentially, the people who are building the libraries and printing out those or compiling those horrible type definitions that you were talking about. And that is an interesting divide there. You've got like the app users on one side and then the library users on one side. And you kind of want them to be able to contribute to each other, you know, for the app user to contribute to the libraries. But I do worry sometimes that it's. 

AJ_O’NEILL: Go ahead. Finish the sentence. 

MATT_POCOCK: Yeah, I do. I worry sometimes that the syntax puts people off, uh, even though the primitives are relatively simple when you know the syntax. 

 
Hi, this is Charles Maxwood from top end devs. And lately I've been coaching some people on starting some podcasts and in some cases just taking their career to the next level, you know, whether you're beginner going to intermediate and immediate going to advanced whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go and figure out what the next steps are. And then from there we can figure out how to get you to the place you want to go. So once again, that's topendevs.com slash coaching. 

 
AJ_O’NEILL: Like I said, I'm a fan of go. I also am a fan of Rust. I think Rust is a bit too complicated. I think that especially with their borrow checker is the most novel and complex thing that people have not encountered before. And I think that trying to mimic languages like C sharp in terms of their complex hierarchies and it simplifies it down quite a bit, but it's still quite complex. But I like the strictness of Rust and I like the strictness of Go. Not necessarily because of the type systems. I like, I like type inference. I think that type inference is good enough. And you basically get that with Go. It's compiled, but it doesn't feel like a compiled language. It feels like a scripting language, but with JavaScript, again, I think a big part of the problem is if you stand for nothing, you fall for anything. And trying to be so loosey goosey just lends itself to just badness. What I want is something that restricts and this is one of the things in some ways, TypeScript extends the loosey gooseyness because it gives you. So where's TypeScript, the objects are loosey goosey. TypeScript now gives you design patterns that are loosey goosey. So now in addition, JavaScript already allows you to create too many design patterns and then TypeScript gives you even more, and I want fewer design patterns, not more design patterns. I want less mental burden. It's not like in the way of, in the world of programming, you actually need these design patterns. You don't actually need inheritance. It's not actually more useful than just adding properties onto objects. In terms of if you write two programs, you can come out with the exact same output with the exact same performance other than the randomness that's introduced by the JIT compiler of how it decides to do something. But you can get the same inference, the same performance, the same everything out of two similar design patterns where one is really complex and requires a computer science degree to understand and the other one somebody can teach you in about five minutes, right? 

MATT_POCOCK: But I don't think TypeScript adds any options that JavaScript doesn't have, you know? I don't see the argument that there are design patterns that you can do in TypeScript that you can't do in JavaScript, apart from literally that enum, like that's the only one. 

AJ_O’NEILL: Well, you were talking about generics before. Technically, yes. 

MATT_POCOCK: But generics are only at the type level, right? Like they're not runtime code. 

AJ_O’NEILL: Well, but that's the thing, is that you're generating more complex code and you're just generating more complexity, you're adding more layers of things that need to be understood. When you think of how complex the web development is becoming, how many layers you have to understand. I've sung this song, but find me a developer who knows how to use CSS. They're pretty much non-existent. Find me a developer who knows how to use JavaScript. They're pretty much non-existent. Find me a developer who knows how HTTP headers work. They're going to be in their fourth or fifth year of development before they understand. Right. And so we have all these things that are the primitives that everything else is built on. And all of our focus has become on these moonshots. We just, you know, we're trying to reach to the most complex patterns to kind of prove our cleverness, prove how cool we are, prove how much we know, prove how nifty we can be. And I honestly believe if we took a step back and said, hey, why don't we just take what we've learned, take just the best parts and focus on learning the simplest things that are the closest to where the work happens so that we understand how the web works from a fundamental, we're sending text messages back and forth to each other. We understand how objects work, iterating over array works, where people aren't always reaching for low dash because they don't know that there's a for each in JavaScript. We're so, so this is, yeah, this is not about TypeScript specifically. I'm just saying that TypeScript is another, it's another layer of complexity that gives credibility to this, let's do everything possible ever at the expense of learning basic things that when you when it turns out you have to debug stuff you need to know anyway. 

MATT_POCOCK: So it's raising the floor, right? 

AJ_O’NEILL: That's correct. 

MATT_POCOCK: It does raise the floor, right? 

AJ_O’NEILL: Yes. 

MATT_POCOCK: You know, you you have a yeah, you have a new sort of level that you need to reach in order to do even the most basic stuff. 

AJ_O’NEILL: And people are struggling. I mean, look at web dev Twitter just or don't or don't look at it. 

MATT_POCOCK: I'd say don't. Yeah, don't. Correct. 

AJ_O’NEILL: But people are so incredibly confused. And, but then again, then again, I mean, to my own point against myself, TypeScript at least gives people something to stand for. You're gonna find better tutorials on TypeScript potentially than tutorials on JavaScript because at least in TypeScript, people are taking a stand and picking something to strive for. 

MATT_POCOCK: Yeah. So yeah, it's tough, right? Because if you're a developer just sort of messing about on your own, you want the floor to be low. You want the floor to be as low as possible. You want the entry to be easy.

AJ_O’NEILL: Or if you have to work with people. 

MATT_POCOCK: Well, OK. But of course, it is easy, right? You can just plug in some JavaScript. You can just have a HTML file, and you can do the thing. But if you're wanting to build a product of decent quality, you kind of want the floor to be a little bit higher, right? You want the floor to be, and this is not talking like above reasonable expectations. And it's not like TypeScript is something that you don't necessarily need to hire a dev to be able to do TypeScript. You can teach them TypeScript on the job. Like, when you see a few annotations, you understand what's going on. You can spend like 20 minutes, like just picking through the first bits of the TypeScript handbook, and you can sort of pick it up as you go. Like, there are going to be, OK, there are some bits about TypeScript that are pretty intimidating, especially the errors. So I've actually gone through and created a VS Code extension, which is the TypeScript error translator, if you're interested in that. 

AJ_O’NEILL: So are you talking about errors from TSC? Are you talking about? trying to get errors to have the properties you want when you throw an error. 

MATT_POCOCK: Oh, no, no, no, no. So, time script TSC errors, basically. So, things that pop up in VS code, for instance, if you're using that. And the red lines and decoding what they mean. That can be terrifying. But if you want that flaw to be sort of high, then you know you're gonna build pretty good products. And it's not like it's raising the flaw for no reason. It raises the flaw, and in my experience, it also raises the quality of the product. 

AJ_O’NEILL: So, but my, I mean, I guess my argument is just why not raise the floor with JS doc so you're not introducing any extra complexity. And by JS doc, I use, I think about maybe less than 10 features of JS doc. And all the code that I write can be described with about 10 of its annotations. So I think that JS doc is unwieldily huge and describes way too much stuff because it's trying to be Java doc. 

MATT_POCOCK: Let me make the argument against JS doc then. 

AJ_O’NEILL: Okay. 

MATT_POCOCK: So JS doc is like TypeScript, but way too verbose. It's essentially just like, okay, why would you take, you know, a hundred characters to write out something that can be written in five? You've got all those kinds of TypeScript comments in taxes. You've got this, you've got that. And like, it's just- 

AJ_O’NEILL: Well, but you get the documentation built in as well. 

MATTl: Sure, you can just add a comment, you know, like the- 

AJ_O’NEILL: Well, yeah, but when you JS doc build, you get the documentation that has those comments and everything's in there quite nice and-

MATT_POCOCK: And again, if you're using it for that, then that's wonderful. 

AJ_O’NEILL: If you don't know how to hit the tab key to autocomplete, you need to go back to the fundamentals of day one of using your editor, right? I mean, if you're worried about, oh, I have to type five letters, just hit the tab key. You don't have to type all five letters. 

MATT_POCOCK: Sure, sure, sure, sure. But then, of course, you've got GitHub Copilot, which can auto-generate your type annotations for you. You know, I mean, like, sure, like, but it's the verbosity and the fact that it's not got the best ID support as well. Like it's, you know, it feels like TypeScript is always going to give you a more complete experience than JS Doc. Although I mean, JS Doc again, like if it's, it's about that lowered floor, right? Like if you, I guess it's a way to raise the floor slowly. I'm just not sure what the 

AJ_O’NEILL: Well, I don't think you raise the floor at all. Because with, if you're just using JS Doc, you are teaching and learning JavaScript, which is the fundamental layer that you really need to know regardless. Because no matter what you're using on top of JavaScript, if you don't understand JavaScript, then you are going to encounter lots of situations where debugging is needlessly complicated because you don't understand the fundamental first principles of what you're building with. And- 

MATT_POCOCK: I think we can allow people to learn TypeScript, but also learn JavaScript while they're doing it. 

AJ_O’NEILL: How do you know what's TypeScript and what's JavaScript then? 

MATT_POCOCK: Well, you look at the JavaScript docs, so you look at the TypeScript docs. TypeScript, as it says, is just a superset on top of it. You're right, like, you need to understand. 

AJ_O’NEILL: Just a superset. So when you create a supersubset of something, that is just fancy parlance for a completely different language. 

MATT_POCOCK: Yeah, of course it's a different language, 

AJ_O’NEILL: but it's- It's not just a superset. It's not like, oh, here's JavaScript with a, you know, just one or two things added on top for nicety. It is a completely different language that was designed by the designer of C Sharp to be this Microsoft scripting language.

MATT_POCOCK: So that is not the goal of TypeScript. Like if you never say that again, I'll be about 10 times happier. Cause it just does not ring true for me at all. I don't get it. 

AJ_O’NEILL: Tell me why this is wrong. I mean, look at the Wikipedia page for TypeScript. It is. 

MATT_POCOCK: Well, look at the TypeScript documentation, I would say. Because the TypeScript documentation tells you what it is, I suppose the Wikipedia people. 

STEVE_EDWARDS: I believe the correct acronym for that is RTFM. Oh, no, no. 

MATT_POCOCK: That sounds correct. 

AJ_O’NEILL: Well, they can record the documentation. I mean, it's always.But it's 

MATT_POCOCK: what I'm saying

AJ_O’NEILL:  is whatever type script developers as just a superset. 

MATT_POCOCK: Okay, but what I'm saying is whatever typescript was, it is different now, right? That's my point. It's evolving to understand the needs of its core people, right? It is becoming more JavaScript. So whatever it became at the start or whatever it was at the start, doesn't matter. 

AJ_O’NEILL: Well, it does. Sure, okay. We'll go with it. But in terms of you're going to get the exact same support with JS doc that you would get with TypeScript for if you're using the simple subset of the language, because the way that you get support in your editor for JS doc is by installing TSC. TSC is what reads JS doc and provides you with the autocomplete and what gives you the type inference. TSC is what makes JS doc at all beneficial. So you you know, from that perspective, I am incredibly grateful that TSC exists. I wish that it had been built in a way that was JavaScript first, but that doesn't matter from the sense that it is the best tool that we have. And it's pretty darn good. And if you just eliminate the types of cases that cause TSC to get fouled up on JavaScript, you're probably in general writing better code anyway, because you're choosing fewer design patterns and design patterns that are easier to read and understand and you're doing less metaprogramming. And the older I get, the more that I want dynamic code generation and not dynamic runtime, metaprogramming. 

MATT_POCOCK: I'd love to know kind of to reframe the discussion a bit. If JS doc didn't exist, like if there was no sort of in between option, and it was only JavaScript on the floor or time scripts in the middle, let's say, what would your opinion be like, okay, you've got this lovely sort of like you, it probably feels like a lot safer and like you're doing type programming with, with JS doc, right? You get a lot more safety. How, how far do you want to go with that? Would you say only ever JavaScript or do you want to replicate that feeling with a bit more complexity with time script? 

AJ_O’NEILL: I just don't like transpiling period. I don't like the slowness. I don't like the complexity, the source maps. If I'm going to be writing in a language, you know, if I, if I have to use something that is going to if I have to add a layer that's that's at that core fundamental level, you know, we're not talking about a library abstraction where you can use composition patterns. We're talking about your modifying the intrinsic first principles. I don't want to do that. I, I don't like having to hold so much in my head. For as smart as I am, I'm pretty dumb and I get dumber as I get older because I'm not as smart as I was when I was 25 and I can tell, right? I don't like having so many things to have in working memory. And so for me, I would just want to write even simpler JavaScript than I already do now so that I'm even less likely to make mistakes because I don't want to be adding compilation layers. I mean, I love having, I love composition. I think composition is great. And I think that in the software engineering community, composition over inheritance is something that's pretty well understood rather than rather than melding things together to get potentially unexpected or non-intuitive results, which is what the inheritance pattern is kind of what you're doing when you're applying TypeScript on top of JavaScript in ways you're having something that inherits something else and then you've got all these odd weird edges to it. Whereas composition, if I can just put a library on top or something like that, that pattern is what I personally prefer. And I know that, you know, it's a split because there are people, this is like left wing versus right wing, except I don't think there's any political affiliation with these ideologies, but either you want something that's like C plus plus where you're constantly implementing every possible pattern. Any computer scientists could ever dream up, or you're on the side of things like go and Zig and Python where it's let there be one way and let it be done well. And I'm just, I'm just a hundred percent in the camp of let's try to find the smallest possible language that we can have that fulfills the needs that we have so that our mental load can be less, readability can be higher. And yeah, so if it was, if I didn't, I mean, I didn't have JS doc before, I didn't know how to use TSC before. So TSC is a huge boon to me writing JavaScript. But if I didn't have TSC for JavaScript, then I would not be writing TypeScript or Elm or something like that. I would still be writing JavaScript. I would just have a harder time during some of these refactor operations, which, oh my, I just can't express enough how just wonderful it is to have that refactoring process go well. 

MATT_POCOCK: Absolutely. It's interesting though, because it does feel like that's a stylistic choice on your part. And my choice would be kind of basically the opposite, which is I feel best when I have, and especially probably this is because I learned JavaScript more recently than you likely, because I'm relatively new to to programming in general. I was kind of like, I was a singing teacher weirdly for about sort of six years before I became a developer. And I've sort of like, I came up in these kind of integrated environments, you know, like in sort of Webpack and Create React app and like, and now Veets and all of these cool things that basically just give you everything out of the box. Right? So for me, it's sort of less important where the edges are and what I prioritize instead is the feeling of safety and the feeling like my tools have got me, like I just can't make a mistake. And what that's, that's great because what that means is you can basically code while drunk, you know, and like your tools will just catch every mistake that you make and tell you immediately. And when you know your tools well, you can just go, Oh yeah, I see what you're doing. Okay. I changed that. Okay. I get it. I get it. I get it. And so that's the first thing that I've really, really prized. Obviously, if 

AJ_O’NEILL: I'm a hundred percent in with you on having tools do the work and it's just I want the tools to do the work on the thing I'm working in, not on something else. But yes, I'm 100% in. I want tools to do the work. That's one of the reasons I love Go. I really like Rust because the tooling is bar none in Go. 

MATT_POCOCK: Totally. And what that means too is that when you go all in on TypeScript and you have these, the thing I guess that separates it, I don't know whether JS.doc has this actually. I don't know JS.doc that well. Can you define like a sort of interface in JS.doc? like you can in TypeScript, for instance. So let's say I have a user that I know has an ID, a Boolean, whatever. 

AJ_O’NEILL: So yes, but I don't do that. Because if you think about it, all you need to do to define an interface is just define a type, right? Because if you define a type that has three functions on it and you say I'm returning this type of object that has these three functions, there's no practical difference between defining it as an interface or defining it as a type. And like I said, the only things that I use in TypeScript are type def, property, param. I use union on occasion. I use the enum as in object enum, meaning this can be a string or a number. It is the enum set of what the types are. And I don't know if there's much else that I use. There's probably one or two things here or there, but essentially with those, I think I counted off five things. Every possible pattern that you could represent in any language can be represented with just those five things. And so all of the other stuff, your class is just a function that returns an object of a type. So if you just define, if you just type def function, and then you say that what its return value is, is another type, then you've defined a class. 

MATT_POCOCK: Yeah. I think, I guess I was using kind of interface and type, uh, interchangeably. That what I meant to say was like you, what I find TypeScript does for me that I really, really like is it makes me think data flow first. It makes me think types first and implementation later. And so what I tend to do is when I'm building something new, like I'll just sort of think about what the data needs to be and the types need to be declare those in TypeScript first, and then start thinking about the flow and the API and how it should be designed and how it should all flow through. 

AJ_O’NEILL: So it's funny that you should say that because this is exactly verbatim what is criticized by Rob Pike in the way that languages like TypeScript encourage people to think. He explicitly calls out that it leads you towards thinking about the typing first, which is the thing that you're most likely to get wrong because you don't have enough information about how your program actually works. And then your refactoring efforts are greater than if your type system is very minimal and you focus primarily on the business logic first. 

MATT_POCOCK: That's fascinating because so would that impact how you apply your tests? Is that kind of like the idea is you should write your test first and get a sense of what the business logic is doing and then apply the tests, apply the types on afterwards? 

AJ_O’NEILL: Well, I guess...you always are going to have types whether they're implicit or explicit you always have types but it's a matter of how involved the types are because like you were talking about before if somebody changes something from an upper case to a lower case or whatever they modify the type you want to be able to quickly and easily go through and modify those types and if particularly I think when it comes to package organization what is the you want a directed graph of your types and your A to Q, but you want there to be as few paths to get from A to Q as possible so that you have the least possibility for error or confusion. And so you're always going to have those, but if you can design without all of the hierarchy and the types are really easy to fix, then you don't have to focus on trying to imagine, oh, you know, is a car is an instance of a vehicle, which is an instance of a moving object, which is an instance of an object. That's kind of the thing that he's criticizing is putting too much mental burden into how things relate to each other and, and how, you know, trying to conserve the amount of code that you write by not ever duplicating a function, if two things could ever have similar behaviors and that sort of thing, I think is primarily where the criticism stems from because that is what is taught in school. For example, if you, if you go to a computer science class, you're going to be taught that you need to think through these 10 layers of hierarchy before you, you print something to the screen. And as far as testing goes, I think you, you can apply this pattern to JavaScript as well. Although most of the testing frameworks and JavaScript seem to have either inherited from Ruby or Java. I haven't really seen one that to me feels like, yes, this is a JavaScript first testing tool. But a lot of times, unless the business logic is super clear, you don't know what your tests really need to be until you've established the contract and you're often creating something on two sides, right? So you have some part A over here and some part B over here. And if you start creating tests before you're clear on what the contract is, you know what the constraints are, because a lot of times you discover the constraints as you're, as you're building you introduce new constraints. So I do believe in test-driven development when the constraints are clear. I don't believe in test-driven development when the constraints are not clear or when the only thing you have to test against is based on knowledge that you might have wrong or maybe might is too soft of a word when there's a strong possibility that you're wrong about what the requirements are testing against that just makes refactoring harder. You know, anything that can be unit tested, typically that's perfect for test-driven development, right? Because if you can unit test it, that means that you know what the inputs are and you know what the output should be. And there's no asynchronous nature of it. It's you get in a block, you get out of a circle, you can test to see if the dimensions are correct, the volumes right, you know. But when you're looking at an API, a user interaction, these things, I don't think, are good candidates for test-driven development when you're exploring the product direction. 

MATT_POCOCK: It's interesting because I thought this conversation was going to go differently. I wasn't sure you were going to go so hard on JS doc, you know, like, which is cool because like it sort of means that we share a lot in common. A lot of criticism I hear about TypeScript is, well, why wouldn't you just do test driven development or why wouldn't you just unit test your JavaScript? So your JavaScript is just sort of doing the thing it's still doing. But instead of verification via the types, you're getting verification from the that the business logic is working. In other words, that you're testing the important bits. I would love to know kind of what you think of that. 

AJ_O’NEILL: I am gonna go all in on, unit testing is not a replacement for type checking. I'm going to make a hard left from my sensei, Douglas Crockford on this one. 

MATT_POCOCK: Preach. 

AJ_O’NEILL: But it's just in the context of something like Go versus the context of something like C-sharp from my perspective, something that has, or in a similar way, Python Python has strict typing, right? So I think that the most important thing more than anything else is to have strict typing. That's number one. If you don't have strict typing, how can you possibly have any hope of writing a correct program with other developers? Because you see a one and they say a one and you say the inputs one and all of a sudden you get a string and it works half the time. So strict typing I think is essential. I don't know why any language would ever want loose typing. I think shadowing is great, which for those that aren't familiar, shadowing is when you can declare a variable multiple times and you can declare it once as a string and then you could say do a parse int and you could declare it a second time as an int. So you could do var age equals read user input and then you could do var age equals parse int age. That's what the shadowing is. And I think that that is great. A lot of languages choose not to do that. I understand how it goes. could be confusing for someone, but in the places where I've seen it implemented, it seems to flow and work well. So strictness, type shadowings, I'm not going to say something has to have it, but I think it's nice. I don't know if there's really that... I don't think I've ever heard a good argument against it or any argument against it. And then having inferred typing is great, because if you have inferred typing and strict typing, then you have types. That's it. You don't need anything else. Well, except for where types can be ambiguous, such as is it an int 32 or an int 64? Or is it a float 32 or a float 64? But, and then the idea of new types, uh, which unfortunately we don't get in JS doc, and I don't think you get in TypeScript either. Uh, are you familiar with it? 

MATT_POCOCK: I don't know what you're throwing to. 

AJ_O’NEILL: So a new type is of just, it's, it's just a compile time check. Let's say that you have most famous case would be Imperial units and you have metric units. And so a number one. What does that mean? Because it lacks context. We don't know what that number one is. So in various parts of the program, say you need to do type conversion, you could specify that this type conversion takes in a metric unit and it outputs an imperial unit or is vice versa. And so new types give you the ability to just, you don't do anything. You don't add anything, you don't change anything. It's simply a type, a type linting or type hinting that you're saying this is not a number and it doesn't accept numbers. it accepts imperial units. And if you ever tried to pass in a number that has not been typed, it won't accept it. And if you ever tried to pass a number that is typed wrong, it won't accept it. 

MATT_POCOCK: You can indeed do that in TypeScript. You can have kind of branded numbers, which would be like an alias on a type of number. And you would say this is like an imperial number, essentially, or an imperial whatever, which is kind of cool. So I've done that before with like strings as well. So like I had different entity IDs mapped to different types. And so you couldn't pass a user ID into something that was expecting a post ID, for instance, very, very powerful. 

AJ_O’NEILL: That yeah, that is super useful. And if that's possible to do in JS doc, I haven't yet discovered it. That be my sixth item on the list of things that are incredibly useful if, if supported because that I use it so rarely, but when you need it, you need it, especially if you have something that you can pass in, say three different numbers to a function and you, you don't want to accidentally switch up two of them. That'd be a case where I'd potentially use it if it didn't make sense to convert that to an object for some reason. 

MATT_POCOCK: And it's almost not possible to do at runtime, right? That's something you can only do at a tight level. 

AJ_O’NEILL: Yeah, it's a 100% compile time. There's no way to do that. Which I actually had a question for you, which is how- 

CHARLES MAX_WOOD: Can we wrap up on this because we're kind of getting the picks time. 

AJ_O’NEILL: Oh, okay. 

CHARLES MAX_WOOD: No, go ahead. 

AJ_O’NEILL: Okay, so my- My one question that I haven't investigated and just heard people complain about, but I bet there's some sort of solution for is, oh no, I lost it. Wait. 

MATT_POCOCK: That's it. Timescript is perfect. 

AJ_O’NEILL: No. Curse you, Chuck. No. What was the last thing that I said? I think it was not even a related thought. I think it was just going back to something somebody had told me before. 

MATT_POCOCK: Well, to wrap up on my side, like, I'm surprised by how much agreement we have. I think you're right in that compilation is sometimes hurtful and sometimes overkill. I do think that TypeScript gives you enough to make the compilation worth it. And especially with this integrated approach with all these tools, I feel like when I'm coding in TypeScript, I just feel like I'm in a bubble. Whereas when I'm in JavaScript, even if it's with JS doc, I feel like I'm having to work harder and I'm having to do more work and I hate doing work.So all I want to do is just relax in my TypeScript, sensory deprivation tank, and just sort of like press little things and have it work for me. And it feels great. 

AJ_O’NEILL: Well, I'll be interested to chat with you in 10 years. Hopefully once you've dabbled in Go a little bit, or Zig, or some other language that's extremely constrained and see if age doesn't pull you into the pit of, I don't want to deal with mental load. 

MATT_POCOCK: Pit of simplicity, yeah. 

AJ_O’NEILL: The pit of simplicity, yeah. But yeah, I agree with you on...I think if we could constrain TypeScript, if we had a subset of TypeScript, if we had a subset of TypeScript that was just the minimal amount, and it was really easy, basically it's a one-to-one. If it was a one-to-one between the language you write and what the output is, there I can get behind transpiler. Essentially if you're writing a macro language, very, very simple, not a Turing complete macro language, which type doc is, but very simple macro language is just find and replace. If my... If all I was doing was adding a few light annotations, and what I got out was the same JavaScript I put in plus JS doc, that's the kind of thing that I could be happy with. But to me, it's the slippery slope. Once you introduce TypeScript, then anybody who comes along has the ability to create things as complex as TypeScript can make them, which is more complex than JavaScript can make them. Nice. 

MATT_POCOCK: A little, little, little unrefutable points at the end that I don't have time to get to. 

CHARLES MAX_WOOD: All right. Well, let's go ahead and do our picks. I've been pretty quiet because I don't know, I've used both and I kind of like them both for different things. So anyway, yeah, let's do PIX. 

 

Hey folks, if you love this podcast and would like to support the show or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production and you can go sign up at devchat.tv slash premium. 

 

CHARLES MAX_WOOD: Steve, do you want to start us off with PIX? 

STEVE_EDWARDS: Ah, I see we're starting with a high point first. So, okay. It's all downhill from here. Today I just, downhill from here, that's right. So I just have the regular elite level dad jokes. Last night, finally getting a good night's sleep and I was woken up by my wife and kids screaming. I was like, what the heck are you guys all yelling about? And they said, we're driving. 

AJ_O’NEILL: What? I didn't get it. 

STEVE_EDWARDS: I was falling asleep while I was driving and they were yelling at me to wake up. 

AJ_O’NEILL: Oh, okay, I missed.

STEVE_EDWARDS: hate it when you have to explain the joke. 

AJ_O’NEILL: Okay. It's I missed a critical word in there. 

STEVE_EDWARDS: Oh, okay. You know, I can usually guess what people do for a living by looking at their hands. I mean, I'm usually wrong, but I can at least guess. And then finally, if you really think about this, humans eat more bananas than monkeys. I mean, really who's ever eaten a monkey. 

AJ_O’NEILL: That was good. Go that one. 

STEVE_EDWARDS: Thank you. All right. That's all I have, Chuck. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_O’NEILL:Okay. So I'm going to pick this is all stuff from creeds of craftsmanship.com basically, but because of all the stuff we were talking about. So I think the talk that I was referencing earlier where Rob Pike is talking about how all languages are trying to adopt all other languages features and it's just creating a mess and what we need is simplicity, not complexity. I think that one is simplicity is complicated. There's two other talks that are by Matt Ryer that are excellent talks. One is called things I never use and go and go is already a tiny language and he's pulling out things that he avoids in an already language that's so tiny that it's difficult to reduce go to a smaller language and still have it be Turing complete and ergonomic. But he does make some really valid cases of here's a few extra things that really aren't necessary and only add complexity. One of them is spoiler else. And I think that if you watch this talk and you don't walk away from from it thinking I really shouldn't be using else except in extremely rare cases. I hope you walk away from programming as well. The little tongue in cheek there. Uh, okay. No, no. I'm my humor is too dry. I apologize. Anyway, scaring people how I write HTTP web services after eight years. That's another one. And then the one that I mentioned earlier, I think this is before the show actually started. So the one about HTTP web services after eight years, again, all these talks are about go, but all of these patterns are native to JavaScript. If you, if you consider native JavaScript and these, these patterns, it is a perfect pairing because of the simplicity that the JavaScript offers you that many languages don't. And then the Pike matchbox talk is about text encoding. And before we got on the show, we were talking a little bit on this tangent of how the Union Jack flag is not in windows. And many of the political flags are not in windows either. And it, how it has to do with text encoding and political divides and all this other stuff. That's not necessarily the point of the talk. The talk talks about the history of text encodings from the very first text encoding until the modern day with UTF-8 and all of the little tricks and whatnot that have been done and Pike match matchbox, Pike matchbox. It's some sort of special word that I think I can't remember. He tells it at the end of the, of the talk, but it's basically If I remember correctly, it's something that US, not US postal workers, but postal workers used to ship packages between countries. If they had Cyrillic alphabets, they would use this reduced alphabet that when it was converted to Latin one or the Russian encoding, then it would still have meaningful characters or something like that. So those, those are my picks for the week, all technical stuff. And, uh, well, actually one more thing I'll pick is I'm starting to like Twitch a little bit more. I've been streaming on Twitch. I finally became an affiliate and now that I'm an affiliate, they boost my channel a little bit so I get more views and have interesting conversations with people while I'm coding on things. And that's just been kind of fun. If you wanna join in on that, it's twitch.tv slash CoolAge86. That's all. 20 minutes done. 

CHARLES MAX_WOOD: All right. All right, I'm gonna jump in. I'm gonna do my board game pick first. It's legendary. I've been picking the legendary expansions and the one that I'm going to pick, this one came out in 2013, it's Legendary Dark City. Board Game Geek ranks it at a weight of 2.63. So it's a little bit more complicated than the base game, but not a ton. And yeah, I've really been enjoying it. It includes a whole bunch of heroes, some of which you've probably seen and some of which you may not be super familiar with. I really wasn't. But yeah, so I'll just list them off. It has cable, which I don't think I'd ever seen a movie or anything or a TV show with but Daredevil, Professor X and Blade are the heroes that it adds and then the villains that it brings in are Apocalypse, Mr. Sinister and Kingpin and it has a whole bunch of other stuff. So then there are other heroes in there as well. I think Electra is in there. I'm trying to remember anyway, but it's super fun. It's a little bit larger expansion. I think it has like 350 new cards in it but if you're out there playing Marvel legendary, this one's a fun one. So I'm going to pick that. As far as other stuff goes, I am finalizing things on the conferences. So go to topendevs.com slash conferences and you can see when the conferences are and stuff like that. I'm also hammering out the rest of the sponsorship stuff for top end devs. So if you go to topendevs.com slash sponsor, you'll be able to see the details there. And my last pick is kind of a It's kind of a pick and kind of an anti-pick. And that is I've been using fireside.fm to host the podcasts. And so like if you, if you've been going to javascriptjabber.com to see the shows, you'll see it all listed there and stuff like that. And there were a couple of things that I really, really liked about it. One of it, one of which was that I could add the hosts to it and then they could go see the numbers on the shows, stuff like that. The issue that I had is that this particular show got so many downloads. It gets so many downloads every month that they are going to make me pay more for the bandwidth which is not really my jam and it's enough of a pay hike to where I'm actually looking at moving stuff off. So fireside.fm is a terrific system until you get to a certain size. And I have another arrangement with another company that will do the hosting for me. And so I'm moving everything back onto cashfly. And so you'll start hearing cashfly messages at the end of the show, 

AJ_O’NEILL: but how many terabytes of bandwidth do we use Chuck? 

CHARLES MAX_WOOD: I think we, I think we top 10. Yeah, it was something like that. It was enough to where they said that we had to pay more for the bandwidth. And I have a different arrangement with Cashfly regarding the bandwidth. And so it'll cost considerably less to host with them. What that means is that I've got to migrate everything over. All the shows are going to be back on Top End Devs. So if you go to topendevs.com slash podcasts, you'll see the shows there. Yeah, I'm just kind of hammering out some more pieces of that. Since I'm building top-end devs myself, I kind of had to divert into managing some of that other stuff. But the upside is that I kind of get to do it the way I want it. If you're, incidentally, if you're looking for a system that'll do podcasts, conferences, meetups, courses, and all that good stuff, and you can kind of manage your media presence and your paid content, that's what I'm building with top-end devs and I'm planning to license the software you can pay for all that. But anyway, that all said, just a heads up that everything's going to kind of shift here within the next few weeks. So yeah, anyway, but if you're looking to start your own show, the, the hosts that I like are fireside.fm and transistor.fm. So you can go look at both of those. Matt, do you have some picks for us and also tell us how to get your course? 

MATT_POCOCK: Sounds good. Yeah. My course is at mattpocock.com. You can find me as Matt N-A-T-C-P-O-C-O-C-K. You can also find me on Twitter at matpocockuk. I'm posting TypeScript tips and all sorts of fun stuff there, kind of advanced generics and all sorts of madness going on. I work at a company called State the AI as well. We do a lot of work with state machines and state charts. And I kind of think that there's a lot to be said there and there's a lot of cool stuff we're doing. We're building like a visual editor that you can build state charts using it and compile them down to code and make them power your front ends. It's kind of cool and cool to see sort of like a visual builder thing happening. And my pick is actually a board game pick. So I'm in board games as well, or relatively recently into board games. And the two that I've really, really loved. The first one is the crew. You played the crew, Charles? 

CHARLES MAX_WOOD: I don't think so. 

MATT_POCOCK: Oh, it's real good. It's really good. It's like a 10 quid or I don't know, $13 or something. And what it is, it's just a, just a card game basically except it's a collaborative card game, so you're all trying to win together. And what you do is you basically, it's just a trick taking game, and you have a little mission at the start of the round, and someone has to win a trick that contains a certain number of a certain suit. And what you do is when you win that, you go on to the next round, and it gets a little bit harder, a little bit harder, and there's 50 rounds, and it's incredibly good value for money. And also the main thing about it is, is that you cannot talk while you play the game. So you can't talk about what's in your hand. So what happens is you get 10 minutes of people going like in complete silence playing these tricks See if they win or lose and then at the end it's like, oh my god, you did this And it just goes crazy. Yeah, it's a brilliant brilliant brilliant game and so cheap And I guess the other one is like a classic game called race for the galaxy, which you may have heard of Chuck Which is just fabulous. It's like a card game I was into magic the gathering for a long time and this sort of scratches that itch while being a bit more sort ofMfriendly for new people to join in. Again, a card game where everyone's sort of playing at the same time, but it is competitive and all about building up your space empire. And yeah, those are my picks. 

CHARLES MAX_WOOD: Very cool. So I'm just gonna chime in here for a second. So the crew, it looks like they have a sequel to it now. So there's another one that's a Deep Sea one. It's not a space one. But yeah, the crew, it clocks in on Board Game Geek. It's a 20 minute game and it clocks in at 1.98. So it's, it's kind of your casual level game. 

MATT_POCOCK: It's not super complex race, super approachable, but it's because it's, it's impossible to kind of quarterback, you know, so someone can't sit at the back and like, uh, direct everything. So it's surprising how much complexity comes out in it. So yeah, the weight is low, but it's, it's pretty nice. 

CHARLES MAX_WOOD: Right. Race for the galaxy is weighted at 2.99. So it's a little more complicated. I just like to give people a feel right because some people are casual gamers. They don't want much more than a two or 2.5 unless it's got like an interesting theme or something. So maybe race for the galaxies there, but yeah, it clocks in at 2.99. So it's about a three. So it's a little more complicated on the scale of casual gamer, but yeah, both of these look like fun. I'll have to go waste my money on them. I'm a sucker for board games and card games. I really, really enjoy playing them. 

MATT_POCOCK: So yeah, you'll love the crew. I promise.

CHARLES MAX_WOOD: Well, if people want to find you online, where do they find you? 

MATT_POCOCK: They can find me at MattPocockUK on Twitter or MattPocock.com. Just search for MattPocockTypescripts. I've got a YouTube channel. Yeah. You'll see me. 

CHARLES MAX_WOOD: Okay. Sounds good. 

AJ_O’NEILL: It was great to have you on. 

CHARLES MAX_WOOD: Yeah, it was fun. 

MATT_POCOCK: Enjoyed our discussion. 

AJ_O’NEILL: I enjoyed your well-defended position. 

MATT_POCOCK: Yep. I thought you did a pretty good job too. I was surprising. I was expecting a much worse defense. So well done. 

AJ_O’NEILL: Well, yeah, thanks. What? Not curious. What kind of expense were you suspecting?

MATT_POCOCK: Wait, I saw the purple box and I thought, ah, this guy can't be serious. What's going on? 

AJ_O’NEILL: Wait a minute. You don't have purple boxes over in the UK? 

MATT_POCOCK: No, I've got my green box. You see. Oh yeah. 

CHARLES MAX_WOOD: Well, all right. I'm going to, I'm going to end the recording. 

 

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.com to learn more.