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, Hello Jane.
How are you doing.
I'm doing well. It's great to have you here. Before we start, I have one thing I would like to mention. So there's the new the latest JAS 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 good? Very good.
I've moved house recently. My son fell about five feet onto a hard floor. He's absolutely fine, but he had a black earfe for about ten days. But other than that, I'm doing okay. Yeah.
Yeah, it's funny. Well, first of all, you need to mention that your son is eleven ten or eleven months old.
He's not sixteen or something. No, he's ten months old. And yeah, he's very small and he felt quite a distance, but he's 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 no, obviously it's super scary and we shouldn't drop them. But but they are, but they are, But they are resilient, more resilient that we might expect. Quite yeah, And where have you moved to?
So 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 and where that distance and it's nice and I really like it.
So really an English country gentleman.
Quite exactly. That's how I like to present myself. That's how I feel too. I just need my top hat, my monica and my pipe.
You know, I know you as I imagine most of our listeners do from everything related to typescript. You have a typescript site, you have a typescript newsletter. You put out I think typescript related videos and other forms of content to a lot of us. Me for example, you're
kind of like mister typeescript. I'm subscribed to your newsletter. Well, I'm subscribed to a couple of development newsletters, but yours 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.
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 join or whatever we like to call it. So take it away.
Yeah, my journey into developments in general is odd. I studied drama at university. I after that, I became a singing teacher, so I sort of sung a lot in a university 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 know. I
didn't like living in the big city. At all, and so this was around twenty seventeen, twenty twenty sixteen, 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 made my own little websites when I was twelve 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. And I loved teaching.
I still love teaching, but I just I wanted to try something new, and it occurred to me that I could go and get a job doing this, and so I did and became 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 timescript. And I was always a just basically a JavaScript and timescript person. I did a love of PHP, but really just that. And I started to.
What year was it when you started doubl in the typeescript?
About twenty eighteen, I think would have been yeah, okay, so it would have been out I think for about six seven years at that point, and maybe even five 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 in 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 a Jason Blobs in Google Docs. 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 or instead of snake case or the other way around, or something would be misspelled, something would be nullable when we didn't expect and this would cause bucks. You know, this would just break our front ends. And when we started opting 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 two seconds instead of two hours.
You know.
It was fantastic. And so from there I was just a touchgo 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 x state?
Yes, yes, I have. It's a state management library. It basically does state machines. That's right.
Have you had David on the podcast as well, David Cushy.
I think we have. I would need to check if we had, though I think I might have missed that episode, And to be brutally ought and honest, I myself have not yet used the x State.
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. I've sync 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, complex applications like spreadsheets, like I was building a video calling service where you could like walk through a virtual room in an agency I was at, and X State was really incredible for that, and so I started working doing a little bit of open source stuff for x State. Open source then led to me joining a company that got formed out of the x State core team, and I started doing DevRel
for x State, and then I started teaching tapscripts. And when I started teaching tapscripts, it just went something really crazy happened, and within about six months or so, I became someone with that four thousand 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.
Well. I think it's a combination really of 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 it was kind of like information from on high, and it was and they were doing it as a vendor, not as you know, as a teacher. So I think there was a real need for teaching typescript and everything else was like Typescript in the context of something else, rather than a 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 typeescript as well. I am curious, though, maybe it's the fact that it's
you know, I'm a bit old school. I came into software the more traditional route through actually studying computer science in the university around and there's a lot of formalism around type systems and stuff like that, So you kind of expect people that are really into type systems to have a bit more formal background, and yet you're able to do this and pull it off and do it really well. So how did you fill in the missing blanks?
How did you get the knowledge the background in type systems and stuff like that.
That's a great question, and I think probably there are still blanks in my knowledge that I don't know, 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, I missed out on something crucial. You know, there was something in a CS course that I never took that 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 still like, I still find it hard to explain, like covariance contravariance in a sentence. 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 the people learning typescript, I would teach it. If, for instance, contraveriance 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 tapskipt'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 its not having the curse of knowledge, has benefited me in weird ways to making me closer to my learners.
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 work whatever seemed to make sense,
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,
that part of my career. So I totally get that a lot of what 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 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 skill set and knowledge and whatever. 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 the way that I got into typescript, which was a bit different than you, I think, or maybe maybe maybe not. We will see. I got into typescript a little bit earlier, around I think twenty fourteen, fifteen is the first time I actually encountered it, and I have to tell you that in my initial reaction
was very negative. The reason was that back at that time, Microsoft, all the examples that they were that were coming out of Microsoft were around classes and interfaces, and they were showing, you know, this is how you implement class hierarchies and interfaces and doing it safely and stuff like that, and to me, it very much felt like Java or SEA sharp, And you know, I left Java and C sharp and went into and you know, got into JavaScript and enjoyed
JavaScript much more than I ever did Java or C sharps. So the last thing that I wanted was to go back. I think that the terminology that I was using back then was this is a poor man's Java. And I basically said, you know, kind of a little bit reflected some of the attitudes that Dagge proclaims still to this day that you know, I like the freedom, I like the duct typing, the monkey patching. You know, I don't like to feel constrained. I've got tests as if I
need guardrails and stuff like that. And it took me a while. It took me a couple of years to realize the value the typescript actually actually has. When I started using typescript without without classes in interfaces, did you go through a similar phase or was it great for you from the get go?
So it was great for me from the get go, I have to say. And I feel like, I'm not sure when type scripts implemented geox, but that's what they did. They implemented gosex 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 typescripts kind of as we were working, and it
was just great from the get go for me. So 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. I immediately saw the value and I immediately started putting it in a React app, which was mostly functional.
The other aspect of it that was initially problematic for me, and to an extent it still exists, I guess, is the fact that the way that at least initially I thought about it is that I would write a JavaScript code and then I would add the types in. And what happened was that the JavaScript code, at least initially would come very fluently, 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 script. So there I was like sweating bullets about getting the proper type interfaces 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 I was thinking, hey, I'm spending more time on implementing the types than I am than I had been on the original logic in JavaScript, 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 impacted runtime, and it felt kind of, you know, redundant.
You can feel like, oh, the features done. You know, I can see it working. Why do I have to do all this extra effort to exactly to just paint it really, to just you know, the cars working. I don't care what it looks like. And I think if I were to rebut that I think because I do. I think I didn't have a long leading as like a JavaScript developer really before becoming a time script maybe
two or three 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 right in quite a sort of dull way. You know, you don't get a lot of a lot of the same freedoms that you do when you're working in JavaScript.
Of course, I would argue that is quite a good thing.
You know.
It means that code generally starts 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 what I start doing now, having worked in tapic it 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 perhaps sort of as part of that.
And so I tend to type my function parameters before I implement them, so I'll just get all my functions in a row and understand what's happening, and then I I'll 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 the types before I implement the rest of it. But that's how I'm certainly thinking about my type of death.
So first of all, by the way, one of the things that also clicked for me was when I started thinking about it, like tests. 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 really hate cool bases without tests. You know, it makes me
feel insecure. And even though I sometimes, like, you know, I'm lazy, I sometimes writing all the tests that I need to, but you know, at the end of the day, it's worth it. And I look at the same way with types, and I've gotten really to the point that I really can't write JavaScript anymore. Even I love JavaScript. JavaScript for a long time, it's been my favorite programming language.
I've been doing it since nineteen ninety eight. I'm really dating myself, so yeah, for a long time, more than many of our listeners have been alive, maybe, But these days I'm literally like, I literally like, if I'm writing just pure JavaScript without the type definition, it feels like something is missing m 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 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 surreness, 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 have a lot more security that your code works the way you think it works.
I totally agree, and this was actually, you know, I literally experienced this very recently, as in a few days ago, because that where I work with just some sense, we've got a lot of legacy code. And one of the topics that I'll probably bring up with you is you know how to deal with legacy stuff and how to port existing jobscript projects to typescript. And I see bugs in the code that could not happen if the code
had been written in typescript. And you know, there are a lot of challenges in adding typescript into an existing jobscript project, especially a lot 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 into an existing job skiped project is basically just adding types, don't 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 adding job typescript into an existing job script project.
M 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 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. But yeah, you're absolutely right. And that was definitely the experience we had is that when I first introduced type script in that very first project, is oh wow, that's a code path I just didn't see what's possible, or yeah,
that's okay. That could either be a string union or string or number in that place instead of just a number. You want to dive into like how to migraines, because I've definitely got some advice there.
Yeah, you know what. I was saving it for later, but it seems to naturally fit in here. So let's say I'll give the background. Let's say I have a large scale existing JavaScript project. Maybe it's React, maybe it isn't. 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? And if so, you know, what would be the unit size? How do I estimate the effort? How do I justify it to product and management? And I'm going to be spending all this time yet not adding a single feature into the product. You know, what can you say about it? Yeah?
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.
Oh yeah, for sure. If it's not worked on, then what's the point Almost exactly right.
So, like you're working on an active codebase, you need the CI to remain green all times as well. You don't want to be doing things which make the CI read for a certain period of time, and you don't want to 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 command or something, and then you
know you're in type script with zero types. And then perhaps you could ramp down the strictness to the point where you get zero errors. Right, there'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.
Basically, they 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.
Yeah, big disruption you know, no good, especially to a big team working on a big mono REAPA, 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 know any rule, then you turn it on and it affects your entire codeies, so the CI is
basically red. So I think that that approach which a lot of people do take of turning every file into a touch grip file is a bad approach because what you should do, I think instead is you should add in a ts comfig into your projects, and you should install typescripts, 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 touch gript file, and by doing that you might find external libraries that need to be important 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. 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, and you want to translate in touch script first.
The ones with the fewest dependencies You can use a tool like match I think to basically walk up the tree.
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.
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 things.
That we use which project does not have a utilis folder.
Exactly right, that's where you want to start. The reason is is that if you start further down the tree, then your touch grip code is going to be depending on JavaScript code, and that's a really nasty place to be because all of the JavaScript code is just going to produce any's and so that anys are then going to filter through, whereas if you start with a typescript file that has no JavaScript dependencies, you're going to be in a really really good spot. And then you just
slowly go down the tree. And so Century has an amazing article about this. They basically did this for Yeah, I'll drop a link certainly later, but if you google Century Typescript, it will come up and that's Century the Eralogua, not like you know, a century of time. And what they did was they basically said, Okay, we're just going
to 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 two years, and it took them a while to get it done. And I think there are still files in that codebase. It's an open source code base as well. There are still javascripts and mostly like tests and things that they just haven't
needed to change. But every new file, of course, is still in typescripts. And so that was the process they followed, and I think it worked really really well. I interviewed Priscilla, one of their devs for my course, and she sort of explained the whole thing, and that is the process
I would follow. Basically, make a dependency tree, workout which ones to do first, add in a TS conflict 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 trs they can tend to script.
Do you know what occurred to me, Maybe is 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, and in which case, don't do it. It might it might be beneficial to have like two levels 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 transition translating into into TS.
It might have been beneficial to have like a TS star or TS you know, TS two whatever file that that has like less strict settings, so which would allow you to gradually get that file to where you want to go without having too lower And that's 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. You unfortunately encounter like a one
thousand and nine file. 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. It's also good good forget and stuff like that. And in that context, taking a one thousand line file and turning it all into strict from JavaScript into script type
script in one go can be fairly challenging. Now, obviously you can turn off various rules in the scope of that particular file, I guess, but that's a pretty big asp.
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 yeah.
But then but then that means that you need to support any everywhere, which you may not want to do.
Yeah, and if it's a file that's dependent on a lot, then if you have any in that top file, it's going to spread down like a virus into all the others, you know, exactly, 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 going to be the hardest to type.
Right.
You might end up needing some generics in there, some generic types and generic functions because those that so, but you might need that, and that's a hard place to start if you're just beginning a typescript migration and upskilling your team. So usually you do need someone who's going to be you know, the type script wizard on that team to tackle the utils file so that everyone else can benefit.
Basically, whichly 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're getting more and more front end or JavaScript developers that are effectively typescript developers, but there are still a lot of JavaScript
developers who are not typescripts out there. And the reality is is that I had a team to tell me, you know, you want us to go full typeescript, but my debs don't really know Typescript. And it's a problem if 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 Any's and if I don't allow them to use Any's, then they'll potentially get stuck.
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, 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 OKAML or I'm not sure. I don't know okammeill that well, but I know that's one of its uses. Risen mL ELM, things like that. I don't like those because there are much heavier lift in terms.
Of learning different programming language, different.
Programming language, whereas and 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 javascripts just to be able to add types to it. So I think when you do that, you do need someone who I think can lead or 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 zero typescript knowledge whatsoever going into a tapkript migration is I think going to have a pretty tricky time unless they invest in some resources to 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. I'm just I'm just stuck on a problem because if you don't develop that intuition, it can
take a while to muscle through on your own. But I think the basics of typescripts, I think you can get productive in tap script pretty quickly. Was that your experience of learning it?
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 statically type language. Well that's not actually true. I started with basic, but I pretty soon got into statically type languages. So most of the most of my programming career was actually spent in statically
type languages to an extent. Going to JavaScript, I felt deliberation into an extent, and of putting all the static types behind and and you know, just saying, you know, the wild wild West, as it were, of you know, it can be whatever, uh, and dynamic object structure and whatnot. 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 chart 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 stuff like that, and then you're trying to, uh, you know, implement a static type system on top of that. It's it's it's pretty amazing what the types of the team
has been able to achieve in that context. And I guess we'll 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 the concept and then I used them in Java and in C sharps. So by the time that I got to typescript, that was already familiar with these concepts. So it was less of a hurdle
for me. Then it might then it might have been, you know, had I not had that background.
M hmm, 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 two areas or possibly three 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 killed folder exactly. Let's let's hold on off on that because I actually want to get into that specific point and and a bit later in our conversation, and before that, I have I have a different question for you. So what I really wanted you to ask. So you're obviously a Typescript aficionado. You really love the concept, you love you love the language. But by the way, one of the other things that I think we forgot to mention, but the big reasons for Typescript success, it's just the
integration with development environments. 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 uh and and tool for the JavaScript programming language. Uh. And the great integration that you had from almost day one with vs code is I think it made a
huge difference. Obviously, now you also get the same level of integration with you know, with other tools like web Storm 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 does all the type checking for you in real time. So that was a huge win. And coupled with that is all the type information that
they created for existing frameworks and libraries. So all of a sudden, even if I'm just working in JavaScript and not Typescript, I'm getting a lot of the benefits of Typescript totally.
So this was about eleven years ago when Timescript first kind of came out. And the thing that I think a lot of people probably or brought a lot of people in was one of my friends called Johnny Riley, who ran the definitely typed repo. He spent a weekend I think when his son was very very small, making typesquery and basically like typing jQuery, so you suddenly had autocompletes for everything jQuery could do, and he wrote these beautiful jas 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 vs code kind of being built at the same time, but typescripts. The VSC 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 VS code? So I don't think VS code because it was such
a complex jawscript application. They really wanted a strongly typed language, so they were built actually at the same time using really within Microsoft Amazing.
I just do. Yeah, that's the other thing I know. I mean when I look at projects that somehow get by with our typescript, they're usually very small, and it's a legitimate thing. But all the projects that I've been working on in the world 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 ten, sometimes as large as fifty working on code basis that can be up
to a million lines of code. Doing that without typing is bordering on insane.
Yeah, because I mean, just in very simple terms, when you're working on like, the more developers you add to the projects, the more likely you are that one of those developers is going to 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, 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 want to check if that code is compassible with
each other. Having an automated system for doing that is incredible. And of course touch Coupe doesn't catch everything, but it catches an enormous amount for a very low or comparatively low level of effort.
I totally agree. And there's the other side of it, which is the fact that jobscript 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 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 still get by with bugs. Like I mentioned before that I'm fixing legacy software, I'm catching a lot of bugs. These are often systems that have uh end to ntest that's saying place and the end to ntest
pass because the browser is such a forgiving environment. 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 buddle through until you know maybe it does it anyway, So I would like to get to the next my next question. And you know, typescript keeps evolving, uh and and getting new features. What version are we at? Five point what.
I think we're five point seven now? Is that right? Let me check five point seven is the new beta that's coming out, So I'm pretty sure.
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 like most about Typescript? But the other side of that equation, is there anything that you hate about typescript? And if so, what is that?
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 got we've got the love. The thing I love is that it makes my ide ten times more powerful, It makes developing stuff easier, makes me feel more secure. So let's go on to the fun stuff. The stuff I hate. Flow, which is Meta's sort of version of typescripts. It's a version of strongly type 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 this is an object of this type, then you basically can't add any extra properties to it. So if you have an object with ABC, 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 touch script 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 can read my chapter of my book on exact object times, which is free by the way is you know, just google.
It and what that means. Book. By the way, it's a.
Total type Script Essentials, So if you go to total touch gript dot com clickbook, you'll you'll.
Find it and recommended.
Oh, thank you very much. This means that various things in touch script are not as good 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 as aws 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 time script knows are 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. So I wish, I wish, I wish, I wish timescript had exact object keys.
I think it's something you can configure somehow with tears configure.
It's just so baked into the way that typescript works that it's impossible to go back. It's a feature I wish they could add, but I I would be shocked if.
They managed to do it, honestly, 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 brilliant flag in the configure. Theoretically be possible, but practically it would be very.
Challenging, very very tough. And I suppose they could add some sort of keyword, you know, like the exact keywords to make make it work, because Flow has exact objects by defaults, but you can make them like typeescript if you want to opt in. But yeah, 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 think they're gonna they're going to get around to it, which is a shame.
M anything else, then you would wish.
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 Tannel Linsley about this, I think three years ago, and he was saying, Oh, they might fix it, and they've been shaping up to maybe fix it. But it just makes certain APIs impossible basically you, and it makes things a little bit harder.
So I would love to fix that too, you know what. 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 go from there.
Yeah, 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 Tychkriit 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 parameter. 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 two upper case or something. Otherwise we do something else. So if you imagine, there are kind of three blocks there. There's the function, there's the first if statement where we were checking if it's a string, and the second if statement if we'd check in if it's a number. Now, without this magical thing called inference, we would have to add types in all
those places. Right, we have to say, Okay, 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. It says, oh, yeah, it's an if statement that's checking this thing. It must only be a string in this particular closure.
By the way, just to interrupt you briefly, that was one of the magical aspects for me of Typescript that initially didn't get because again I came into, as I said before, my background was from language statically type 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 passing types, but within the code itself, you don't. And it took in the realization that you that typescript does static analysis of your code and narrows the types based on 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. And once I realized that that was one of the things that really like got me to to really appreciate typescript one.
Hund And it's such a hard problem as well. I imagine building that from scratch, you know, something that looks at your code and understands, okay, in all of these places, this is what type these values are. It's crazy. They pulled it off. So it works. This is what's called narrowing in typescripts. 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 will automatically. You don't need to add any type annotations apart from just the input. It's amazing the way it works. So that's what type inference is. It's typeescript 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 saw return types, by the ways, where I usually think about inference, Like you said, parameters usually need to be typed, I mean, because you really can't infer the parameters. 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 AD function that takes A and b in returns A plus b. If both A and b are numbers, then obviously A
plus b is a number. So yeah, 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.
Yeah, so this 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 time 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, it's a function that takes in a string and returns an object with a value in our 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 developments. You're 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 going to return the same type, always going to return a type of React dot React node because you're just returning gsx so in every single React component, so you're going to be returning the same thing, And to annotate React components return type just seems a bit weird to me.
There are link rules that force you to add 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.
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 function body, then I've got the return type as a validation that what I'm returning actually matches that type. So I get two benefits. 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. Yep.
Absolutely.
The interesting thing is, again looking at my experience with other statically type 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 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 this aspect, because in a sense, if I
don't really if if if my all my assignments are initializations, m so all my variables are calls like not variables, they're they're mutable to an extent, I don't need to think about I almost don't need to think about the type. So I'm assigning the return value of a function into a variable. It is what it is. I know that 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.
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 run time. 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 going to have this value of property on them, then you need to tell touch script that upfront, because if you just initialize like an empty object, then touch is just going to infer it as an empty object basically. And so I'm adding that level of you making a map. But even with a map, you need to you know.
Yeah, maplicit. Yeah, you're obviously exhisit about the time. By the way, one of the things that kind of also blew my mind about modern typescript is how you can create types with string expressions that you can actually structure. Is say, not we give example before about keys that it's not just any string. It's it's the keys of an object. But it also can be a particular structure of a string, so a string that has like hello at the beginning or something like that, which is pretty insane to me.
Yeah, if you, if you're following on at home, if you've got us in your ear and you're at your laptop, try just typing crypto dot random you U, I, D 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 five parts of a string separated by dashes, and you'll see in the return time 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 type safe way. It's absolutely wonkers.
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 type languages working against me, was the document dot create element. The fact that the type returned was based on the string parameter passed into that function kind of blew my mind. This
was not C plus plus. They're like, you know this, it's 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 dome. But the fact that if you pass in the string div the time, the return type is is HTML div, but if you pass in span, it's HGML span. If it's a button, then it's HML button. It's pretty insane to me. Yeah, and I think that was from day one.
Yeah, I think because that's that's another thing that tapskib does too. Is it just it gives you a lot of confidence in these dom APIs, and some of the domapis are pretty funky, you know, in terms of what they do.
And you talked about Jquerry. The dollar function in Jquerry literally could accept anything in what you passed in really determine 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.
I can't believe they pulled it off, to be honest, like it is. I mean that you've you've got an incredible team there, You've got Steve Luca, You've got Andres Hausbergs that are working on.
This thing, and this is my god.
You know, yeah, everyone's good. It seems like such a nice guy as well. And I'm never met him in person, but I would love to.
I'll do a quick aside. You know that. You know, people know him from typescript and from C sharp, but for me, he'll be forever the person associated with Tubo Pascal. I really, you know, you know what Tubo Pascal was or is.
I don't think I do. I mean, I know the words, but I don't know the.
So so so. Pascal is a programming language that originated back in the 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 everybody working on on PCs back in the in the day and 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 Tubo Pascal, which basically was an implementation of Pascal and an ID, so it was both the programming language, the compiler, and an integrated ID, which was miles ahead of anything else available at the time, ran on really low endpcs 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 Tubo Pascal in Pascal, 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 if I'm thinking about people that I owe my career to, Andrews is high on that list.
Wow, I guess me too, man, I'm me too. I mean he didn't invent Touchkik like a lot of people think, but his influence and his guy didn't say very I mean he's still involved today, is still making pians today.
He's an incredible guy anyway, So I have a few more questions. So we talked about the things that we like or did like, or you like or don't like about typescript. By the way, we are starting to run a long I don't know 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 stop or whatever.
I've probably got a hard stop at half past so in eighteen minutes, sadly.
Okay, So maybe we'll you know, just need to schedule a follow on, so I'll try to get one or maybe two more questions into there. The next question that I have is, again, given the new versions of Typescript coming out, what recent or upcoming addition to Typescript has you the most excited.
Yeah. So the thing that really got me excited was five point five, and I want to get this right. This was five point five 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 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, and then you can write a little inside that. Top filter basically just says a type of string, a type of input equals string, and before again you need to do this junky 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.
So basically all the arra 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. If they get that to work, that will be like really insane.
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 retreats for a couple of weeks and just built a feature, his first ever PR timescript and they accepted it and it's now an incredible, incredible feature.
Which again I don't I don't think will 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 noullable is part of the type and if you pass a non noble argument in then you
don't need to worry about it being null. So the if you're doing it correctly, all the null errors that what's known as that you know, that famous one billion dollar mistake, even though it's probably way more than one billion dollars by now, all those null references. If you do typescript correctly, it's it just solves that.
And the fact that 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 on. And that's part of strict true, which is timescript sort of basic strictness level. The fact that it discriminates between those two as well is just you can feel extra strict sometimes, but it just saves you an extra level of pain.
Yeah, I do wish, you know, if I could have gone back in time to nineteen eighty five and whisper on Brendan Ike's ear I would have said, maybe not both, maybe just one or the other.
I strongly agree, and maybe just fix the thing where type of nell is an object as well.
That's blood. You know, that's a funny one that one actually slightly bothers me less interestingly enough. I get why that is. Let's put it this way. But again I think,
you know, that's a different discussion. And there is one more thing that I would like 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 you tills, but utils is probably not dependent on anything, or at
least or not on anything internal and the question. But on the other hand, it's the one that's most likely to need advanced Typescript features like generics and stuff like that, so you're probably also starting with the hardest part. 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 in this context, I think it was
THEO if I'm mistaken, then I apologized. 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 like the userland slash application level, you can be you don't need all the fancy schmancy Java typeescript 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, you need to deal with sophisticated APIs, and then you need stuff like generics, and we talked about covariant and contravariant 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.
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 three or two things in there, 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 ACYNC 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 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. And this sort of is a nice feature of typescripts, I think, because it means that 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 pannotations by the app developers. I would say, I think of there as being three places, three sites of three levels
of tacticrit 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 your idea update and things like that. And then I'd say that the utils folder is like a level in between where you don't necessarily need and this is not my idea is to actually
orto the Rocks's idea. Who's a great typescript term was on the touch script team, great typical contributor, and the utils folder. I think you can get by with just a bit of types of knowledge, especially now you have things like gubt 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 developments, 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 fund 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 first month doing type scripts 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 details folder knowing this stuff is going to just benefit you enormously.
Yeah, I think that's the key point. I think it's totally fine to start before your quote unquote and expert. If we all waited to become expert before we actually started doing something, that we will never stop. Like the worst enemy 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. 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
stuff like that. So as long as you you know, say okay, I am going to put in the effort to fill in the blanks. I think it's a legitimate approach.
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 don't get stuck so often. You know, you can just work your way through errors. You can understand what's going on.
Now, if you've got another minute or two, 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 Poe or Poan. 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?
Yeah, so one key part of typescript understanding is that it just doesn't operate at runtime at all, like.
It's just gone.
It's gone. It's just you know, like they're they're just cleaned out those types and so there can iterate.
You can't iterate over like a lot of people like say, I hate the fact that you kind of define certain things like twice part once as values ones in types and one can can iterate over the type you can because it's not part of the run time, 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 m could probably do
it for you. But yeah, I mean, there's there's no 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 typescripts, 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 zod which is a runtime validator runtime schema library, then you can take that and you can say type of z dot's schema and it just gives you a type of.
The simple example. The simple example is the key is keys. Is the fact that you can use specify like an object with various keys infer a type from that. So now you've got the actual object which you can use at run time, but you've also inferred the type that you can use at you know, build slash programming type.
Yeah, 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 them. 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 two places. You just add an the key you had a staging environment, and then that suddenly appears in the type. It's really really powerful stuff.
So before we've really run out of time, if people want to get in touch with you to you know, get on your news letter, 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.
Thank you. So this is total touch. Script dot 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 it's a free book. It sounds like it's just a cheap giveaway. It took me nine months to write this thing, you know what I mean. Like, and it's being released as as an actual paper book as well. And I've got a course up there, and there are tons of free tutorials and sixty articles I've written up there. It's a it's a really solid resource.
And in terms of paid stuff that you put out, what do you what is there? What's there? What's Yeah?
So I've got I've got two courses, or two levels of courses, one which is pro Essentials, which is I mean it's about two hundred two hundred and forty exercises I think where basically it takes you from total beginner in tap script to sort of like the bottom end of Wizard, I'd say, So we cover generics, and there we cover all sorts of stuff related to typescript, and then the other stuff, which is 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 five hundred exercises or so, like it's an enormous, great, big thing, But I love the exercises. You can just sort of dive into them in an your lunch break. Basically it should take about sort of five or ten minutes to solve each and there we've gotten feedback that it's just like a really addictive process.
You can just go bam bam bam bamm solving all the exercises and it's great fun.
And the very last thing before we let you go, is there anything interesting that you're working on now, something that we can look forward to.
Well, I'm diving into the world of AI, I think, and I'm starting to find that I'm someone who's kind of allergic to hype. Really, I just hate the whole hype cycle for things like crypto, and I just want to get to the interesting stuff and the meat that's gonna kind of make me more money or make companies more productive, or like somewhere I can provide value, you know what I mean. I don't want to speculate on
crypto rubbish. And AI has 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.
Oh so very cool. So you know, people are used to us also having a pick section, but I think we've kind of ran out of time. I would 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 about AI at all, So hopefully I can get you on again. In any event, it's been excellent. I've learned a lot. 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 job as the JAS survey mention us you know given excellent content like this one. And thank you all and goodbye.