In this episode, Dan sits down with TypeScript expert Matt Pocock to dive deep into the world of TypeScript migration, learning curves, and developer challenges. They explore why having a TypeScript "wizard" is crucial for teams transitioning from JavaScript and how TypeScript's integration with development environments like Visual Studio Code has been a game changer.
Dan and Matt discuss the importance of real-time typechecking, the community's role in TypeScript's success, and practical strategies for migrating large codebases to TypeScript. You'll hear about Matt's journey from drama school to becoming a DevRel expert, his contributions to the XState library, and his philosophy of type-driven development. Together, they highlight TypeScript's advantages, such as enhanced code reliability and the nuanced benefits of explicit vs. inferred types.
Whether you're a seasoned developer or just starting with TypeScript, this episode offers valuable insights and actionable advice to help you harness the full power of static typing in your projects. Tune in for a fascinating discussion that underscores the value of "boring" code, the need for continual learning, and the ongoing evolution of software development practices. Stay with us as we unravel the intricacies of TypeScript and share practical tips to elevate your coding journey.

Dan Shappir [00:00:05]:
Hello, everybody, and welcome to another episode of the JavaScript Jabber podcast. Today, we have a special episode with a special guest, Matt Pocock. Hi, Matt.

Matt Pocock [00:00:16]:
Hello, Jan. How are you doing?

Dan Shappir [00:00:19]:
I'm doing well. It's great to have you here. Before we start, we have I have one thing I would like to mention. So, there's the the new the latest, j s j s survey that has just come out, I think, today as of the time of the recording. And I would love for you to pick JavaScript Jabber as one of your favorite podcasts in this survey, you know, just to help us get the word out there, you know, every little bit helps. So with that out of the way, let's get to Matt. So, Matt, how have you been doing?

Matt Pocock [00:00:56]:
Good. Very good. I've moved house recently. My, son, fell about 5 feet onto a, a hard floor. Oh. He's absolutely fine, but he had a blackout for about 10 days. But other than that, I'm doing okay. Yeah.

Dan Shappir [00:01:14]:
Yeah. It's it's funny. Well, first of all, you need to mention that your son is 11 10 or 11 months old.

Matt Pocock [00:01:19]:
That's true. That's true. He's not not 16 or something. No. He's 10 months old. And, yeah, he's very small and he fell quite a distance, but he's

Dan Shappir [00:01:28]:
okay. Yeah. It's it's surprising how resilient babies are. I mean, if they if they are if they wouldn't have been, then the human race would have likely died out by now. But, you know, obviously, it's super scary and we shouldn't drop them. But but they are but they are but they are resilient, more resilient than we might expect.

Matt Pocock [00:01:46]:
Quite.

Dan Shappir [00:01:47]:
Yeah. And where have you moved to?

Matt Pocock [00:01:50]:
So I just moved locally. So I live in Oxfordshire and just moved to another place in Oxfordshire. So I can see horses out my window. Oxford is, like, somewhere that distance, and it's it's nice. I really like it.

Dan Shappir [00:02:04]:
So really, an English country gentleman?

Matt Pocock [00:02:09]:
Quite. Exactly. That's how I like to present myself. That's how I feel too. I just need my top hat, my monocle, and my pipe.

Dan Shappir [00:02:18]:
You know, I know you as I imagine most of our listeners do from everything related to TypeScript. You have

Matt Pocock [00:02:25]:
a

Dan Shappir [00:02:25]:
TypeScript site. You have a TypeScript newsletter. You put out, I think, TypeScript related videos and and other forms of content. To a lot of us, me, for example, you're kind of like mister TypeScript. I I'm subscribed to your newsletter. Well, I'm subscribed to a couple of development newsletters, but yours is is one that I open as soon as it arrives because it contains so much really useful and pertinent information. I've really learned a lot, and I'm not just saying it, you know, to be nice. I'm saying it because it's true.

Dan Shappir [00:03:02]:
So I would love thank you. So I would love for you to tell us a little bit about your journey into TypeScript and maybe even your journey into software in general because I know that you didn't actually start with software. It's something that you, like, grew into or decided to to join or whatever we like to call it. So take it away.

Matt Pocock [00:03:26]:
Yeah. My journey into development in general is odd. I studied drama at university. I, after that, I became a singing teacher. So I sort of sung in a lot in at university and and and basically picked up singing teaching. I did a master's in voice and singing teaching, so in a drama school, and moved to London and was working as a drama teacher. And I lived in London, and I wanted to be an Oxford country gentleman, you

Dan Shappir [00:03:58]:
know.

Matt Pocock [00:03:58]:
I didn't like living in the big city at all. And so this was around 2017, 20 no. 2016, I think. And I thought what's a skill that can take me out of the city that I can do from anywhere? And I've always loved computers. Always, I was made my own little websites when I was 12 years old, just with HTML. And I thought, well, okay. Maybe I could do that for a job. And so I started making applications for my students, making my lessons more interactive.

Matt Pocock [00:04:30]:
And I love teaching. I I still love teaching but I just I I wanted to try something new. And it occurred to me that I could go and get a job doing this. That's what I did and became a a junior developer. And I went from junior to mid to senior pretty quickly. And around when I was a mid, I started picking up TypeScript. And I I was always a just basically a JavaScript and TypeScript person. I did a little bit of PHP, but really just that.

Matt Pocock [00:04:55]:
And I started to

Dan Shappir [00:04:57]:
So what year was it when you started, doubling in TypeScript?

Matt Pocock [00:05:02]:
About 2018, I think, would have been. Yeah.

Dan Shappir [00:05:05]:
Okay.

Matt Pocock [00:05:05]:
So it would have been out, I think, for about 6, 7 years at that point. And and maybe in 5 years or so. But and from that point, I was working professionally. And there was one particular project as well that had just really brought home the power of TypeScript to me, which was this project, we were the front end team working with the back end team. Back end team in a totally different language. And we would make these contracts for linking up the front end and the back end. And they weren't very sophisticated. They were just kind of JSON blobs in Google Docs.

Matt Pocock [00:05:39]:
And these contracts, the back end team never quite implemented them the way we wanted them to in the front end team. So, you know, you would have camel case since or instead of snake case or the other way around or something would be misspelled, something will be nullable when we didn't expect. And this would cause bugs. You know, this would just break our front ends. And when we started adopting TypeScript, which I really really pushed for, suddenly, whenever a small change was made in the back end architecture, it just meant we could change it in 2 seconds instead of 2 hours. You know? It was fantastic. And so from there, I was just a touch advocate at every job I had, and that led me into a bit of open source stuff as well. So I started doing, have you heard of a library called XState?

Dan Shappir [00:06:27]:
Yes. Yes. I have. It's a it's a state management library. It's it basically does state machines.

Matt Pocock [00:06:34]:
That's right. Have you had David on the podcast as well? David Kosci.

Dan Shappir [00:06:38]:
I think we have. I would need to check. I if we had, though, I think I might have missed that episode. And to be brutally honest, I, myself, have not yet used XState.

Matt Pocock [00:06:50]:
It's a wonderful library. Basically, building state machines and state charts. And if you've ever done front end work, you know that building front end interfaces is really hard, actually, and you will often encounter bugs. And those bugs are often because you just haven't thought of a specific state that your UI can be in. You know? Like and, you know, things go out of sync and then it and it all feels horrible. But state machines really bring that complexity to the surface and make it a lot easier to work on. And I was working on some complex app complex applications like spreadsheets. Like, I was building a, a video calling service where you could, like, walk through a virtual room in an agency I was at, and XState was really incredible for that.

Matt Pocock [00:07:38]:
And so I started working doing a little bit of open source stuff for XState. Open source then led to me joining a company that got formed out of the XState core team, and I started doing DevRel for XState. And then start teaching TypeScript. And when I started teaching TypeScript, it just went something really crazy happened. And within about 6 months or so, I I became, someone with about 4,000 followers to being the TypeScript guy, to being this person. I'm not really sure how that happened. Happened quite quickly and happened seemingly without my knowledge or intervention. So, thank you.

Dan Shappir [00:08:13]:
Well, I think it's a combination really of a a couple of things. First of all, I think there was a real need in the market. I mean, on the one hand, Microsoft were communicating stuff about TypeScript, but but it was kind of like information from on high, and and it was. And and they were doing it as a vendor, not as as, you know, as a teacher. So I think there was a real need for for teaching TypeScript, and everything else was like TypeScript in the context of something else rather than the focus on TypeScript itself. And I also think it helped that you're just a great teacher, that you could bring your knowledge and expertise and your approach that you had from teaching other things and apply them to TypeScript as well. Yeah. I I am curious though.

Dan Shappir [00:09:08]:
Maybe it's the fact that it's you know, I'm a I'm a bit old school. I came into software, the more traditional route, through actually studying computer science in the university. And around and there's a lot of formalism around type systems and stuff like that. So you kind of expect people who that are really into type systems to have a bit more formal background. Mhmm. And and yet you're able to do this and pull it off and do it really well. So how did you fill in the the missing blanks? How did you get the the the the the background in in type systems, stuff like that?

Matt Pocock [00:09:54]:
That's a great question. And I think, probably there are still blanks in my knowledge that I that I don't know about because I often feel, and I think a lot of people who come into dev as a second career feel this. They feel like, oh, we I missed out on something crucial. You know? There was something in a CS course I never took that I I I never quite got. And I think a lot of people feel that. But as it turns out, TypeScript operates on a relatively high level. You know? You don't need to know a lot of the deep stuff. I'm I'm still, like, I still find it hard to explain, like, covariance, contravariance in a sentence.

Matt Pocock [00:10:34]:
Like, I never quite know if I'm using the terms correctly. And it has felt to me I feel like if learning that stuff would benefit my the people learning TypeScript, I would teach it. If, for instance, contravariance and covariance was mentioned in TypeScript errors, I feel like I would need to teach it. But as it turns out, me not knowing about that stuff, I think, actually helps in terms of explaining it to people because I'm not trying to layer on all of this extra kind of nomenclature and language onto what are relatively simple concepts. You know? If you understand what a subset and a superset is, you know, you can kind of understand what TypeScript's doing in a lot of cases. And so I do feel a bit like, oh, maybe it would have been good for me to do a CS course, learn that stuff. But, actually, I think not knowing it, not having the curse of knowledge has benefited me in weird ways too, making me closer to my learners.

Dan Shappir [00:11:38]:
First of all, I totally get that. I also have to say, you know, again, I even though I came into software, the more traditional route, I actually started before I learned. So I did start as a hobbyist, you know, as a teenager. And then I after several years of just basically, you know, doing whatever seemed to make sense, I I went to university. But it's been so long that effectively, I think every technology that I've learned, I'm no longer using. And every technology that I am using is stuff that I learned after I actually finished, my universities, you know, at part of my career. So, I I I totally get that a lot of what we we learn is some is the stuff that we pick up along the way. And in fact, the thing that I love most, it's it's the biggest challenge around working, I think, in software development, but it's also the thing I love most is the fact that you constantly need to be learning stuff and updating your your skill set and knowledge and and whatever.

Dan Shappir [00:12:44]:
And we'll probably get to how you yourself manage that, especially with TypeScript, but with other things as well. But before that, I would actually like to share something about my the way that I got into TypeScript, which was a bit different than you, I think, or or maybe maybe maybe not. We will see. I got into TypeScript a little bit earlier, around, I think, 2014, 15 is the first time I actually encountered it. And I have to tell you that in my initial reaction was very negative. Mhmm. The reason was that back at that time, Microsoft, the all the the examples that they were that were coming out

Matt Pocock [00:13:27]:
of

Dan Shappir [00:13:27]:
Microsoft were around classes and interfaces. Mhmm. And they were showing, you know, this is how you implement class hierarchies and interfaces and doing it safely and stuff like that. Mhmm. And to me, it very much felt like Java or c

Matt Pocock [00:13:47]:
sharp. Mhmm.

Dan Shappir [00:13:49]:
And, you know, I left Java and c sharp and went into and and, you know, got into JavaScript and enjoyed JavaScript much more than I ever did Java or c sharp. So the last thing that I wanted was to go back. I think the the terminology that I was using back then was this is a poor man's Java. And and I basically said, you know, kind of a little bit reflected some of the attitudes that, DHH, proclaims still to this day that, you know, I like the freedom. I like the duck typing, the the monkey patching. You know, I don't like to feel constrained. I've got tests as if I need guardrails and and and stuff like that. And and it took me a while.

Dan Shappir [00:14:44]:
It took me a a couple of years to realize the value the TypeScript actually actually has. When I started using TypeScript without, without classes and interfaces, did you go through a similar phase, or was it great for you from the get go?

Matt Pocock [00:15:06]:
So it was great for me from the get go, I have to say. And I I feel like I'm not sure when TypeScript implemented JSX, but that's what they did. They implemented JSX and a few sort of nice niceties to, like, basically, work better with React. And I was working on a React app at the time that was in JavaScript, and we translated that over sort of slowly to TypeScript kind of as we were working. And it was just great from the get go for me. So I I never actually received that marketing of, like, oh, this is the new c sharp or something or this is like, you know, I don't think I really sort of thought about classes and interfaces. And, actually, to be honest, React was quite class based at the time. So, no, I didn't have that.

Matt Pocock [00:15:52]:
I immediately saw the value, and I immediately started putting in a React app, which was mostly functional.

Dan Shappir [00:16:01]:
The the other aspect of it that was initially problematic for me, and and to an extent it still exists, I guess, is the fact that you the the way that it at least initially I thought about it is that I would write a JavaScript code, and then I would add the types in. Mhmm. And what happened was that the JavaScript code, at least initially, would come very fluently or very flu very quickly. But then I would literally, like, sweat bullets adding all the TypeScript in. Now part of it was that, obviously, I didn't know TypeScript well enough. Maybe I still don't. But also that I was doing, you know, doing some more extreme dynamic style coding with JavaScript, and that didn't really sit well with the way that you, you know, you might write TypeScript. So there I was, like, sweating bullets about getting the the proper type interfaces.

Dan Shappir [00:17:06]:
And I'm and and I'm kind of anal about these things, you know. It has to be perfect, you know. It can't just be any or stuff like that. And and I was thinking, hey. I'm spending more time on on implementing the types than I am than I had been on the original logic in JavaScript. And and it's it's weird because at the end of the day, all this type information is basically stripped out. So when it's actually executed, it's just the JavaScript back again. So here I am putting all this effort into something that has literally zero impact at runtime, and it felt kind of, you know, redundant.

Matt Pocock [00:17:54]:
You can feel like, oh, I've the feature is done. You know, I can see it working. Why do I have to do all this extra effort to

Dan Shappir [00:18:01]:
Exactly.

Matt Pocock [00:18:02]:
To to just paint it really, to just, you know, the car is working. I don't care what it looks like. And, I think if I were to rebut that, I think I because I I do I I think I didn't have a long lead in as, like, a JavaScript developer really before becoming a Times Script. I have maybe 2 or 3 years or so. But folks who've been writing JavaScript for a long time before that, their habits are absolutely set. You know? Like and all of that sort of dynamic stuff, you know, like the monkey patching and all sorts of patterns are kind of TypeScript makes you be a lot more boring. You know? It makes you write in quite a sort of dull way. You know? You you don't get a lot of, a lot of the same freedoms that you do when you're working in JavaScript.

Matt Pocock [00:18:53]:
Of course, I would argue that is quite a good thing. You know, it means that code generally starts to

Dan Shappir [00:18:58]:
Boring is good.

Matt Pocock [00:18:59]:
People will like each other. Boring is good. You know? Yeah. Boring is good. Boring is efficient. Boring means that you can switch projects easily. Boring means that, you know, boring is good. And I would say that the what I start doing now, having worked in TypeScript for a long time, is I do more type driven development now, is I'm thinking about the types and the flow of the types really before I'm thinking about the runtime architecture or perhaps sort of as as part of that.

Matt Pocock [00:19:30]:
And so I tend to type my function parameters before I implement them. So I'll just get my all my functions in a row and understand what's happening, and then I will start to implement. So I think that is definitely for someone coming from a long time JavaScript background, that's quite alien, you know, because that's really, I need to think about these types before I implement the rest of it, but that's how I'm certainly thinking about my TypeScript dev.

Dan Shappir [00:19:55]:
So, first of all, by the way, one of the things that also clicked it for me was when I started thinking about it like tests.

Matt Pocock [00:20:04]:
Yeah.

Dan Shappir [00:20:04]:
Again, you can write all your code without tests, and tests themselves, again, have zero impact on runtime. They're not part of the runtime bundle. So, again, you know, you could say, well, all the tests are stripped out effectively. But, you know, I I I really hate code bases without tests. You know, it makes me feel insecure. And even though I sometimes, like, you know, I'm lazy. I sometimes load write writing all the tests that I need to, but, you know, at the end of the day, it's it's worth it. And I look at the same way with types, and and and I've gotten really to the point that I really can't write JavaScript anymore.

Dan Shappir [00:20:45]:
I I even the I love JavaScript. JavaScript for a long time has been my favorite programming language. I've been doing it since 1998. I'm really dating myself. So so yeah. For a long time, more than many of our listeners have been alive maybe. But but, but these days, I'm literally, like, I I literally, like if I if I'm writing just pure JavaScript without the type definition, it feels like something is missing.

Matt Pocock [00:21:19]:
And I think a lot of people feel that way as well. That seems to be why TypeScript is so sticky. It's not like people adopt TypeScript and then, in my next job, I'll just write JavaScript because that was too hardcore. No. People who tend to go into TypeScript, they don't tend to leave because you're right. It just doesn't feel the same. You just I think there was a quote from the TypeScript documentary that really stuck in my head, which is when you're writing in JavaScript, you feel like you're carving in stone, basically. It's really hard to then change that resulting code.

Matt Pocock [00:21:51]:
Code feels a lot less malleable, a lot less movable, a lot less portable. You just can't change it with the same rapidity and the same sureness. Whereas in TypeScript, if you move something to the wrong place, it will give you all these warnings. You can check your entire project, and you can be you can have a lot more security that your code works the way you think it works.

Dan Shappir [00:22:16]:
I totally agree. And this was actually you know, I I literally experienced this very recently as in a few days ago because at where I work, which is Sisense, we've got a lot of legacy code. And one of the topics that I'll probably bring bring up with you is, you know, how to deal with legacy stuff and how to port existing JavaScript projects to TypeScript. And I see bugs in the code that could not happen if the code had been written in TypeScript. Mhmm. And, you know, there are a lot of challenges in adding TypeScript into an existing JavaScript project, especially a large one. But for me, the biggest challenge from what I see is fixing all the bugs that you discover when you add TypeScript. Because ideally, adding TypeScript in an into an existing JavaScript project is basically just adding types.

Dan Shappir [00:23:18]:
You don't you you don't want to be touching the business logic. But what I find is that I run I find bugs in the business logic, which I then need to fix. And and this to me is, like, the biggest hassle of of adding Java TypeScript into an existing JavaScript project.

Matt Pocock [00:23:37]:
That's I mean, that's quite a good hassle to have. Right? You know, like, the hassle of making your, code better, I suppose. I mean, in in some ways, you know, it makes you code a bit more defensively. You need to make sure that, you know, that your inputs are all correct and but, yeah, you're absolutely right. And that was definitely the experience we had is that, when I first introduced TypeScript to that very first project is, oh, wow. That's a code path I just didn't see was possible or, yeah, that's okay. That could either be a string or union or, string or number in that place instead of just a number. You wanna dive into, like, how to migrate? Because I definitely got some advice there.

Dan Shappir [00:24:18]:
Yeah. You know what? I I was saving it for later, but it seems to naturally fit in here. So let's say I'll I'll give the background. Let's say I have a large scale existing JavaScript JavaScript project. Maybe it's React, maybe it isn't. I I don't know if it matters really. And and no TypeScript insight, and I want to add TypeScript into this project. You know, I can what's the best approach? Should I do, like like, sit down and just try to do it all in one go? Should I do it incrementally? Mhmm.

Dan Shappir [00:24:53]:
And if so, you know, what would be the unit size? How do I estimate the effort? Mhmm. How do I justify it to product and management that I'm gonna be spending all this time yet not adding a single feature into the product? You know? Mhmm. What can you say about it? Yeah.

Matt Pocock [00:25:13]:
So it's a huge topic. Let's add another assumption as well. Well, let's assume that the code base is actively being worked on and that there's features being added as well because that seems to be the most common case.

Dan Shappir [00:25:23]:
Oh, yeah. For sure. If it's not worked on, then what's the point almost?

Matt Pocock [00:25:27]:
Exactly. Right. So, like, you're working on an active code base. You need the CI to remain green all times as well. You don't want to be doing things which make the CI red for a certain period of time, and you don't wanna be messing people's stuff up. So there are a few ways that you could do it. You could take every single JavaScript file, turn it into a TypeScript file just like with a with a command or something, and then, boom, you know, you're in TypeScript with with 0 types. And then perhaps you could ramp down the strictness to the point where you get 0 errors.

Matt Pocock [00:26:00]:
Right? That's one way to do it. That's a bad way to do it. The reason for that is that, first of all, you break everyone's PRs. You know. If anyone has any existing PRs, then they literally can't, you know, that you would have to do all sorts of shenanigans to, make them

Dan Shappir [00:26:18]:
work. You probably want to tell everybody we're doing it on this week. Merge all your PRs. Don't create any new PRs, and this is what we're doing.

Matt Pocock [00:26:29]:
Yeah. Big disruption. You know? No good. Especially to a big team working on a big mono repo, let's say. And then the thing that's hard after that is that it's really hard to ramp up the strictness in a way that's incremental because you want the CI to stay green. And if you say, okay. Today, we're going to turn on the no any rule, then you turn it on and it affects your entire code base. So the CI is basically red.

Matt Pocock [00:26:56]:
So I think that that approach, which a lot of people do take, of turning every file into a TypeScript file is a bad approach. Because what you should do, I think instead, is you should add in a TS config into your project. You should install TypeScript. And you should choose the highest level of strictness that you're going to get, your desired level of strictness. And when you do that, you then take it file by file. And you're just turning basically in one PR, you would just turn one file into a TypeScript file. And by doing that, you might find external libraries that need, to be imported types and stuff, and you fix the types in there. You can use, like, any at this point as well, you know, if you need to if you need to get around it.

Matt Pocock [00:27:38]:
But that's what I would start with. And the key there is that the order of the files that you choose is really important. Right? Because let's imagine that your code base is like a tree. You know? You've got the files that are imported very often, sort of at the top of the tree and sort of like spreading down like that. And the files that are used in lots of places, you want to do those first. You want to translate in the TypeScript first, the ones with the fewest dependencies. You can use a tool like Madge, I think, to basically walk up the tree.

Dan Shappir [00:28:10]:
You want the ones you want to start with the ones that have the fewest that depend on the fewest things. And but on the other hand, that a lot of stuff depends on them. That way, you you create small disruption but quickly bring on the most amount of value.

Matt Pocock [00:28:30]:
Yes. And the reason for that is so like your utilities folders, for instance, or, the files that contain, you know, math or something or, you know, things that you use in the marketplace.

Dan Shappir [00:28:41]:
Which project does not have a utilities folder?

Matt Pocock [00:28:44]:
Exactly. Right. That's where you wanna start. The reason is is that if you start further down the tree, then your TypeScript code is gonna be depending on JavaScript code. And that's a really nasty place to be because all of the JavaScript code is just gonna produce anys. And so those anys are then going to filter through. Whereas if you start with a TypeScript file that has no JavaScript dependencies, you're gonna be in a really, really good spot, and then you just slowly go down the tree. And so Sentry has an amazing article about this.

Matt Pocock [00:29:15]:
They basically did this for,

Dan Shappir [00:29:17]:
like, 2 year old Nicholas. Or maybe now or later.

Matt Pocock [00:29:20]:
Yeah. I'll drop a link certainly later, but if you Google Century TypeScript, it will come up. And that's Century, the error logger.

Dan Shappir [00:29:27]:
Yeah.

Matt Pocock [00:29:27]:
Not like, you know, a century of time. And what they did was they basically said, okay. We're just gonna share this out among the devs. Whenever you have a free minute, whenever you finish your tasks for the sprint, just translate a TypeScript file and go down this list of all of our dependencies. And so they slowly did that over the period of about 2 years, And it took them a while to to get it done. And I think there are still files in that code base. It's an open source code base as well. There are still JavaScript and mostly like tests and things.

Matt Pocock [00:29:56]:
They just haven't needed to change. And but every new file, of course, is still in TypeScript. And so that was the process they followed, and I think it worked really, really well. I interviewed, Priscilla, one of their devs for for my course, and she sort of explained the whole thing. And that is the process I would follow, basically. Make a dependency tree, work out which ones to do first, add in a TS config with the maximum strictness, and go file by file keeping that CI always green, making sure you're not stepping on anyone's PRs and maybe during people's PRs, they can turn things to touch groups.

Dan Shappir [00:30:30]:
You know what occurred to me? Maybe it's an idea for a feature if anybody from the TypeScript, dev team is listening, or maybe you'll tell me it's a stupid idea, in which case, don't do it. Yeah. It might it might be beneficial to have, like, two levels of of TypeScript support. So, if your TypeScript or TS or TSX file, then you go with the strictest definition. But there's a transitional period that your work you're taking a JavaScript file and then you're trans you're translating into into, TS. It might have been beneficial to have, like, a TS star or TS, you know, TS 2 whatever file Mhmm. That that has, like, less strict, settings. So which would allow you to gradually get that file to where you wanna go without having to lower.

Dan Shappir [00:31:27]:
And and that's a because one of the things that I'm seeing is that, unfortunately, at least with some of these legacy projects, some of the files are pretty large. Mhmm. You unfortunately encounter, like, a a 1,095. And and now, obviously, you can say, okay. Then part of the project is also splitting up such large files into smaller files, but that significantly increases the scope of the project. So, ideally, you would like to handle that. You would like to keep the file structure as is. It's also good good for Git and stuff like that.

Dan Shappir [00:32:03]:
Mhmm. And in that context, taking a 1,000 line file and and turning it all into straight from JavaScript into script TypeScript in one go can be fairly challenging. Now, obviously, you can turn off various rules in in the scope of that particular file, I guess, but that's a pretty big hassle.

Matt Pocock [00:32:26]:
Not quite. I mean, you could, I suppose I mean, there is a very complicated way of doing that. But in general, if you have a TypeScript project, the rules apply equally to every file, essentially. One thing you could do with a file like that is just use any in lots of places or ts ignore all the errors or file requests.

Dan Shappir [00:32:45]:
But then but then that means that you need to support any everywhere, which you may not want to do. Yeah.

Matt Pocock [00:32:51]:
And if it's a file that's dependent on a lot, then if you have any in in that top file, it's gonna spread down like a virus into all of the others. You know?

Dan Shappir [00:32:59]:
Exactly.

Matt Pocock [00:33:00]:
Yeah. It's it's just hard. I think there will be situations like that. And, honestly, starting with the, utils folder, that's probably gonna be the hardest to type. Right? You might end up needing some generics in there. Some generic types and generic functions.

Dan Shappir [00:33:16]:
Oh, I'll get to that.

Matt Pocock [00:33:17]:
Yeah. I'll get to that. So but you you might need that, and that's a hard place to start if you're just beginning a touch script migration and upskilling your team. So, usually, you do need someone who's gonna be, you know, the touch script wizard on that team to tackle the utils file, so that everyone else can benefit, basically.

Dan Shappir [00:33:35]:
Which brings me to another point. I've talked to people who are basically, like, thinking about doing this transition. And they said, well, the code base is one challenge, but the other challenge is my developers. Now these days, it's you you're getting more and more front end or JavaScript developers that are effectively TypeScript developers, but there's still a lot of JavaScript developers who are not TypeScript developers out there. And and the reality is is that I I I had a team lead tell me, you know, you want us to go full TypeScript, but my devs aren't don't really know TypeScript. Mhmm. And and it's a problem if I'm I effectively have my developers working in a programming language that they don't know. What we will end up is them using a lot of nees.

Dan Shappir [00:34:25]:
And if I don't allow them to use nees, then they'll potentially get stuck. And and now, obviously, you know, you're obviously working to address that by teaching developers TypeScript. But if I have an existing team, like, what would be the best way to get the team into TypeScript?

Matt Pocock [00:34:46]:
Well, I mean, the cool thing about TypeScript is that it's not a really heavy lift in terms of learning. If this is what I don't like about other languages that are sort of trying to solve the same problem as TypeScript, which is basically adding a type system to JavaScript. So things like, OCaml or I think I'm not sure. I don't know OCaml that well, but I know that's one of its uses.

Dan Shappir [00:35:11]:
ReasonML?

Matt Pocock [00:35:12]:
ReasonML, Elm, things like that. I don't like those because they're a much heavier lift in terms of learning.

Dan Shappir [00:35:18]:
Oh, it's a different programming language.

Matt Pocock [00:35:20]:
It's a different programming language. Whereas in TypeScript, people will say, surely that's a different programming language, isn't it? Well, no. I don't think so. It's really just a sort of set of decorations on top of JavaScript. And you're using a lot of the same intuitions as you have in JavaScript just to be able to add types to it. So I think when you do that, you you do need someone who I think can lead or be be the go to person at that company who can answer people's TypeScript questions. So I think a team that's just sort of, like, with 0 TypeScript knowledge whatsoever going into a TypeScript migration is, I think, gonna have a pretty tricky time unless they invest in some resources to, you know, help them out. But, yeah, you do need that person at the company who can just be the go to TypeScript wizard to say, help me out, please.

Matt Pocock [00:36:14]:
I'm just I'm just stuck on a problem. Because if you don't develop that intuition, it it can take a while to muscle through on your own. But I think the basics of TypeScript, I think you can get productive in TypeScript pretty quickly. Was that your experience of learning it?

Dan Shappir [00:36:29]:
Well, to be fair, I came into TypeScript as a as a very experienced developer who's been around the block. And I actually started with with statically typed lang well, that's not actually true. I started with basic, but but I pretty soon got into statically typed languages. So most of the most of my programming career was actually spent in statically typed languages. To an extent, going to JavaScript, I felt the liberation into an extent of of putting all the static types, behind and and, you know, just saying, you know, the the wild wild west as it were of of, you know, it can be whatever, and dynamic object structure and whatnot. I I by the way, one of the things that I like to say about TypeScript is that the tasks that they pick for themselves is literally herding cats because you have the poster child for dynamically dynamic programming, you know, programming language, which is not only dynamically typed, but dynamically structured. And and everything is about duct typing and and stuff like that. And then you're trying to, you know, implement a static type system on top of that.

Dan Shappir [00:37:47]:
It's it's it's pretty amazing what the TypeScript team has been able to achieve in that context. And our guest will get into some of the finer points if we have some time later on in this podcast. So for example, I learned generics or templates as they were called in c plus plus. So by the time that I got to TypeScript, I I the concept and then I used them in Java and in c sharp. So by the time that I got to to TypeScript, I was already familiar with these concepts. So it was less of a hurdle for me, than in my than it might have been, you know, had I not had that background.

Matt Pocock [00:38:23]:
I think you can one thing that occurs to me is that you don't necessarily need to learn the really advanced parts of TypeScript in order to get productive with it. Often, there are kind of like I think there are kind of 2 areas or or possibly 3 areas, actually, I think, in terms of the level of TypeScript that you need to interact with it, which is you probably need someone on your team who's able to write kind of library level TypeScript code, you know, like someone who can do The details folder. Utils folder. Exactly.

Dan Shappir [00:38:54]:
Let let's let's hold on on off on that because I actually want to get into that specific point and and a bit later in our conversation. Mhmm. And and before that, I have a I have a different question for you. So, yeah, what I really wanted you to ask so you're obviously a TypeScript aficionado. You you really love the concept. You love you love the language. By by the way, one of the other things that I I think we forgot to mention about the big reasons for TypeScript success is just the integration with development environments.

Matt Pocock [00:39:25]:
Yeah.

Dan Shappir [00:39:26]:
This whole thing about you know, one of the things that kind of came out in that, video that you mentioned, about TypeScript was the fact that you can look at it as a programming language, but you can also look at it as a tool. Mhmm. And and and for the JavaScript programming language. Mhmm. And and all the the great integration that you had from almost day 1 with Versus code Mhmm. Is I think you made a huge difference. Obviously, now you also get the same level of integration with, you know, with other tools like WebStorm or whatever. But without that level of integration, I don't think so the whole thing of this, TypeScript, service that's running on your, computer and that the editor can communicate with it, and it it does all the type checking for you in real time.

Dan Shappir [00:40:17]:
So that was a huge win.

Matt Pocock [00:40:19]:
Yeah.

Dan Shappir [00:40:20]:
And coupled with that is all the type information that they created for existing frameworks and libraries. So all of a sudden, if even if I'm just working in JavaScript and not TypeScript, I'm getting a lot of the benefits of TypeScript.

Matt Pocock [00:40:35]:
Totally. So this was about 11 years ago when TypeScript first kinda came out. And the thing that I think a lot of people probably,

Dan Shappir [00:40:44]:
or brought

Matt Pocock [00:40:45]:
a lot of people in was, one of my friends, a guy called Johnny Riley, who ran the definitely typed repo. He spent a weekend, I think, when his son was very, very small making, types for jQuery and basically, like, typing jQuery. So you suddenly had autocomplete for everything jQuery could do, and he wrote these beautiful JS dot comments, which are still there to this day. And I don't know. I mean, that level of integration, the fact that not only was TypeScript and Versus Code kinda being built at the same time, but TypeScript the Versus Code team went to the TypeScript team and said, we hear what you're working on is pretty cool. Do you mind if we use it to build Versus Code? So I don't think Versus Code, because it was such a complex JavaScript application, they really wanted a strongly typed language. So they they were built actually, at the same time using, really within Microsoft. Amazing.

Matt Pocock [00:41:44]:
I just I don't know.

Dan Shappir [00:41:47]:
Yeah. That that's the other thing. I know I mean, when I look at projects that somehow get by without TypeScript, they're usually very small, and it's a legitimate thing. But all the projects that I've been working on in in the world of of JavaScript development, be it, in the browser or be it in Node, in the past, decade have been really large. I mean, projects where you've got teams of at least 10, sometimes as large as 50, working on code bases that can be up to a 1000000 lines of code, doing that without typing is bordering on insane.

Matt Pocock [00:42:25]:
Yeah. Because, I mean, just in in a very simple terms, when you're working on like, the more developers you add to the project, the more likely you are that one of those developers is gonna make a mistake. You know? Just the number of mistakes goes up as the number of developers working on something goes up. It's just, you know, how maths works. And when you have something that you can just sort of stick in a project that you can run on your CI, let's say, you know, whenever a PR comes in and just check if anyone's made a typo, check if a whole class of those mistakes, that's just so valuable for teams. And especially when you have code that's being worked on at the same time, you wanna check if that code is compatible with each other. Having an automated system for doing that is incredible. And, of course, TypeScript doesn't catch everything, but it catches an enormous amount for a very low or comparatively low level of effort.

Dan Shappir [00:43:18]:
I totally agree. And there's the other side of it, which is the fact that JavaScript is so very forgiving, and so is the browser, and so so are basically, in almost any environment that runs JavaScript. So, you know, again, people would say, why do I need JavaScript? I've got tests. But the the the the thing is that the environment is so forgiving that you can have a catastrophic failure and still pass the test. So unless the test is specific enough, you can you can still get by with bugs. Like, the the I mentioned before that I'm fixing legacy software. I'm catching a lot of bugs. These are often, systems that have, end to end tests, let's say, in place.

Dan Shappir [00:44:07]:
And the end to end tests pass because the browser is such a forgiving environment, Mhmm. But it doesn't change the fact that you you've had a stupid bug in there that, you know, you've got some undefined in there where you should have had some value, and it's somehow able to muddle through until, you know, maybe it doesn't. Yeah. Anyway, so, I would like to get to the next my next question. And, you know, TypeScript keeps evolving, and and and getting new features. What version are we at? 5.what?

Matt Pocock [00:44:40]:
I think we're 5.7 now. Is that right? Let me check. 5.7 is the new beta that's coming out, so I'm pretty sure.

Dan Shappir [00:44:50]:
Okay. So first of all, let's start with with one thing. Let's start with what do you I think we kind of covered it, but maybe you can be more explicit about it. What do you love most about TypeScript? But the other side of that equation, is there anything that you hate about TypeScript? And if so, what are what is that?

Matt Pocock [00:45:10]:
Yeah. So there are lots of things I don't like about TypeScript, definitely. Lots of things I think they could improve, features I wish they would add. I think we've we've got we've got the love. The the thing I love is that it makes my IDE 10 times more powerful. It makes developing stuff easier. It makes me feel more secure. So let's go on to the fun stuff, the stuff I hate.

Matt Pocock [00:45:33]:
Flow, which is Meta's sort of version of TypeScript, it's a version of strongly typed JavaScript. It has something called exact object types. What that means is that if you create an object in Flow and you say, okay, this is of it's an object of this type, then you basically can't add any extra properties to it. So if you have an object with a, b, c, then you can never, in any situation in Flow, add a d property to it. But in TypeScript, in various situations, you can do that. So TypeScript has open objects, objects that are open to extension. And that means that in various places, you can actually get into situations where you have these random sort of properties kind of floating about. And if we if we were doing code, I could show you, but, you you can, read my chapter of my book on, exact object types, which is free, by the way.

Matt Pocock [00:46:29]:
It's, you know, you just Google it. And that means

Dan Shappir [00:46:34]:
free book, by the way?

Matt Pocock [00:46:35]:
It's a Total TypeScript Essentials. So if you go to total typescript.com, click book, you'll you'll find it.

Dan Shappir [00:46:41]:
And Highly recommended.

Matt Pocock [00:46:43]:
Oh, thank you very much. This means that various things in TypeScript are not as good as as they could be. So object dot keys, for instance, when you're iterating over an object's keys, when you iterate over a, b, and c, you would expect the type of that to be a, b, or c. Sure it's a, b, or c. But in fact, it's just a string. So it's extra wide. So it's wide because it's sort of it knows TypeScript knows, well, it could contain d, and I don't actually know about that. And that means that that extra wide type sort of gets a bit frustrating to use because when you go to index back into that object, it's horrible.

Matt Pocock [00:47:21]:
So I wish I wish I wish I wish TypeScript had exact object keys like that.

Dan Shappir [00:47:25]:
Isn't it something you can configure somehow with tsconfig?

Matt Pocock [00:47:29]:
It's just so baked in to the way that TypeScript works that it's impossible to go back. It's a feature I wish they could add, but I I I would be shocked if they managed to do it, honestly.

Dan Shappir [00:47:42]:
So you're saying it's such an integral or core aspect of the way in which they structured types of the language that backtracking on that on this now would be extremely hard. Like, adding a Boolean flag in the TS config could theoretically be possible, but, practically, it would be very challenging.

Matt Pocock [00:48:02]:
Very, very tough. And I suppose they could add some sort of keyword, you know, like the exact keyword to make the make it work. Because Flow has exact objects by default, but you can make them like TypeScript if you want to opt in. But, yeah, I I just don't think they, they do it because it does have benefits too. It's it means that you can pass wider objects to smaller ones, which is useful when you're doing things with classes and stuff. But I don't know. I don't think they're gonna they're gonna get around to it, which is a shame.

Dan Shappir [00:48:35]:
Anything else that you would wish?

Matt Pocock [00:48:38]:
There's a lot of there's some more complex stuff like, the way that TypeScript works with generic functions if you can actually pass types to certain functions. But then if you pass one type, then any other types that you don't pass don't get automatically inferred. So this is called the partial inference problem. I wish they would bloody fix that. I was talking to Tanner Lindsley about this, I think, 3 years ago, and he was saying, oh, they might fix it, and they've been shaping up to maybe fix it, but it it just makes certain APIs impossible, basically. You you and it makes things a little bit harder. So I would love if they fix that too.

Dan Shappir [00:49:15]:
You know what? I I was saving this question for later, but since you brought up type inference, maybe you can explain briefly what type inference means. And then you might say what is your attitude towards type inference. Like, if there is a place where type can be inferred, should it always be inferred, or do you prefer to be explicit sometimes or always? So let's start with what is type inference and and and go from there. Yeah.

Matt Pocock [00:49:44]:
So let's imagine you have a function, and that function can, either take in a string or a number. Then there are some things that TypeScript can't infer. Like, let's say you're creating a function. Whenever you create that function in strict mode, you have to annotate the parameters. That's usually where most people are writing their types actually. So imagine this function takes an input of string or number. Then we do like an if statement and we check if the input is a string. If we do, then we call like input dot to upper case or something.

Matt Pocock [00:50:14]:
Otherwise, we do something else. So if you imagine there are kind of 3 blocks there. There's the function. There's the first if statement where we're checking if it's a string, and the second if statement if we're checking if it's a number. Now without this magical thing called inference, we would have to add types in all those places. Right? We'd have to say, okay. It's a it's a string or number up here, it's a string here, and it's a number here. But TypeScript can actually infer that based on the behavior of our code, based on the it just looks at the code.

Matt Pocock [00:50:44]:
It says, oh, yeah. It's an if statement that's checking this thing. It must only be a string in this particular closure.

Dan Shappir [00:50:49]:
By the way, just to just to interrupt you briefly, that was one of the magical aspects for me of TypeScript that initially I didn't get. Because, again, I came into like, as I said before, my background was from language statically typed languages, which usually don't need these types of shenanigans because something is a strict type. You don't have to infer that, hey. It's this type in this context and that type in that context. You might do some crazy stuff around templates, to narrow to narrow the past in types, but but within the code itself, you don't. And it it took in in the realization that you that TypeScript does static analysis of your code and narrows the types based on how what it reads in your actual code, like ifs and stuff like that. And now you also have type guards and stuff like that. That was pretty amazing to me.

Dan Shappir [00:51:48]:
And once I realized that, that was one of the things that really, like, got me to to really appreciate TypeScript.

Matt Pocock [00:51:56]:
100%. And it's such a hard problem as well. Imagine building that from scratch, you know, Something that looks at your code and understands, okay, in all of these places, this is what what types these values are. It's crazy they pulled it off. So it works this is this is what's called narrowing in Timescript. You know? It works with switch statements, works with objects, works with, now it actually works with functions too. So you can create a function that checks if something is a string, and it automatically you don't need to add any type annotations apart from just the input. It's amazing the way it works.

Matt Pocock [00:52:27]:
So that's what type inference is. It's TypeScript looking at your runtime code and inferring the types from it. And I have an exercise in my course where I basically say, okay, we do all of this code and I basically annotate every single place that you could possibly annotate. You know? Like, on variables, on, function parameters, on function return types as well. And I just return

Dan Shappir [00:52:49]:
types, by the way, is where I usually think about inference. Like like you said, parameters usually need to be typed. I mean, because you really can't infer the parameters there. That's that's the entry point. But the exit point is certainly the place there's something that you can often infer. Like, you know, if it's an add function that takes a and b and returns a plus b, if both a and b are numbers, then obviously, a plus b is a number. So so yeah. So the so the question then really becomes, if the function return type can be inferred, should I be explicit about it or should I just let TypeScript inferred?

Matt Pocock [00:53:30]:
Yeah. So this I I go back and forth on this. This is a tricky question. And there are various cases where it's obvious that you should type the return type because what you're saying is when you create your function definition, basically, the types at the top are your description of how the function should work. And when you're in, let's say, a library setting or a utils folder setting, you probably always want to create those types actually because it's a way for someone who doesn't want to read the body of the function to just go, oh, I see what this is doing. Right. I understand. Okay.

Matt Pocock [00:54:04]:
It's a function that takes in a string and returns an object with a value in or something. So what it means then to type those is that it gives you a contract that you have to be able to meet. And so it means that this is type driven development. You are taking the types and saying this is what I want to create and then you're creating it. If you don't do that, then it does give you a bit more flexibility. It means that the things that you're returning, for instance, from your function are just like automatically inferred. This is a really good, a really good example is React components, for instance. They are always every single React component is always gonna return the same type.

Matt Pocock [00:54:43]:
Always gonna return a type of React dot React node because you're just returning JSX. So in every single React component, you're gonna be be returning the same thing. And to annotate a React component's return type just seems a bit weird to me. There are Lint rules that force you to add a a type to every single function return. And I find those extremely annoying because there are tons of use cases and tons of cases where I don't want to add the return type at all. But it is sometimes beneficial to just give yourself a guardrail, give yourself a contract that you need to meet. And honestly, I find myself doing it more and more and more because it just feels good to be able to say this function does this thing and then implement it.

Dan Shappir [00:55:28]:
So, basically, you're saying is if I'm I'm doing the function outside in, I'm actually specifying the function parameters and return types before I write the the function body, then I've got the return type as a validation that what I'm returning actually matches that type. So I I get 2 benefits. I I get, you know, anybody looking at the function declaration knows what the function will be returning without having to read the code. Although, you know, there's an interesting point about that. I'll get to that in a second. And the other aspect is that the fact that you're providing a guardrail for yourself, making sure that you are in fact returning the correct type.

Matt Pocock [00:56:12]:
Yep. Absolutely, Daniel.

Dan Shappir [00:56:15]:
The interesting thing is, again, looking at my experience with other statically typed programming languages, there are programming languages that actively advocate the, type inference approach, where ideally you even though they're statically typed, their inference is so good that you're expected to hardly ever write any types. Because you it it's it's basically you don't need to think what the type what the types are, which again which again takes me back to to this aspect. Because in a sense, if I don't really if I if I if my all my assignments are initializations, so all my variables are const, like, not variables. They're immutable. To an extent, I don't need to think I almost don't need to think about the type. So I I'm I'm assigning the return value of a function into a variable. It is what it is. Mhmm.

Dan Shappir [00:57:12]:
I know that what whichever way I use it is correct. I can only pass it into the appropriate functions. Or if I do the dot, I'll get the correct completion. I don't need to be explicit about the type. Mhmm.

Matt Pocock [00:57:25]:
There are situations where, of course, you do want to be explicit about the type where you know you know more about the type that something should be than TypeScript can infer from the runtime. A really good example of this is like index signatures. So for instance, if you have an object that you know, okay, I'm going to be adding keys to this dynamically, like IDs for instance, and, they're gonna have this value of property on them, then you need to tell TypeScript that upfront. Because if you just initialize like an empty object, then TypeScript is just gonna infer it as an empty object, basically. And so adding that level of,

Dan Shappir [00:58:04]:
of Make it a map.

Matt Pocock [00:58:06]:
Say, you have to make it a map. But even with a map, you need to, you know,

Dan Shappir [00:58:10]:
give it a map. Explicit. Yeah. You're obviously explicit about the time. By the way, one of the things that kinda also blew my mind about modern TypeScript is is how you can create types with string expressions, that that you can actually structure and say not we give example before about keys that it's not just any string. It's it's a keys of an object, but it also can be a particular structure of a string. So a string Yeah. That has, like, hello at the beginning or something like that, which is pretty insane to me.

Matt Pocock [00:58:43]:
Yeah. If you're if you're following along at home, if you've got us in your ear and you're at your laptop, try just typing crypto.randomuuid and call the function and see what if you just hover over the thing that it returns, you'll see that it returns basically it what it returns in real life is like a UID. So it's like, 5 parts of a string separated by dashes. And you'll see in the return tab that it actually does the same thing on the type level. It's crazy. It's crazy that you can basically represent these, strings in a time safe way. It's absolutely bonkers.

Dan Shappir [00:59:17]:
Another thing that really confused me initially when I got into TypeScript because, again, of my actually, my background with type languages working against me, with statically typed languages working against me, was the the document dot create element. The fact that the type returned was based on the string parameter passed into that function kinda blew my mind. This was not this was not c plus plus. They're like, you know, this it it the fact that, you know, they had to do it from the get go because otherwise create element would have been pretty useless and it's part of the DOM. But the fact that if you pass in a the string div, the the type the return type is is HTML div. But if you pass in span, it's HTML span. If it's a button, then it's HTML button. It's pretty insane to me.

Dan Shappir [01:00:11]:
Yeah. It's true. And I think that was from day 1.

Matt Pocock [01:00:14]:
Yeah. I think because that's that's another thing TypeScript does too is it just it gives you a lot of confidence in these DOM APIs. And some of the DOM APIs are pretty funky, you know, in terms of what they do.

Dan Shappir [01:00:26]:
You talked about jQuery. Did the dollar function in jQuery literally could accept anything, and what you passed in really determined what you got out. So the fact that it could infer what you got out based on on on the value of what you passed in was, again, pretty insane.

Matt Pocock [01:00:45]:
I can't believe they pulled it off, to be honest. Like, it is I mean, that you've you've got incredible team there. You've got Steve Luca. You've got Anders Heilsberg sort of working on this thing.

Dan Shappir [01:00:54]:
Anders is my god. You know?

Matt Pocock [01:00:56]:
Yeah. He's everyone's god. He seems like such a nice guy as well. And I've never met him in person, but I would love to.

Dan Shappir [01:01:02]:
I'll do a quick aside. You know that, you know, people know him from TypeScript and and from c sharp. But for me, he'll be forever the person associated with Tubbo Pascal. Oh, really? You know you know what Tubbo Pascal was or is?

Matt Pocock [01:01:18]:
Don't think I do. I mean, I I know the words, but I don't know the, the

Dan Shappir [01:01:22]:
way it was. So Pascal is a programming language that originated back in there. I don't remember if it's the seventies or the eighties, created as a strongly typed, language intended for teaching computer science in the universities. Quickly open sourced, which made it fairly popular. And what happened so we are we everybody working on on PCs back in the in in the day, back in the eighties or early nineties, was basically working in basic, which was a terrible programming language in a lot of ways. And then Anders, as this young man, released Turbo Pascal, which basically was an implementation of Pascal and an IDE. So it was both the programming language comp the compiler and an integrated IDE, which was miles ahead of anything else available at the time, ran on really low end PCs with blazingly fast compilation. So all of a sudden, we went I went from writing slow code in basic to writing super fast code in turbo Pascal in Pascal.

Dan Shappir [01:02:36]:
And it literally blew my mind, rocked my world, and made me into the developer that I am today in a lot of ways. So I Wow. So if I'm thinking about people that I owe my career to, Anders is high on that list.

Matt Pocock [01:02:50]:
Wow. I guess me too, man. Me too. I mean, I he didn't invent Tapscrip like a lot of people think, but his influence and his guidance over it I mean, he's still involved today, still making PRs today. He's an incredible guy.

Dan Shappir [01:03:05]:
Anyway, I so I have a few more questions. So we talked about these things that we like or did like or you like or don't like about, TypeScript. By the way, we are starting to run long. I don't know how to how much time you have. I would love to have as much time with you as I possibly can, but don't hesitate to let me know that you need to to stop or whatever.

Matt Pocock [01:03:27]:
I've probably I've probably got a hard stop at half past, so in 18 minutes, sadly.

Dan Shappir [01:03:32]:
Okay. So maybe we'll, you know, just need to schedule a follow on. So I'll I'll try to get 1 or maybe 2 more questions into there. My the next question that I have is, again, given that new versions of TypeScript keep coming out, what recent or upcoming addition to TypeScript has you the most excited?

Matt Pocock [01:03:56]:
Yeah. So the the thing that really got me excited was 5.5, and I wanna get this right. This was 5.5 TypeScript, which built or added something that I just did not think they'd ever add, which was inferred type predicates. This is something I sort of touched on earlier, which is when you have a a function that you can check whether it's, a string or not, a thing that's passed in. Before to get this to work in TypeScript, you would need to add this kind of slightly janky looking input is string return type, which checked whether the, basically sort of duplicated the runtime logic in the type level. And now you can just delete that and TypeScript will infer it automatically. This makes many things a lot easier. For instance, if you need to filter if you have an array of things that might be string or null, then you can actually filter those with array dot filter.

Matt Pocock [01:04:56]:
And then you can write a little function inside that dot filter. Basically, it just says a type of string a type of input equals string. And before, again, you'd need to do this janky little thing, but now you can just delete that and it infers it automatically. So it's just something that has a huge downstream effect.

Dan Shappir [01:05:16]:
So, basically, all the array utility functions or iteration utility functions now emit the proper type definition. I think I saw this as well, and it also kind of blew my mind. And it will be especially especially interesting to see if it is able to work with iterator helpers. Mhmm. If they get that to work, that will be, like, really insane.

Matt Pocock [01:05:42]:
Yeah. That's very cool. Yeah. This was made by Dan Vanderkam, who's, another Timescript author. I think he went on, like, a coding retreat, for a couple of weeks and just built the feature, his first ever PR to Timescript, and they accepted it. And it's now an incredible, incredible feature.

Dan Shappir [01:05:58]:
Which, again, I don't I don't think we'll have enough time to talk about it. But, again, one of the things that I especially learned to love about TypeScript is null safety. Yeah. People don't appreciate it that whether or not something is nullable is part of the type. And and if you pass a non nullable argument in, then you don't need to worry about it being null. So all the then if you're doing it correctly, all the the null errors that what's known as that, you know, that famous $1,000,000,000 mistake, even though it's probably way more than $1,000,000,000 by now. All those null references, if you do TypeScript correctly, it it's it just solves that.

Matt Pocock [01:06:51]:
And the fact it discriminates between null and undefined as well, which is that that's like a strictness setting, so you can basically sort of turn that. I always recommend you turn that on, and that's part of strict true, which is TypeScript's sort of basic, strictness level. The fact that it discriminates between those 2 as well is just it can feel extra strict sometimes, but it just saves you an extra level of pain.

Dan Shappir [01:07:12]:
Yeah. I do wish, you know, if I could have gone back in time to, 1985 and whisper on Brendan Eyck's ear, I would have said maybe not both, maybe just one or the other.

Matt Pocock [01:07:24]:
Yes. I strongly agree. And maybe just fix the thing where type of null is an object as well. That's bloody no.

Dan Shappir [01:07:32]:
You know, that's a funny one. That one actually slightly bothers me less, interestingly enough. I I get why that is. Let's put it this way. But but again, I think, you know, that's a different discussion. And and and there is one more thing that I would like to to touch on before we finish. And it kind of goes to the fact that as you mentioned, whenever converting a project, there's likely a utils folder. And on the one hand, you want to start there because probably everything is dependent on utils, but utils is probably not dependent on anything or at least on not on anything internal.

Matt Pocock [01:08:09]:
Mhmm.

Dan Shappir [01:08:09]:
Yeah. And and the the the question but on the other hand, it's the one that's most likely to need advanced TypeScript features like generics and and stuff like that. So you're probably also starting with the hardest part. And and my question here is so generics. Like, does every TypeScript developer need to understand generics? Or is this something that we can be relegated to a few, like, quote, unquote, TypeScript wizards? And and in this context, I think it was Theo, I I if I'm mistaken, then I apologize, who once in a video kind of made a distinction between the TypeScript at the app level versus TypeScript at the library level. That when you're working at the, like, the user land slash application level, you can be, you don't need all the fancy schmancy JavaScript TypeScript features. It's basically mostly simple or very explicit types. But when you work at the library level, then you probably need to get into various APIs and sorry.

Dan Shappir [01:09:28]:
Very you you need to deal with sophisticated APIs, and then you need stuff like generics. And we talked about Yeah. Co variant and contra variant and stuff like that. So do you agree with this distinction? Do you think it should exist, or should does every TypeScript developer need to know generics one you know, sooner or later?

Matt Pocock [01:09:51]:
Let me break this down in a couple of places. The first place I'll break it down is that generics as a concept, I think there's kind of 3 or 2 things in that, which is that there's generics as a consumer, which is basically the person consuming the functions, calling the functions. You need to know, for instance, how to pass a type to another type, which is generics. You know? So if you have an async function, you need to understand how the promise type helper works, which is, of course, a generic type. But then the thing that I suppose we're really talking about is generic functions, declaring your own generic functions, designing APIs. If you're in the business of designing an API and, I I mean, like, an API for a function that other people are going to call, then you will probably need some generics at that point. And that's when we start to get this sort of spectrum coming in of we've got the app developers on one side who are mostly just consuming generic functions. And then we've got the library developers on the other side who are creating the generic functions, you know.

Matt Pocock [01:10:56]:
And this sort of is is a nice feature of TypeScript, I think, because it means that the a lot of complexity can just be held inside those generic functions and then just used in a very simple way with very few type annotations by the app developers. I would say I think of there as being 3 places, 3 sites of 3 levels of, TypeScript wizardry, let's say, where you have the app developers on one side. You do have the library developers on the other side who had to deal with all sorts of stuff like infer and conditional types and TypeScript performance, you know, like, which is the performance of your types, you know, how fast does does your IDE update and things like that. And then I'd say that the utils folder is like a level in between. Well, you don't necessarily need and this was this is not my idea. This is actually author the Rocks' idea who's a great TypeScript, was on the TypeScript team, great TypeScript contributor. And the utils folder, I think you can get by with just a bit of TypeScript knowledge, especially now you have things like chat gpt with Claude, that can help you out a little bit with these. If you can declare a generic function, declare a generic type, I think that is going to really help you just in terms of your app development.

Matt Pocock [01:12:14]:
Because it's going to mean that you can design your types a lot better. You can make types that sort of flow in beautiful ways. You can make generic fun make functions that do what you want them to on the type level as well as the runtime level. And so you don't if you're starting and it's like your 1st month doing TypeScript, don't dive into generics immediately. You know, there's no need. You can just consume generics. Just do that. But I think that as your apps grow, as more code gets shared, more code goes into the utils folder, knowing this stuff is gonna just benefit you enormously.

Dan Shappir [01:12:49]:
Yeah. I think that's the key point. I think it's totally fine to start before you're quote, unquote, an expert. If we all waited to become expert before we actually started doing something, then we will never stop. Like, the the worst enemy of of good is better. You know, fake it till you make it and whatever is actually is actually a legitimate approach in this context. That said, don't stop. If TypeScript is a core part of your development process, then I think that you owe it to yourself, to your career, to your team, to your product to become as proficient as possible in it.

Dan Shappir [01:13:31]:
And I think that it's definitely worthwhile to put in the effort to go to websites like yours, to read the newsletters that you put out, to try things out, to make sure that you do understand, you know, how things actually work and and stuff like that. So as long as you, you know, say, okay. I am going to put in the effort to to fill in the blanks, I think it's a legitimate approach.

Matt Pocock [01:13:59]:
Yeah. And learning this stuff as well, learning the mental models behind it, they just benefit you so much when you're building stuff because you just you you don't get stuck so often. You know? You can just work your way through errors. You can understand what's going on.

Dan Shappir [01:14:11]:
Now if you've got another minute or 2, I I want to pick up one question that we got in in the in one of the chats. Let's see if I if I properly understand it or if you do. It's from either Pohwan or Pohwan. I hope I'm pronouncing it correctly. And he asks, how can we automatically convert TypeScript to runtime assertions? What are the options and the tool sets?

Matt Pocock [01:14:36]:
Yeah. So one key part of TypeScript understanding is that it just doesn't operate at runtime at all. Like, it's just It's gone. It's gone. It's just, you know, like, they're they're just cleaned out those types. And so there is

Dan Shappir [01:14:49]:
no iterate you can't iterate over like, a lot of people, like, say, like, hate the fact that you kind of define certain things, like, twice. Part once is tie is values and once in types, and one cannot can't I iterate over the type? You can't Yeah. Because it's not part of the runtime.

Matt Pocock [01:15:06]:
It's not part of the runtime. They just don't exist at runtime. And so this I think this question is sort of asking, how do I make a type and sort of pull it into the runtime? And you probably could with some kind of cogen library, you know, an AI could probably LLM could probably do it for you. But yeah. I mean, there's there's no, I I think people who ask this question are asking the wrong thing, which is instead of taking a type and putting it into the runtime, you should be thinking, how do I take the runtime and turn it into a type? Because there's a really nice operator called the type of operator in TypeScript, which it's same as the JavaScript operator, but sort of operates slightly differently, which just lets you basically if you're using something like Xod, which is a runtime validator, runtime schema library, then you can take that and you can say type of z dot schema, and it just gives you a a type out.

Dan Shappir [01:16:03]:
The simple example the simple example is the is keys. It's the fact that you can, use specify, like, an object with various keys, confer a type from that. So now you've got the actual object which you can use at runtime, but you've also inferred the type that you can use at, you know, build slash programming type.

Matt Pocock [01:16:27]:
Yep. Totally. A really good example is, let's say, you have an object of APIs that you want to hit with different sort of environments, attached to it. So you have your your QA environment, your development environment, and your production environment. You have that on an object. You can pull those keys off and suddenly you have a union of those three keys. So I call this derived types where you basically derive some sort of type from the type of thing. And this could be really powerful because it means that you don't need to maintain the type in 2 places.

Matt Pocock [01:16:59]:
Just add another key, you add a staging environment, and then that suddenly appears in the type. It's really, really powerful stuff.

Dan Shappir [01:17:06]:
So before we've really run out of time, if people want to get in touch with you to, you know, get on your newsletter, your website, your book, whatever, what's the best way to find you? How how how do we, you know, find all your stuff, excellent stuff that you're putting out?

Matt Pocock [01:17:23]:
Thank you. So this is, total touch script.com is basically the site where I put pretty much everything now. So there is a newsletter there. There is my free book on there, which I mean, a free book, it sounds like it's just sort of a cheap giveaway. It took me 9 months to write this thing. You know what I mean? Like and it's being released as a as an actual, paper book as well. And I've got a course up there, and there are tons of free tutorials and about 60 articles I've written up there. It's a it's a really solid resource.

Dan Shappir [01:17:51]:
And in terms of paid stuff that you put out, what do you what is there? What's the what's Yeah. What's available?

Matt Pocock [01:17:57]:
I've got I've got 2 courses really, or 2 level of courses. 1 which is, Pro Essentials, which is I mean, it's about 2 100, 240 exercises, I think, where basically just takes you from total beginner in TypeScript to, sort of like the bottom end of wizard, I'd say. So So cover generics in there. We cover, all sorts of stuff related to TypeScript. And then the other stuff, which is the the complete volume is I've got a series of really advanced, workshops, which I taught live, which are basically sort of, I turned into a self paced course as well. So the whole thing, I think it's about 500, exercises or so. Like, it's enormous great big thing. And, but that I love the exercises.

Matt Pocock [01:18:41]:
You can just sort of dive into them in in your lunch break, basically. It should take about sort of 5 or 10 minutes to solve each, and there we've gotten feedback that it's just like a really addictive process. You you just go bam, bam, bam, bam, solving all the exercises, and, and it's great fun.

Dan Shappir [01:18:55]:
And the very last thing before we let you go, is there anything interesting interesting that you're working on now, something that we can look forward to?

Matt Pocock [01:19:03]:
Well, I'm diving into the world of AI, I think, and I'm starting to find that I'm I'm someone who's kind of allergic to hype, really. I just hate the whole hype cycle for things like crypto, and and I I just want to get to the interesting stuff and the meat that's gonna kinda make me more money or make, companies more productive or, like, some somewhere I can provide value. You know what I mean? I don't want to to speculate on crypto rubbish. And AI is got a lot of hype around it, but it's also very, very real and based on a lot of good science. And, yeah, I'm finding it very, very interesting and potentially thinking about making something from it.

Dan Shappir [01:19:45]:
Oh, so very cool. So, you know, people use are used to us also having a pick section, but I think we've kind of ran out of time. I will love to have you on again. There are so many questions on my list that we didn't get around to, and we didn't speak about AI at all. Mhmm. So hopefully, I can get you on again. In any event, it's been excellent. I've learned a lot.

Dan Shappir [01:20:08]:
It's been such a joy speaking with you. I hope our listeners have learned as well. So thank you for coming on our show. And to all our listeners, you know, thank you for listening to us. And, again, reminder, if you're thinking about filling in the Java the JS survey, mention us, you know, given excellent content like this one. And thank you all, and goodbye.