DejaVue

This episode of DejaVue includes not only knowledge but also a certain degree of magic, as Alex and Michael meet up with the one and only TypeScript Wizard Matt Pocock. Together, they talk about how he became a full-time educator and what the pros and cons are, then of course discussing everything around TypeScript - from Types vs. Interfaces, any vs. unknown, Matt's ts-reset library, Flappy Bird in TypeScript and more amazing nuggets

Enjoy the episode!

Chapters

  • (00:00) - Welcome to DejaVue
  • (02:08) - How Matt came to join DejaVue
  • (03:03) - Becoming a full time TypeScript educator
  • (05:10) - What do you miss when doing full time content creation?
  • (08:16) - Being an employee vs. self-employed
  • (14:42) - Why using TypeScript?
  • (19:59) - TypeScript only for libraries?
  • (22:40) - Migrating JS to TS
  • (28:08) - The build/compile step
  • (33:20) - Types vs. Interfaces
  • (37:19) - Declaration Merging pitfalls
  • (41:35) - TS Reset and TS 5.5 improvements
  • (48:25) - TypeScript enforcing a way of programming
  • (51:18) - any vs. unknown
  • (54:25) - Wrapping up

Links and Resources



Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Guest
Matt Pocock
Full-time TypeScript educator and author of Total TypeScript
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Michael Thiessen:

Welcome to DejaVue

Alexander Lichter:

It's your favorite Vue podcast. You just don't know it yet. Or maybe do. Maybe you have a DejaVue, and we're back here with another amazing guest. But first of all, who who are we?

Alexander Lichter:

Maybe you don't see it right now. Maybe you don't see the video. Maybe you listen to us to these familiar voices, maybe you never heard before. Well, I am Alex, Alexander Lichter, a web engineering consultant and Nuxt team member, also doing a bit of content on YouTube and Twitch around the Vue ecosystem. I'm here with my co host, Michael Thiessen.

Alexander Lichter:

How are you doing?

Michael Thiessen:

I'm doing well. Thank you very much. I am a Vue educator, so I do courses, content, all that stuff. You can find me teaching things online wherever you are. And we've got our guest here, Matt.

Matt Pocock:

Hello, folks. My name is Matt Pocock. I am, I suppose, a TypeScript educator. I'm pretty noob in the kind of Vue world, but, you know, TypeScript gets everywhere, gets into every little crack and cranny. So I think, well, TypeScript's pretty hot on the Vue world too, so I'm kind of excited to talk to you guys.

Alexander Lichter:

Absolutely. Thanks, first of all, for joining the podcast. I mean, we we we had some cool guests on already but, you're definitely one of our of most favorite ones already. You've been, with Vercel before with, the XState core team. I remember stately AI and now you are known to most of our listeners probably as the one and only, truck TypeScript wizard, of course.

Alexander Lichter:

Sorry. And you you're teaching TypeScript around the world to all the people there.

Matt Pocock:

That's right. So, yeah, I was part of, the XState core team, and that's there were some really complicated TypeScript problems involved in there. XState is a pretty complex library. It it sort of lets you build state machines and state charts in JavaScript. And building those in TypeScript, especially, is pretty challenging.

Matt Pocock:

That got me pretty interested in TypeScript. It's got me interested in kind of developer education, talking about xstate. I got hired for Vercel quite briefly as, as a developer educator. And then I went solo talking about TypeScript full time, and this is what I do now, like, 9 to 5. This is my job.

Matt Pocock:

And to explain the trucking thing as well, this is kind of our origin story on this podcast, which is I thought it would be a great idea to do a stream where I just drove a truck. You know, I've got, like, a steering wheel. I've got a trucking game. You're a truck simulator too. And now it seems to have become like a part of my personality at least where Alex is concerned.

Matt Pocock:

Because Alex was on the stream, said, do you wanna come on this podcast? And, I couldn't say no. So, yeah, I'm the truck Timescrip guy apparently.

Alexander Lichter:

And I I hope I hope you'll do one of these streams at least, and hopefully more more again because a lot of fun, having awesome maybe a little TypeScript logo on the truck. That would be amazing and on brand. Yeah.

Matt Pocock:

It would be on brand, but I don't know if I wanted to be my brand. You know what I mean? I don't wanna be the truck guy. Like, maybe I can make it work, but I I feel like I'm too British, too posh to get that going. You know what I mean?

Alexander Lichter:

I see. I see. Then let's let's let's leave there as a little anecdote, and and come to the whole part of okay.

Alexander Lichter:

You do 9 to 5 content creation, courses, videos, lots of free content on YouTube, on on your Twitter, on your socials, all linked in the in the show notes and description as well. So how how did you decide to go solo?

Alexander Lichter:

Maybe let's let's start with this first of all.

Matt Pocock:

Yeah. Like, I was a teacher for a long time before I became a developer. I was a voice and accent coach, if you believe it, and singing teacher. So I was in London. I sort of went to drama schools, teaching people how to do Shakespeare and, you know, teaching singing, that kind of thing.

Matt Pocock:

And I when I became a dev, I always wanted to link up the 2 because I always loved coding, always loved teaching as well. And so it just made sense to bring them together. And I've been on my own, you know, running my own business for a long time, doing nowhere near as, being nowhere near as successful as sort of being in, like, tech and doing that kind of thing. So when the two things came together, it just felt really, really natural, and, I've been loving it ever since. I just love it.

Alexander Lichter:

Sweet. I mean, like

Michael Thiessen:

Mhmm.

Alexander Lichter:

Most most of people, also listeners, otherwise, you are also in the in the description and show notes. They they know your courses. I mean, you have some some free parts of it.

Alexander Lichter:

For example, also the Zot course and then, of course, all the TypeScript essentials and the the the whole, like advanced TypeScript parts with, like, generics and, and all the the little details of the language. So, it it has been it has been a blast and a and a huge success as well. Like, it's it's pretty amazing that, first of all, you said, like, okay, let's go. Let's combine the 2 things you like and then do the step of going full time into content creation, prepare the courses, and eventually make it work into a big success story around the world. So, yeah, props props to that.

Matt Pocock:

Thank you so much. It's been a it's been amazing. Like, I've partnered with some really good people and it's I've partnered with a guy called Joel Hooks from Egghead and Badass courses. Right? Yeah.

Matt Pocock:

Badass courses, and he has been extremely cool to work with. So I I credit him with a lot of our success for sure.

Alexander Lichter:

Perfect. We'll also definitely tag him somewhere. So he he will you'll get a big shout out for that too.

Alexander Lichter:

And, I mean, like, what on a way, we're all doing content creation. Like, Michael's doing also full time content creation in in the Vue ecosystem.

Alexander Lichter:

I don't do it full time, but who knows? Maybe one day. And, I think in a way we all know, like, the the challenges, but also the the great parts. So Mhmm. Maybe is there something that you're missing out compared to before, let's say?

Matt Pocock:

Totally. I mean, the grass is always greener. Right? But I you know what? I've been really wanting recently just to go back to being part of an engineering team again.

Matt Pocock:

That's where I felt my happiest, I think. Like, I just love being an engineer. I love fixing things, love, like, tackling problems. And I was thinking, you know, like, I I I build a lot for my job anyway, so I'm I'm kind of always sort of, like, tinkering to tinkering around with tools and, like, trying to get my processes better. But what I want is I just wanna be put into, like, a 10 year old legacy system, and I just wanna, like, just slowly make it better path like, battling all the politics and, you know, I'm I just miss all the things you're supposed to hate about engineering.

Matt Pocock:

You know, I miss, like, Jira. You know? Like, how can you miss Jira? Like, I do. Actually, I do.

Matt Pocock:

I miss, like, being that, you know, either.

Michael Thiessen:

Well, I I was gonna say I completely agree with you until the the Jira part. But

Alexander Lichter:

We will clip that. We will clip that.

Matt Pocock:

I'm gonna be on this linear, you know, like I miss the idea of Jira, but more than the execution.

Michael Thiessen:

I agree with you though, on the point of like those like really gnarly engineering problems. Like I get to play with the latest features and stuff and that's fine. I can, I don't have to deal with all this tech debt if I don't want to, but at the same time, you know, I'm building rather small toy demos most of the time? And they're not like that interesting. Like, you can only, on your own, do do so many, interesting things.

Michael Thiessen:

And so it that's something that I do miss. Yeah.

Matt Pocock:

Who knew that greenfield would get boring? You know what I mean? Like like,

Alexander Lichter:

it's too easy.

Matt Pocock:

I want a brownfield. The grass is always browner on the other side. You know what I'm like? Yeah. That's what I want.

Matt Pocock:

I want the gnarly stuff because that's actually where a lot of the juice is in terms of engineering, that where you can develop a lot of skill. I actually went and, I've been playing with this library called Never Throw recently, and I went and I did a couple of PRs for them. And, I just this morning, actually, I was I just did, like, 6 PRs just upgrading all of their old, like, libraries and dependencies and things like that. I just I go if I can't work on legacy code myself, I'd go out and find it, you know, like so totally. I mean, there's there's it's an emotional roller coaster doing content creation, I find, because it's so you push something out there.

Matt Pocock:

You've no idea of the feedback that's gonna come back. You don't know if it's gonna bomb. You don't know if it's gonna go crazy. And it's easy to tie your self esteem up with that too, you know, especially if you're supposed to be earning money from this pursuit. And, some, you know, some I just want sometimes something more simple.

Alexander Lichter:

And would you say that engineering is more simple, quote unquote, or maybe more like, you know what you get, let's say?

Matt Pocock:

Yeah. You're kind of like I mean, having a salary is, like, totally different to having you know, relying on self employed stuff for sure. Like, there's definitely I miss having a salary sometimes, just having that little bit of your brain turn off where you're constantly thinking about earning more or things like that. Yep. And, yeah, I I think that I don't know.

Matt Pocock:

I just I miss having colleagues. I miss, like, just working on a problem together. I don't know if simple is the right word, but maybe no. I can't think of a better one, so I'll stick with that. Different.

Matt Pocock:

Different. Yeah.

Alexander Lichter:

Different. Mhmm.

Matt Pocock:

Yeah. Michael, I don't know if you feel the same, like, if you're doing the same game as me.

Michael Thiessen:

Yeah. The the ups and downs, especially like, before I went full time, the ups and downs are definitely there. But once you once you have your entire livelihood based on it, then it's, a totally different thing because, you know, especially with projects that take, like these projects take on the order of months at least to to get out there. And so you're slowly watching your bank account dwindle until you launch this this new course or whatever. And so the at least that's that's the typical business model.

Michael Thiessen:

Some people do like a subscription or something like that, which, you know, I'm sure the grass is greener on the other side. So I'm sure there's, like, there's challenges with that too. But but yeah. Like, you know, there's making, you know, 80% or 90% of your of that year's income in, like, 2 weeks is both exhilarating, but also terrifying. So yeah.

Matt Pocock:

Absolutely mad way of doing things. But, yeah, that is that is the game for sure.

Alexander Lichter:

And I think also on the other hand, like, content creation, it's I don't know. If you go every day, you do a bit of programming. Of course, some days you're better and some days you might take longer for a bug. But in the end, you get you get a salary and you're good. And with content creation, it's not only the uncertainty of, like, how well it perform, but also people expect a certain level of quality and also a bit of innovation.

Alexander Lichter:

So

Matt Pocock:

Mhmm.

Alexander Lichter:

How to make sure you can be still innovative while, like, still keep going. And it's it's also, I think, in a way, it's it's very unrealistic goals to have, like, okay, always, like, the same quality, even better. There will be some things that that won't be well received. There will be ups and downs as they are in your your daily form as well. But, of course, it's a bigger impact if, like, hey.

Alexander Lichter:

That's that's where my, yeah, my my own money is on. Like, you know, if if that will continue, the the downtrend, what then? So, yeah, it's it's tricky for sure.

Matt Pocock:

I'm a huge fan of, of board games. And, like, in it's kind of like if you think of engineering as kinda like a board game where there's a little bit of randomness baked in a little bit. You know, you're drawing cards off a deck, but you basically know what's gonna be in that deck. But content creation is you're drawing cards off a random deck, like, which is your performance at the start of the day, and then you have no idea what the card is gonna do when you play it. You know what I mean?

Matt Pocock:

Like, there's randomness just baked in in so many different parts of the algorithm. And a lot of my job is trying to reduce that randomness, really, is trying to make things more predictable, knowing that when I put a certain amount of work in something, then it's gonna produce the thing. But you can't really like you're you're always gonna be in prey to your audience.

Michael Thiessen:

You know? It's very funny that you you bring that up, that that randomness because, it's not something that I'd like fully connected. But when I was working as a dev, getting a salary, one of the things that really bothered me, I guess, was that if I worked twice as hard or did work that was, like, twice as amazing, I didn't get paid twice as much. Mhmm. And and so that I I don't know what it was about it.

Michael Thiessen:

It just kind of like irked me. And so I was like, okay. What if I do my own business, then like, if it does twice as well, then Mhmm. I get paid twice as much. And you

Alexander Lichter:

twice as well as too as well. Yeah.

Michael Thiessen:

But then but then the thing is then there's way more randomness involved. And so it's like, you could do twice put in as twice as much work, do twice as good of a job. But, you know, if there's that randomness, you may or may not see those results.

Alexander Lichter:

So

Matt Pocock:

Do you want the fluctuation, or do you want the mean? You know? Yeah. Some days, I want the mean. That's that's all I want.

Alexander Lichter:

100%. I I also feel like in one especially with vacation, like, where I've been couple weeks ago now, it's just like you have this tiny part of your brain that's like, hey. You know what? How are things? Maybe we should put up some some content.

Alexander Lichter:

Why not start doing some planning? Hey. Could you reach out to someone to join the podcast? This and that. So there there are always tiny things like you can't at least for me, it's really difficult, like, fully shut it off.

Alexander Lichter:

On the other hand, it's also like is it is it in general possible, like, fully just shut off, do nothing? It's also tricky.

Matt Pocock:

Yep. I I've told the story on a different podcast before, but I went from being self employed as a senior teacher, for 6 years to then starting my first ever dev job, and that was my first ever full time job. And at that moment, I realized, oh, that little ticking clock in my head, that's gone. I can just relax. I can go on holiday.

Matt Pocock:

They'll pay me to go on holiday. What the hell? You know? Like, it's crazy. I can't be right.

Matt Pocock:

But, yeah, it's it's it's there for sure. I mean and I think it does help, you know, if you're constantly pushing yourself to be better, then even if you're in a full time job, you're gonna keep, like, trying to earn above the mean, essentially, and trying to push yourself above what's expected of you, and then you tend to rise quicker.

Alexander Lichter:

Yeah. Yeah. Also, motivation in general. Like, why why are you doing the things? Like, it's it's it's of course, also, you want to pay the bills at some point, but you're interested in some topic.

Alexander Lichter:

You're you're also, like, maybe people like your content because you can explain things very well because you're very entertaining, maybe both, maybe none of them, maybe just because it's hilarious. Who knows? But but they're there. And in the end, if you give the people something, I think that's also very rewarding intrinsic motivation. It would be like, okay, I can help people with that and also paying the bills.

Alexander Lichter:

Cool. So talking about helping people, there's also one thing that helped a lot of developers when it eventually came out, and that was TypeScript, obviously. That helps how people fix in bug, writing, like, writing better code. Some some would argue, like, oh, is it really better? We'll see that in a bit.

Alexander Lichter:

And I think most of most of the people listening or watching, they know what TypeScript is, but maybe it would be good to iterate on why should people use TypeScript.

Matt Pocock:

Yeah. So I've I've gone through many different versions of this over the years. I think the best way of talking about why you should use TypeScript is do you want your IDE to be more helpful or less helpful? Right? The IDE, your integrated development environment, the place where you write your code.

Matt Pocock:

Are you happy writing in an environment like Notepad? You know what I mean? Where you have no help whatsoever, no syntax highlighting, no whatever. No. You're not.

Matt Pocock:

Right? You want something that's a bit better. You want syntax highlighting. You want, let's say, autocomplete on things. You want to, you want to be able to navigate different files and stuff.

Matt Pocock:

You know? And the more powerful you want your IDE to be, I think the better. You know? And there comes a time with JavaScript and a limit with JavaScript really, which is you realize, right, there are certain things I want my IDE to be able to do that it can't do. When I'm working with a library, I want to be able to, like, see all the parts of that library and, like, autocomplete my way to various functions.

Matt Pocock:

When I call something from that library, I want to know if I'm getting it wrong. You know? And you just can't do that with JavaScript because it has no idea what type anything is supposed to be. You know? And so without types in a language, there's no way for powerful features like autocomplete, rename symbol, go to definition, things that are like table stakes in other languages, like c sharp or, you know, like, you know, various strongly typed languages.

Matt Pocock:

You need a layer on top of JavaScript in order to make your IDE more powerful, And that's what TypeScript is. So it's not types for type sake. You know, it's not like a strongly typed language in the traditional sense of the word. Those types disappear at runtime. They're totally gone.

Matt Pocock:

But what it is is just a layer on top to make your IDE way more powerful. So you get errors inside your IDE. You've got all these features like autocomplete, go to definition. You can explore what type of function it's supposed to take. It's it just makes everything so much better.

Matt Pocock:

And I think makes you code so much faster because it makes the feedback loop so much shorter. Because instead of having to flit between the docs and your IDE or the browser and your IDE, you're just in your IDE for longer periods just getting that feedback.

Michael Thiessen:

I've noticed that with JavaScript, sometimes you have to jump through to a method and then go back up a level, hunt down where where the data originates from Yeah. To figure out, okay, was it items or item? No. And like, what was or like some, like, you know, subtle variation and you're like, okay, it's not working. What's what's going on?

Michael Thiessen:

And you have to like or you console log the object out to see what is what's going on here. Yep. And that's just, it's a time time waster.

Matt Pocock:

You know? It forces you to do so much work like JavaScript, I mean, forces you to do so much more work just in producing your code. Yeah. And especially when something goes wrong. You know?

Matt Pocock:

When something goes right, you know, when you know that library inside out, when you can just get a feel for the code you're writing, maybe you've written a similar feature before, then JavaScript and TypeScript are pretty similar, right, in terms of the amount of time it takes. But TypeScript is just there helping you when things go wrong, you know, and just giving you little hints. And, of course, when you come to change your code, that's when TypeScript is insanely powerful because, you know, if you need to refactor ID to item ID, let's say, and that's in a 100 different places in the code base, a find and replace is not always gonna cut it you know, because ID might be used in various different situations. And so you can just do a rename symbol, you know, f 2 or whatever, and just bam, and it instantly changes everywhere. So an an hour long job in JavaScript just literally takes 2 seconds in TypeScript.

Alexander Lichter:

I still like the highlight that you that you meant before. Like, oh, yeah, if you have, like, C Sharp or Rust or whatsoever, they're like they're all like, oh, yeah, you can do that with our language. And then JavaScript is like, oh, yeah, we need this little layer on top because, well, JavaScript is not strongly typed. I mean, we have, like, data types. Like, we have number, for example, string in in JavaScript.

Alexander Lichter:

But, yeah, with with TypeScript, we can not only actually express them, but also more complex types. So and Yeah. I also like the the take of, like, okay, think about your IDE first, not even think about the CI or, like, runtime versus built. I'm just like, okay, very simple step. You want to have, like, the the most, like, the most helpful IDE possible.

Alexander Lichter:

Right? You like you want to, like, ship features as fast as possible. So you want to write them faster without, like, scavenging the docs through a library. Just like, okay. Hey.

Alexander Lichter:

What's the method? Dot oh, there it is. Very simple.

Alexander Lichter:

And I've given some some, like, JavaScript workshops to also, like, showing people some TypeScript and then people like, yeah. Okay.

Alexander Lichter:

But and the library authors, they can use TypeScript. It's fine. Why do I have to use it for my, like, end application?

Matt Pocock:

Yeah. I mean, the cool thing about that is that yeah. If we make it sort of, like, distinction between library and application, You know? You imagine that you have your application and then sort of above it in like a a tree, you know, you've got all of this kind of like this library that depends on this library, depends on this library. You know?

Matt Pocock:

And so the connections between those libraries sort of they need to be kind of like guaranteed, you know, like, so they need to be type safe, as we say. And then right at the bottom, sure, you're consuming a bunch of libraries like that, but this could technically just be TypeScript or JavaScript. Doesn't matter. What I like to think of is, like, you know weirdly, like, if you're writing JavaScript now, the thing that's in the background helping you kind of, like, do autocomplete in JavaScript and, like, make sure that your ID is as powerful as it can be with JavaScript. It's actually TypeScript in the background, weirdly enough.

Matt Pocock:

So there's the TypeScript server bundles in with Versus Code, Visual Studio Code, which basically just runs in the background and looking at your JavaScript code. Because every JavaScript program is technically a TypeScript program. It just doesn't have any types in it. You know? And so, yeah, you totally can if you want to.

Matt Pocock:

But I tend to find I code faster, and most people code faster when your ID is more powerful. So if you're happy with JavaScript, if you feel, yeah, I just want to stick with dynamic typing, don't want to bother with all these extra type annotations, then, yeah, stick to JavaScript if you want to. But if you're a library author, you basically have to use TypeScript because it means, like, if you don't use TypeScript, then people have to sort of patch declarations on top of your library. It just makes everything so much easier for the consumers of your library, whether they're in TypeScript or JavaScript.

Michael Thiessen:

It's interesting that JavaScript applications or, like, JavaScript code is valid TypeScript. I think Evan You was talking about future version of Vue and making it so that just by default, everything is TypeScript as opposed to right now where it's opt in. But if you're writing JavaScript in your Vue component, then you wouldn't you wouldn't even notice because, I mean, it just it still just works the same the same way.

Matt Pocock:

Totally. You can just disable the transcript rules, you know, TypeScript no check or whatever. And then, yeah, just writing JavaScript in a, I assume maybe a dot v

Alexander Lichter:

file or whatever. I mean, the same works with normal TS file. Like, even there you can say, okay Mhmm. I have my TypeScript file. It can be just JavaScript and it's fine.

Alexander Lichter:

Especially for migrations, I think that's really sweet if you have, like, a dot JS file. You name it dot dot TS and you can, like, slowly build up the types and and add things, which I mean oh, I see. Matt Matt, you have some opinions on that. Now I'm curious.

Matt Pocock:

I do. Yeah. I have some very strong opinions on that.

Alexander Lichter:

That's what we're here for.

Matt Pocock:

I mean, the if we could dive deep into how to migrate a JavaScript file a JavaScript codebase to a TypeScript codebase, because there's definitely a right way and a wrong way to do that. Do you want it done?

Alexander Lichter:

Let's let's go for it. Yeah. Let's let's see why my way is the wrong way.

Matt Pocock:

Well, so your way is the way where you basically just turn all the JavaScript files into TypeScript files. And if we think there's kind of, like, 2 sliders, you can sort of, like, move up and down. One slider is the strictness slider, which is you basically and the other slider is the JavaScript to TypeScript file slider. So the more the JavaScript to TypeScript file slider is high, the more TypeScript files you have, the higher slider is, the stricter your TypeScript is. You can configure TypeScript by going into tsconfig.json and kind of like fiddling with the with the settings there.

Matt Pocock:

Now what I tend to recommend is setting TypeScript at your proper level of strictness, you know, your desired level of strictness, and then just slowly, PR by PR, just changing JavaScript files into TypeScript files. Right? Because then what you're doing is the way you would, like, cleverly do this is you would do a dependency graph of every single file in your repo, and you basically go, okay. What's the file that has, like, no dependencies and that lots of other files depend on? You do that one first.

Matt Pocock:

Because then, ideally, no TypeScript file should ever depend on a JavaScript file. So no typed file should have depend on an untyped file because then that that's just nasty. You would just end up, like, doing any in all sorts of places. It's no fun. The way that you described is going the other way, which is to convert everything over to TypeScript and then slowly raise the strictness level.

Matt Pocock:

Now if you think about that, the strictness level is global, affects the entire project. So you need to basic and there's no real clever way of, like, just going I mean, you sort of can do it, but it's it's really hacky, of just saying, okay. Only these files should be strict and these files shouldn't be strict. You can do it with, like, project references with, tsconfig.json in a certain place, but it's not very fun. So I tend to recommend, basically, whack up to the level of strictness and then just go file by file by file by file.

Matt Pocock:

This is how Sentry did it. Sentry converted an enormous code base. There was a great article about this, which I can send you after

Alexander Lichter:

that. That. Yes.

Michael Thiessen:

For sure.

Matt Pocock:

Yeah. It's really, really good. Basically, they just did it over a period of, I think, like, a year, like, you know, 18 months or something, slowly doing it PR by PR while still shipping features, you know, which is the way to They can't do big bangs. They still

Alexander Lichter:

have doesn't work.

Matt Pocock:

Yeah. Cannot do a big bang. And with a strictness setting, that's a big bang every time you change the system.

Alexander Lichter:

You have to touch all the files again. And to be fair, I mean, I I think we're we're on the same page there. So, like, if I think if you want set your tsconfig up, like, okay, hey, should we, like, like, check check the indexes? Should we, like, allow, any what what are our rules and then migrate files step by step over no matter if they're component files, if they're JavaScript files, like whatever it is. And with, as you mentioned, the dependency graph analysis.

Alexander Lichter:

So you really make sure, oh, it's not just a random file and then you have, like, weird, weird scenarios like, okay, I have to type in any here and then maybe I revisit and I will never do it. That's I think that's that's a that's a very good strategy that, that will make things easier. I also remember, like, Stripe was also, like, moving to TypeScript as well with, like, an enormous amount of files. So, and and they they pursued a similar strategy, which, I also think, like, it's the Interesting. That's the way to go.

Alexander Lichter:

Yeah.

Matt Pocock:

Yeah. It's totally the way to go. So yeah. I'm not I'm not saying you were advocating for the wrong way, but, yeah, I just something that would No. I I think my head and I just start shifting message.

Alexander Lichter:

It's really good because lots of people I still see like, hey, TypeScript now, like, that's more than 80% of the people, like, hey, TypeScript is good and every framework has a wonderful integration with it. And there is, like, no, let's say, real competition. I mean, Flow still exists, but not that many people using Flow compared to TypeScript. Then people like, oh, hey. Okay.

Alexander Lichter:

Maybe you should try it out. Maybe we should move over. So, I think it's definitely something something valuable to think about for people. Might be in a migration right now of, like, okay. How do we do it the best way without, yeah, halting production or without, like, wasting too much time touching the wrong files first?

Matt Pocock:

Yeah. And if you're in a production code base, you're basically always in a migration. You know what I mean? Like True. Everything is slowly migrating, like, all the time.

Matt Pocock:

So It's

Alexander Lichter:

always legacy as well.

Matt Pocock:

I miss I miss it so much. I miss it. That's what I miss.

Alexander Lichter:

Oh, wow. I can bring you on to some very nasty ones if you want to. Just have a little look into.

Matt Pocock:

Let's turn into a live coding session. Absolutely. I'm so down for that.

Alexander Lichter:

That would be that would be really fun. It could be another live stream for sure. Also, maybe get in touch with a little bit of Vue and and your opinion on that. Like, there are there are really cool things with, like, Vue and the Composition API of, like, generic components because you can write JSX in Vue, but Vue components are are lots of fun as well.

Matt Pocock:

Yeah. I saw I saw there was some custom syntax for that, I think. I do keep keep up with that a little

Alexander Lichter:

bit of you,

Matt Pocock:

but no. I've I've never written in production, so I can't claim to be an expert.

Alexander Lichter:

Maybe maybe one day it could be a a a fun little thing. So definitely let us know when you're after that. Yeah. When when there's time. Sounds good.

Matt Pocock:

When there's time.

Alexander Lichter:

So. There is there is one more thing that personally, I I heard a lot with, like, people having this legacy code base, and they let's say, they don't even use a framework. Right? They use, I would say, vanilla JavaScript. I don't really use jQuery Right?

Alexander Lichter:

And jQuery and TypeScript's a bit tricky. But let's say they even have, like, a vanilla JavaScript with, like, imperative DOM API. And I know lots of people, then, like, don't do the modern way of, like, hey. We have a build step and a CI, but just, like, the the old school way of, like, here is my FTP client. Here is the JavaScript file.

Alexander Lichter:

I move it over. Yeah. And usually, it was like, oh, yeah. They have you have the build step there and people like, oh, yeah. Okay.

Alexander Lichter:

Cool. But what if in 1 year, the build step doesn't work anymore because you need new node version, update this and that and that. So how how would you say, you could tell the people that are, like, afraid of, like, the build or compile step that TypeScript more or less introduces? What could you tell them to maybe ease their their fears?

Matt Pocock:

Yeah. I mean, that sort of FTP, like, you know, sort of bung something up on a server, like, that's not the main use case when I think of, like, no compile steps. The one that really comes to mind is actually with, like, full stack developers and, like, Node. So for instance, with Node, like, you can write dotjs files and then, you know, like, you can basically it just simplifies so much. You can just run those source files with Node.

Matt Pocock:

You can debug them really easily with the Versus Code debugger. Don't need to set up anything complicated. It just works. Like, I sometimes do reach for that myself. Sometimes I don't really want the build step because Node I mean, actually, they did ship something that sort of runs TypeScript files recently.

Matt Pocock:

But until recently, Node could not run TypeScript files. So you'd have to turn them into JavaScript files first. It's horrible build step, as you're talking about, in order to kinda get it working. So what was your question? Something about, like, allaying fears?

Alexander Lichter:

More or less, what if people say they don't want that build step? Let's say they wanna just, like, build less. But also Yeah. I mean, in a way, if you introduce TypeScript, it's like it's a dependency, of course. If you use a framework, it's also dependency, obviously.

Alexander Lichter:

But then people like, okay, the same code should still run-in in 5 years, let's say. And I don't want to rebuild it and say, like, okay, the node version doesn't run there anymore, so this and that.

Matt Pocock:

Yeah. And I've been there as well. Like, it's not fun. And every dependency you bring on to your application, essentially exposes you to the passage of time. You know?

Matt Pocock:

Like, time will just make fools of us all, and it makes fools of every dependency that you have. You know, I moved a friend's website over from Gatsby to Next, I think, recently and relatively recently. And just just literally because there were so many dependencies in Gatsby, I couldn't be bothered to figure out, like, how they all fit together, whereas Next was just one dependency. And so I think that's the real question we're gonna be thinking about here is, like, how many dependencies are you introducing when you, move to a build step? Because if you're wanting, let's say, ESLint, you know, that's like a plug in architecture.

Matt Pocock:

That's a lot of different plugins that will all get brought in. Whereas if you move to something like Vite, for instance, that's kind of just one dependency, you know, and it's kind of all bundled together. So if you update your Vite version, probably it's gonna work with everything. So

Alexander Lichter:

I'm not sure

Matt Pocock:

what I would say because, like, if you're really set on buildless, if you feel like the entire revolution in CICD, in testing, in making sure your code is doing what you think it's doing has not produced any worth for you, then I don't think I'm gonna sell you on, like, TypeScript being a cool IDE, like, extension and, like, making that better. I think there's there's just a fundamental idea at the roots of all of these improvements, which is that we need safety nets, you know, as developers. We need safety nets. Like, I I I don't want to be walking up a cliffside, like, possibly, like, slip and fall and just sort of break production. You know what I mean?

Matt Pocock:

I want there to be something that's gonna give me a warning before that happens. I want to feel sure footed in where I'm going because then I don't need to sort of, like, stumble along the cliff. I can just run. You know what I mean? I because I know that if I fall, something will catch me.

Matt Pocock:

So that's my thinking there is that I just love TypeScript, especially when it runs in CICD because I can get a warning before my users get the warning or before it breaks for my users. So for me, it's all about users, like being in service to giving them a good time. And often if it's like a really important application, like a a financial application and stuff, I bloody need those guardrails. I need those safety nets because if I don't have them, like, my job might be in jeopardy, you know what I mean, if I if I break something serious. So that's how I feel, is I'm not sure that if you're really into that build less stuff, I can convince you, but that's my feeling.

Matt Pocock:

I wish I ended that on, like, a more hammer line. You know what I mean? Like, I just

Alexander Lichter:

No. That that was perfect. That was great.

Matt Pocock:

Hopefully, you can, like, make a social clip

Alexander Lichter:

of it

Matt Pocock:

before I just sort of stumbled into oblivion.

Alexander Lichter:

No no worries. We'll we'll we'll clip it. That will be that will be lucky.

Michael Thiessen:

So I have a question for you of something that has confused me for a while, and I'm sure confuses other people with TypeScript. And that is this whole types and interfaces thing. Mhmm. So they feel like they're basically the same thing. And I think at one point I read an article that favored interfaces, and I can't remember the argument.

Michael Thiessen:

But now I just remember, maybe I should use an interface instead of a type. And so that's basically my, my my thought process. And so I was I was wondering if you could, yeah, ex explain those differences and when do I use one over the other?

Matt Pocock:

Yeah. So, yeah, we're kinda talking about, like, types versus interfaces when you're declaring, like, a single object type. You know what I mean? Like, the props that your component should take. If you you call them props.

Matt Pocock:

Right? Yeah. Yeah. So the props your component should take, you know, is it still defined props? Is that still Top

Alexander Lichter:

of table. Exactly. You you're spot on, man.

Matt Pocock:

Nah. Nah. So, yeah, how do you declare that? You know, you've got actually 3 options. You've got either, you can either, like, pass it directly to define props, so using an object literal, or you can extract it out into a type.

Matt Pocock:

So, obviously, type my props or whatever and then declare that. And then you've got interface my props, you know, and you stick it in an object. So let's just set out the the game as it as it were. You've got types can basically express more things. You know?

Matt Pocock:

So you can express union types with types, whereas interfaces can't do that. Types can express like strings and numbers, whereas interfaces sort of can't. But interfaces can do a couple of things that types can't do. So I don't think of there as being like a difference really when you're just expressing a normal object type. They kind of, like, perform the same.

Matt Pocock:

They do the same job. The difference is when you want to combine 2 object types together. So when you have, let's say, let's say, a base user type, you know, and you wanna do a little bit of inheritance. So you have your base user that has, like, a ID and name, and then you have, like, a user with email, for instance, that just sort of adds an email onto it. What you could do is you could basically use an intersection type, an and operator, and ampersands are basically just go and smush them together.

Matt Pocock:

Or you could use interface extends. An interface extends, basically, you declare, 2 interfaces, let's say, and one interface extends from another. So they've got a hierarchical relationship. So interface extends is much better than the and operator. Much, much better because you get a lot more guarantees there.

Matt Pocock:

If I have an ID of string on the base interface and then have an ID on of number on the one that extends from it, you actually get a warning there when you use interfaces. But with a type, you actually don't get a warning. So it lets you smush together 2 incompatible objects. So you get ID of string and ID of number. Like that, you actually end up with ID of never.

Matt Pocock:

But it only sort of tells you that further down the line when you go to use the object. So interface extends is much better than type, but type can express more things. So if you want to do any kind of, like, hierarchical stuff, I would recommend using interfaces. If you want to just be more expressive, I suppose, or like do really anything else, like express union types, then you can use types. There are, like, several other differences as well.

Matt Pocock:

They treat hovers slightly differently. There's an implicit, what am I saying, index signature on types but not interfaces. And you can use declaration merging on interfaces but not types. So we can get into that if you want to, but that's like the high level view.

Michael Thiessen:

I mean, that yeah. That makes sense to me. That's that's a pretty good answer.

Alexander Lichter:

I think the declaration merging is especially something if you work in the front end once again and you have, like, an interface called form data. I love that example so much. Like oh, yeah. And, accidentally, you have all these things because it merges with the declaration from from the lip from the lip e s 5 or whatever. Yes.

Alexander Lichter:

Hopefully, not not on e s 5. Like, e s 2023, 2054, whatever. So, like, with declaration that that TypeScript basically provides for the actual form data type for form data in the browser.

Matt Pocock:

We we should explain the mechanics of that as well. So what declaration that's a really good, example. What declaration merging means is that 2 types with the same name. If you try to do that, you'll get an error saying duplicate identifier. So you cannot create 2 types with the same name in the same scope.

Matt Pocock:

In different modules, it's fine, but in the same scope, no. With interfaces, they merge together. So you create 2 objects with the same name and they merge together. So weird. You will get errors if you're doing compatible stuff, but that's so weird.

Matt Pocock:

The reason I don't really mention that as, like, a top level problem is, but the form data example is really good, is because you can actually lint that away. So with ESLint, you can basically say, no. You shouldn't be doing that. You know? TypeScript has that for a few reasons.

Matt Pocock:

But what you're saying with the form data, which I never actually thought of, never happened to me before, is basically your local interface of form data merges with the global one, which is so grim because you end up with all of the stuff that's on form data plus the Exactly. Intent. Yeah.

Alexander Lichter:

Feel free to steal that for for the next video, at least. Alright.

Michael Thiessen:

I'll write

Alexander Lichter:

it down here. Yeah. No. But, like, it it's it's so painful. And then when you understand, okay.

Alexander Lichter:

Hey. That's declaration version. And if you use type, that will never happen to you. Then, like, oh, that's that's good to you. Never you never forget it.

Matt Pocock:

Yes. Exactly. And so I go back and forth on, like, what the default should be, you know, because, like, sometimes, declaration merging happening declaration merging happens to me. Like, I'm in a 4000 line file. I accidentally named 2 things the same.

Matt Pocock:

And I just think, oh, I never want that to happen again. I'm using types by default. But then I realized, god, interface extend is actually so much better than, using the ampersand operator intersections. So I'm gonna just use interfaces by default. And so I genuinely just go back and forth on what I recommend, and this is why this topic is something I get asked on, like, every podcast.

Matt Pocock:

It's like, it is genuinely tight. You know? It's close. And so it is worth discussing and knowing all of the the ramifications of choosing 1 or the other.

Alexander Lichter:

And you wouldn't but you wouldn't say, like, use either types or interfaces. Like, it's it's fine to mix them whatever you wanna do instead. It's more like hierarchical stuff or like more like, okay. Perfect. That's great.

Matt Pocock:

Yeah. People people go really hard on, like, no. You have to be consistent. You know what I mean? You don't have to be consistent.

Matt Pocock:

They do different things. You know? Like, it doesn't doesn't matter if you have a type. Like, interfaces can extend from types. Types can do a lot of stuff that interfaces can do.

Matt Pocock:

People go nuts about consistency, but, no, today doesn't matter too much.

Alexander Lichter:

Though I think in a way, if you have rules, as in as you said, like hierarchical things using interface, that's also a way of consistency. It's more like like some rule of thumb so people are not like, oh, half an hour time to decide, is it a type or interface? Well, like, just use whatever. And if it doesn't work, then, like, if it doesn't fit in East, then just change it. It's fine.

Matt Pocock:

Yeah. I'm pretty sure there's a lint rule in, like, TypeScript ES lint for instance that just says, this you could express this with an interface instead when you have, like, a intersection. I can't remember quite what it is, and it might not even exist. I might have just invented it in my brain, but, it's useful if it exists.

Alexander Lichter:

That's true. Yeah. We'll we'll check that after the show. And if it's the case, you know where to find it.

Matt Pocock:

But hopefully, that sort of puts it to bed for everyone. Maybe it doesn't.

Alexander Lichter:

I mean, there were always people be like, yeah. But what what of this scenario? What what is what is here? In the end, I think it's it's good to know the differences and the benefits. Like, I I also remember all the hovers about, like of the, like, oh, yeah, the the intersection types and, like, what is it now?

Alexander Lichter:

Can you please tell me instead of, like, just showing the type and the other type? But yeah. Fair.

Matt Pocock:

Yeah. They do they do hover differently. We could talk about that if you fancy, but that is particularly nerdy.

Alexander Lichter:

Then then let's maybe continue with some for more TypeScript features that are pretty amazing because maybe maybe some people, some listeners, some viewers know one of your libraries that you wrote, Matt. So we're not only talking about x state where you're on a core team, but we are actually talking about tsreset. Maybe you could briefly describe what tsreset is and then maybe some things we hopefully won't need anymore in the newest typescript version.

Matt Pocock:

Yes. So TS reset, what it does, is TypeScript ships global types along with your project, basically. So it ships various, what are called declaration files. They explain what JavaScript is sort of doing. You know?

Matt Pocock:

So it has like if if you're targeting in your TypeScript, let's say, ES 2023, then you have access to string dot replace all. You know? Whereas if you're targeting earlier than that, you don't have those methods. And so TypeScript has a way of basically making those methods available to you. And if your if your code is supposed to be running in the DOM as well, which most of your apps are, then it has you know, it lets you access window and document dot create elements and all that sort of stuff.

Matt Pocock:

So, I think that those global typings can be improved a little bit or tweaked in certain ways. And there are various global functions that sort of behave oddly in certain situations. The classic example is, when you're filtering out an array of stuff. So let's say you have an array of numbers, but some of those numbers might be null. Right?

Matt Pocock:

So you've got an array of number or null, and you do a filter function. So you do array dot filter, and then you pass it Boolean, not like true or false, but like Boolean with a capital letter. What this does is it will filter anything out that isn't truthy. So you're gonna end up with basically all the nulls gone because null isn't truthy. You're also gonna end up with 0, like, being filtered out as well.

Matt Pocock:

But then which is, you know, pro and con. Maybe you don't want 0 for whatever reason. But then the type that's produced by that so, obviously, at runtime, that will happen. All the numbers and nulls will will despair. All the nulls will despair.

Matt Pocock:

But on the type level, TypeScript doesn't know that that's what's happening for some reason. They just haven't sort of, like, patched that together. That's not in the global typings. And so you'll end up with a type of number or null in there even though null can never exist in that array. And so ts reset, it does a couple of things like that.

Matt Pocock:

It tweaks a club couple of the global types, makes filter work with filter boolean, and it makes, dotincludes work a bit better in various situations, makes local storage a little bit stricter. It makes a few things just a little bit better. And this has been, like, wildly popular. It's been my most popular library by far. I've got a few little utilities here and there, but this is the one that's, just gone nuts, really.

Matt Pocock:

I think it's up to, like, 300,000 weekly downloads on NPM or something like this. It's crazy. And, yeah, this is this is basically what ts reset does. Now you're alluding to something that came out in TypeScript 5.4. Was

Alexander Lichter:

that 5.5, which I fully remember. You know that.

Matt Pocock:

5. Yeah. I is it 5 point I think it's 5.4. Oh, no. 5.5.

Matt Pocock:

It is 5.5. Which is that there's this whole wonderful feature that got added, by an amazing author called Dan Vanderkam, who wrote a brilliant book on TypeScript. And that's in its second edition now called Effective TypeScript, very much worth a read. And what he added to type he basically made a PR to TypeScript. He went on a retreat, like a coding retreat, and he just made a PR to TypeScript.

Matt Pocock:

And PRs to TypeScript from outside the core team, like, major ones like this, very rarely, like, get accepted. But this one was just like and it's fantastic. What it does is basically before this, if you had, like, let's say you were checking if a value was a string. Right? You know, it's coming in from an external API.

Matt Pocock:

I don't know where it's coming from. You need to check it's a string. You could create a reusable is string function that just checks inputs equals or type of input equals string. Now if you use that function, if you didn't wrap it in a function, if you just inline the check, just that type of check, TypeScript would infer it nicely. But if you wrap it in a function then use the function, it wouldn't infer it.

Matt Pocock:

So the thing would still be string or null or something. You know? But with Dan's change, inferred type predicates in Timescript 5.5, it does check it and it checks it automatically. And this means that things like, filter Boolean, you know, filter Boolean technically still doesn't work, weirdly, still doesn't work. But you can do by filter, passing in type of array member equals number.

Matt Pocock:

And so you're checking in that dot filter whether the thing that's being passed in is a number, and then it will infer it properly for you. So, yeah, I mean, incredibly cool job by Dan. It's one of the coolest TypeScript features I've seen in the last couple of years, really.

Alexander Lichter:

I think the same

Matt Pocock:

yeah. It's it's just amazing. And so TS reset still has a place, like but TypeScript is so called to see TypeScript itself kind of like catching up to it in terms of what you can do. And if anything, I think I think if if inferred type predicates had existed when I was thinking about TS reset, I probably wouldn't have made it. You know what I mean?

Matt Pocock:

It's like, it's that good. You know? And, like, I think actually doing that type of check is probably even better than filter Boolean because you get you don't get the zeros filtered out. True. It is an amazing change.

Matt Pocock:

So cool.

Alexander Lichter:

And would you say, like, if more, let's say, changes in TypeScript, ideally, the TS reset would be obsolete at some point if, like, all the things that Yeah.

Matt Pocock:

Yeah. Yeah. Totally. I mean, I think a lot of the things that are in TS resets are not like that in TypeScript for a reason. You know?

Matt Pocock:

So, like, something, or they're arguable on TypeScript just sort of landed on the other side of the debates. You know? So I think some of the things in ts reset, will never change in TypeScript. TypeScript is sort of quite hard to change the global typings in TypeScript because then you just sort of break a lot of stuff. You know?

Matt Pocock:

But yes. I'm not sure types TS reset will ever be obsolete, but I think the need for it will definitely, diminish over time as TypeScript improves because it is improving all the time. Their cadence of release is nuts. They are releasing stuff all the time. And, yeah, this this one especially was a doozy.

Alexander Lichter:

100%. Like, when I saw that PR landing, I I remember, like, all the conversations around it because it's it's very unintuitive for someone that, like, learning TypeScript can be like, okay. I use a filter here. I know there won't be any like, there will only be numbers in there, right, with just, like, type of number. Why doesn't TypeScript know?

Alexander Lichter:

Or, like, same same with, like, object keys, object values. Like, I think there are lots of things where when you program JavaScript and all the freedom of, like, a not strong in typed language and be like, okay. I I take objects. I mangle them around somehow. And then you go to TypeScript and you're like, wait.

Alexander Lichter:

Now I have to, like, cast things because TypeScript doesn't know anymore. Like, in a way, TypeScript is forcing you into a a certain at least tiny tiny degree in a certain programming style to be more strict with what you do yourself. Would you see that as, like, a as a pro, as a con to both?

Matt Pocock:

Yeah. I mean, it's definitely true, isn't it? What like, your premise is absolutely correct is that while, like, TypeScript basically supports a subset of what JavaScript can do. You know? If you're writing in JavaScript, you can do a lot more different patterns, a lot more crazy stuff, implicit stuff that sort of don't need types than you can, when you're using TypeScript.

Matt Pocock:

You know? And I would argue it is a good thing to be restricted. You know? Like, if you think of a language like Go, what everyone says about Go is that it's extremely restricted in what you can do. Like, there are very few patterns you can actually get away with.

Matt Pocock:

You have to check all your errors all the time you have to do. You know. And so every Go app is like a boring app, you know. Like, there's there's no fancy stuff happening in Go. It's all just real dull.

Matt Pocock:

I mean, that's what people say. I've never written written in Go, so I'm not sure if it's true. But that's kind of what writing like a TypeScript app is like. Now you can get away with more stuff in TypeScript.

Matt Pocock:

TypeScript has an extremely dynamic type system.

Matt Pocock:

Its type system is actually Turing complete. You know, you could do all sorts of crazy

Alexander Lichter:

tic tac toe and something in TypeScript. I've seen I've seen so many different things. Yeah.

Matt Pocock:

Yeah. So, I mean, the the canonical crazy example is someone, made a runtime for the TypeScript, type system, and they made Flappy Bird in types. Wow. Yeah. Yeah.

Matt Pocock:

Bonkers. So they made, like, a Zig interpreter that took the TypeScript type system and made Flappy Bird. Okay. Cool. Cool.

Matt Pocock:

Okay. Right. Blimey. You know, someone reimplemented SQL in types. You know?

Matt Pocock:

It's it's bonkers. So you can do all that stuff, but, actually, the things that it lets you do at runtime are relatively, like, contained. Actually, it does contain you in a certain way, and I find that really nice. I like being, pushed towards a happier path. And I think the the thing you should think about this is why does any exist in TypeScript?

Matt Pocock:

You know? Because any is like a way of opting out of the type system of saying, here, but no further. You know? It's it's way of saying, just shut up TypeScript. I know what I'm doing.

Matt Pocock:

And so with any in TypeScript, you can really just do a bunch of crazy stuff if you want to. You can go back to doing all the bonkers JavaScript things that you like doing. And any is there in TypeScript because because JavaScript is so nuts. You know? And what it means is it's a way of TypeScript saying, slowly over time, we will improve.

Matt Pocock:

We will make more patterns possible via clever inference. But some things will never be possible to explain and do in TypeScript. So for that, you have any type.

Alexander Lichter:

That totally makes sense. And may maybe on that note, any I think everybody even people not know, like, writing in TypeScript, they know any. But there is also something that people should use instead of any very often, which is unknown. But, I think not that many people know about unknown than knowing about any.

Matt Pocock:

Yeah. I think you think of any as really representing any type in TypeScript. This could be anything. And I think that's the wrong way of saying it. Because, like, if we think of the type system as kind of like rock, paper, scissors, you know, like, this thing fits into this thing, this thing fits into this thing.

Matt Pocock:

It's sort of like, you've got, like, kind of, I I watched that video the other day of, like, of the woman saying, like, I know fit the thing into the square into the square hole. You know, everyone's seen that video. And so it's one of those things, you know, where the triangle fits in the triangle, the the square fits into there. But any is kinda it doesn't fit into that system. Any is kind of like a tactical nuclear missile just sort of landing on that whole setup, just exploding everything.

Matt Pocock:

It breaks the rules. You know what I mean? It just okay? Any does not make sense. So when you use any, that's what you're doing to your code.

Matt Pocock:

You're basically just, like, creating a black hole. You know? It's it's it doesn't fit in the type system. Any in technical terms, it's assignable to everything and everything is assignable to it. You know?

Matt Pocock:

And so whenever you're using any, you are breaking out of the type system. Whereas unknown, it's basically like a triangle. You know what I mean? It's in the system. You know?

Matt Pocock:

You it's it's it's playing by the rules. And what unknown is basically is everything is assignable to unknown, but unknown is only assignable to itself. What that means is if you have a function, which is called, that takes in a property of unknown, you can pass anything to it. But then you can't access any properties on that unknown. You've no idea what it is.

Matt Pocock:

And so you will get warnings when you try to access properties that you haven't checked for. And so with unknown, you can kind of narrow it down to different things. Whereas any, you can pass anything to it, and you can access any properties on it. So it just explodes everything. And so I do have an article that says, like, unknown won't save you from any or something like that.

Matt Pocock:

So it's not always appropriate to use unknown where you're using any, because sometimes you do need to just sort of bash touch scripts on the head and just say, shut up. I know what I'm doing in this situation. But unknown definitely has a place, and it's, it's basically like you can think of it as the top type in TypeScript. It's the thing that sort of if you really don't know what it is, use an unknown. Really good for, things like when you have, like, public facing API functions.

Matt Pocock:

You don't know what they're gonna be called with. Great for form data. Great for anything that needs validating. Use an unknown.

Alexander Lichter:

Wonderful. I think that's, that's that's a perfect point in terms of any unknown and how people should maybe treat their their inputs not as like any, oh, whatever. What could go wrong? Just like and with a little bit more more care if if it's needed. Right?

Alexander Lichter:

That's, that's the important part.

Matt Pocock:

Totally. Yeah. I mean, as front end developers, we are always dealing with unknown inputs. You know what I mean? And so using unknown is pretty useful.

Alexander Lichter:

Wonderful. Then I think it's slowly but surely time to wrap up already for this episode. Matt, thank you so much for joining the DejaVue podcast. Thanks for coming here and talk about content creation, TypeScript, and a little bit of Go as well.

Matt Pocock:

Nice. I'm glad no more trucks were mentioned. That's the only that's the thing I'm thankful for.

Alexander Lichter:

Yeah. Not not that has to be another episode for that. I know not livestream. We'll come up with something, that's for sure.

Alexander Lichter:

Or you will you will go on one one more. We'll see. Then the most important last question at the very end is, Matt, first okay. Actually, 2 parts. 1st, is there anything you want to plug?

Alexander Lichter:

I'm more than sure there is. And second, where can people follow you for more insights around TypeScript courses and so on and so on?

Matt Pocock:

Sure. You should go to typescript.com. It's the place, I've been I mean, it's it's I've been pushing so much free content up there. It's insane. I since August last year of writing a TypeScript book that is available up there for free.

Matt Pocock:

So you just read my book, 16 chapters, lot of words, and a bunch of free tutorials up there as well. And there's a paid course as well. There's one section that's kind of for beginners to intermediate and a section for super advanced folks as well. So there's gonna be something up there that you want. And I'm also pushing a newsletter recently too.

Matt Pocock:

So I'm doing TypeScript Tuesdays, so one should be going out very, very soon today. And so, yeah, that's just gonna be full of kind of, like, cool insights and my tips that I've been, like, posting on Twitter since since, like, February 2022. So, yeah, total time to go.com, that's the place, especially, the newsletter side too.

Alexander Lichter:

Wonderful. Links are on the show notes, of course. Great. Very important. And, yeah, I can I can only second that I I I bought the course when it came out?

Alexander Lichter:

Super super happy that I did, because even using TypeScript for for a couple years, like, there's always something to learn or just like a slightly different explanation to things where, like, oh, this is this is even better to understand it. So, yeah, I can just say thank you so much for all the free content, for all the courses you offer, and thank you so much for coming on to Data View.

Matt Pocock:

No worries. Nice to meet you both.

Alexander Lichter:

And then, of course, for everybody, still on here. Yeah. You should be. It's not the end yet, but almost. Feel free to check out the later episodes like the earlier ones.

Alexander Lichter:

Whenever you're watching this, maybe just watch it when it comes out. Also if you if you have any question to the TypeScript wizard, and and, not the track guy, but the TypeScript wizard, very important to mention once again, bring him on on Twitter and, in the YouTube, the comments, wherever you want to, and, there will probably be a chance to to ask him. Maybe he'll be there answering them. So, yeah, bring him on, and, thank you for joining and see you in the next episode, folks.