Speaker 1: Hello everybody, and welcome to another episode of the JavaScript
Speaker 1: Jabber podcast. Today we have a special episode with a
Speaker 1: special guest, Matt Pocock. Hi Matt, Hello Jane.
Speaker 2: How are you doing.
Speaker 1: I'm doing well. It's great to have you here. Before
Speaker 1: we start, I have one thing I would like to mention.
Speaker 1: So there's the new the latest JAS survey that has
Speaker 1: just come out I think today as of the time
Speaker 1: of the recording, and I would love for you to
Speaker 1: pick JavaScript Jabber as one of your favorite podcasts in
Speaker 1: this survey, you know, just to help us get the
Speaker 1: word out there. You know, every little bit helps. So
Speaker 1: with that out of the way, let's get to Matt. So, Matt,
Speaker 1: how have you been doing good? Very good.
Speaker 2: I've moved house recently. My son fell about five feet
Speaker 2: onto a hard floor. He's absolutely fine, but he had
Speaker 2: a black earfe for about ten days. But other than that,
Speaker 2: I'm doing okay. Yeah.
Speaker 1: Yeah, it's funny. Well, first of all, you need to
Speaker 1: mention that your son is eleven ten or eleven months old.
Speaker 2: He's not sixteen or something. No, he's ten months old.
Speaker 2: And yeah, he's very small and he felt quite a distance,
Speaker 2: but he's okay.
Speaker 1: Yeah, it's it's surprising how resilient babies are. I mean,
Speaker 1: if they if they are, if they wouldn't have been,
Speaker 1: then the human race would have likely died out by now.
Speaker 1: But no, obviously it's super scary and we shouldn't drop them.
Speaker 1: But but they are, but they are, But they are resilient,
Speaker 1: more resilient that we might expect. Quite yeah, And where
Speaker 1: have you moved to?
Speaker 2: So just moved locally? So I live in Oxfordshire and
Speaker 2: just moved to another place in Oxfordshire so I can
Speaker 2: see horses out my window. Oxford is like and where
Speaker 2: that distance and it's nice and I really like it.
Speaker 1: So really an English country gentleman.
Speaker 2: Quite exactly. That's how I like to present myself. That's
Speaker 2: how I feel too. I just need my top hat,
Speaker 2: my monica and my pipe.
Speaker 1: You know, I know you as I imagine most of
Speaker 1: our listeners do from everything related to typescript. You have
Speaker 1: a typescript site, you have a typescript newsletter. You put
Speaker 1: out I think typescript related videos and other forms of
Speaker 1: content to a lot of us. Me for example, you're
Speaker 1: kind of like mister typeescript. I'm subscribed to your newsletter. Well,
Speaker 1: I'm subscribed to a couple of development newsletters, but yours
Speaker 1: is one that I open as soon as it arrives
Speaker 1: because it contains so much really useful and pertinent information.
Speaker 1: I've really learned a lot. And I'm not just saying it,
Speaker 1: you know, to be nice. I'm saying it because it's true.
Speaker 1: So I would love thank you. So I would love
Speaker 1: for you to tell us a little bit about your
Speaker 1: journey into typescript and maybe even your journey into software
Speaker 1: in general, because I know that you didn't actually start
Speaker 1: with software. It's something that you like, grew into or
Speaker 1: decided to join or whatever we like to call it.
Speaker 1: So take it away.
Speaker 2: Yeah, my journey into developments in general is odd. I
Speaker 2: studied drama at university. I after that, I became a
Speaker 2: singing teacher, so I sort of sung a lot in
Speaker 2: a university and basically picked up singing teaching. I did
Speaker 2: a master's in voice and singing teaching, so in a
Speaker 2: drama school and moved to London and was working as
Speaker 2: a drama teacher. And I lived in London, and I
Speaker 2: wanted to be an Oxford country gentleman. You know. I
Speaker 2: didn't like living in the big city. At all, and
Speaker 2: so this was around twenty seventeen, twenty twenty sixteen, I think,
Speaker 2: and I thought, what's a skill that can take me
Speaker 2: out of the city, that I can do from anywhere.
Speaker 2: And I've always loved computers always. I made my own
Speaker 2: little websites when I was twelve years old, just with HTML,
Speaker 2: and I thought, well, okay, maybe I could do that
Speaker 2: for a job. And so I started making applications for
Speaker 2: my students, making my lessons more interactive. And I loved teaching.
Speaker 2: I still love teaching, but I just I wanted to
Speaker 2: try something new, and it occurred to me that I
Speaker 2: could go and get a job doing this, and so
Speaker 2: I did and became a junior developer, and I went
Speaker 2: from junior to mid to senior pretty quickly. And around
Speaker 2: when I was a mid I started picking up timescript.
Speaker 2: And I was always a just basically a JavaScript and
Speaker 2: timescript person. I did a love of PHP, but really
Speaker 2: just that. And I started to.
Speaker 1: What year was it when you started doubl in the typeescript?
Speaker 2: About twenty eighteen, I think would have been yeah, okay,
Speaker 2: so it would have been out I think for about
Speaker 2: six seven years at that point, and maybe even five
Speaker 2: years or so. But and from that point I was
Speaker 2: working professionally and there was one particular project as well
Speaker 2: that had just really brought home the power of typescript
Speaker 2: to me, which was this project. We were the front
Speaker 2: end team working with the back end team, back in
Speaker 2: team in a totally different language, and we would make
Speaker 2: these contracts for linking up the front end and the
Speaker 2: back end, and they weren't very sophisticated. They were just
Speaker 2: kind of a Jason Blobs in Google Docs. And these
Speaker 2: contracts the back end team never quite implemented them the
Speaker 2: way we wanted them to in the front end team.
Speaker 2: So you know, you would have camel case or instead
Speaker 2: of snake case or the other way around, or something
Speaker 2: would be misspelled, something would be nullable when we didn't
Speaker 2: expect and this would cause bucks. You know, this would
Speaker 2: just break our front ends. And when we started opting Typescript,
Speaker 2: which I really really pushed for, suddenly whenever a small
Speaker 2: change was made in the back end architecture, it just
Speaker 2: meant we could change it in two seconds instead of
Speaker 2: two hours.
Speaker 1: You know.
Speaker 2: It was fantastic. And so from there I was just
Speaker 2: a touchgo advocate at every job I had, and that
Speaker 2: led me into a bit of open source stuff as well.
Speaker 2: So I started doing have you heard of a library
Speaker 2: called x state?
Speaker 1: Yes, yes, I have. It's a state management library. It
Speaker 1: basically does state machines. That's right.
Speaker 2: Have you had David on the podcast as well, David Cushy.
Speaker 1: I think we have. I would need to check if
Speaker 1: we had, though I think I might have missed that episode,
Speaker 1: And to be brutally ought and honest, I myself have
Speaker 1: not yet used the x State.
Speaker 2: It's a wonderful library basically building state machines and state charts.
Speaker 2: And if you've ever done front end work, you know
Speaker 2: that building front end interfaces is really hard, actually, and
Speaker 2: you will often encounter bugs. And those bugs are often
Speaker 2: because you just haven't thought of a specific state that
Speaker 2: your UI can be in, you know, like and you know,
Speaker 2: things go out. I've sync and it all feels horrible.
Speaker 2: But state machines really bring that complexity to the surface
Speaker 2: and make it a lot easier to work on. And
Speaker 2: I was working on some complex, complex applications like spreadsheets,
Speaker 2: like I was building a video calling service where you
Speaker 2: could like walk through a virtual room in an agency
Speaker 2: I was at, and X State was really incredible for that,
Speaker 2: and so I started working doing a little bit of
Speaker 2: open source stuff for x State. Open source then led
Speaker 2: to me joining a company that got formed out of
Speaker 2: the x State core team, and I started doing DevRel
Speaker 2: for x State, and then I started teaching tapscripts. And
Speaker 2: when I started teaching tapscripts, it just went something really
Speaker 2: crazy happened, and within about six months or so, I
Speaker 2: became someone with that four thousand followers to being the
Speaker 2: typescript guy to being this person. I'm not really sure
Speaker 2: how that happened. Happened quite quickly, and happened seemingly without
Speaker 2: my knowledge or intervention, so thank you.
Speaker 1: Well. I think it's a combination really of a couple
Speaker 1: of things. First of all, I think there was a
Speaker 1: real need in the market. I mean, on the one hand,
Speaker 1: Microsoft were communicating stuff about typescript, but it was kind
Speaker 1: of like information from on high, and it was and
Speaker 1: they were doing it as a vendor, not as you know,
Speaker 1: as a teacher. So I think there was a real
Speaker 1: need for teaching typescript and everything else was like Typescript
Speaker 1: in the context of something else, rather than a focus
Speaker 1: on typescript itself. And I also think it helped that
Speaker 1: you're just a great teacher that you could bring your
Speaker 1: knowledge and expertise and your approach that you had from
Speaker 1: teaching other things and apply them to typeescript as well.
Speaker 1: I am curious, though, maybe it's the fact that it's
Speaker 1: you know, I'm a bit old school. I came into
Speaker 1: software the more traditional route through actually studying computer science
Speaker 1: in the university around and there's a lot of formalism
Speaker 1: around type systems and stuff like that, So you kind
Speaker 1: of expect people that are really into type systems to
Speaker 1: have a bit more formal background, and yet you're able
Speaker 1: to do this and pull it off and do it
Speaker 1: really well. So how did you fill in the missing blanks?
Speaker 1: How did you get the knowledge the background in type
Speaker 1: systems and stuff like that.
Speaker 2: That's a great question, and I think probably there are
Speaker 2: still blanks in my knowledge that I don't know, because
Speaker 2: I often feel and I think a lot of people
Speaker 2: who come into dev as a second career feel this.
Speaker 2: They feel like, oh, I missed out on something crucial.
Speaker 2: You know, there was something in a CS course that
Speaker 2: I never took that I never quite got And I
Speaker 2: think a lot of people feel that. But as it
Speaker 2: turns out, Typescript operates on a relatively high level. You know,
Speaker 2: you don't need to know a lot of the deep stuff.
Speaker 2: I'm still like, I still find it hard to explain,
Speaker 2: like covariance contravariance in a sentence. I never quite know
Speaker 2: if I'm using the terms correctly, and it has felt
Speaker 2: to me I feel like if learning that stuff would
Speaker 2: benefit the people learning typescript, I would teach it. If,
Speaker 2: for instance, contraveriance and covariance was mentioned in typescript errors,
Speaker 2: I feel like I would need to teach it. But
Speaker 2: as it turns out, me not knowing about that stuff,
Speaker 2: I think actually helps in terms of explaining it to people,
Speaker 2: because I'm not trying to layer on all of this
Speaker 2: extra kind of nomenclature and language onto what are relatively
Speaker 2: simple concepts. You know, if you understand what a subset
Speaker 2: and a superset is, you know, you can kind of
Speaker 2: understand what tapskipt's doing in a lot of cases. And
Speaker 2: so I do feel a bit like, oh, maybe it
Speaker 2: would have been good for me to do a CS
Speaker 2: course learn that stuff, But actually I think not knowing
Speaker 2: its not having the curse of knowledge, has benefited me
Speaker 2: in weird ways to making me closer to my learners.
Speaker 1: First of all, I totally get that. I also have
Speaker 1: to say, you know again, I even though I came
Speaker 1: into software the more traditional route, I actually started before
Speaker 1: I learned. So I did start as a hobbyist, you know,
Speaker 1: as a teenager, and then I, after several years of
Speaker 1: just basically you know, doing work whatever seemed to make sense,
Speaker 1: I went to university. But it's been so long that effectively,
Speaker 1: I think every technology that I've learned I'm no longer using,
Speaker 1: and every technology that I am using is stuff that
Speaker 1: I learned after I actually finished my universities, you know,
Speaker 1: that part of my career. So I totally get that
Speaker 1: a lot of what we learn is some is the
Speaker 1: stuff that we pick up along the way, and in fact,
Speaker 1: the thing that I love most it's the biggest challenge
Speaker 1: around working, I think in software development, but it's also
Speaker 1: the thing I love most is the fact that you
Speaker 1: constantly need to be learning stuff and updating your skill
Speaker 1: set and knowledge and whatever. And we'll probably get to
Speaker 1: how you yourself manage that, especially with typescript, but with
Speaker 1: other things as well. But before that, I would actually
Speaker 1: like to share something about the way that I got
Speaker 1: into typescript, which was a bit different than you, I think,
Speaker 1: or maybe maybe maybe not. We will see. I got
Speaker 1: into typescript a little bit earlier, around I think twenty fourteen,
Speaker 1: fifteen is the first time I actually encountered it, and
Speaker 1: I have to tell you that in my initial reaction
Speaker 1: was very negative. The reason was that back at that time, Microsoft,
Speaker 1: all the examples that they were that were coming out
Speaker 1: of Microsoft were around classes and interfaces, and they were showing,
Speaker 1: you know, this is how you implement class hierarchies and
Speaker 1: interfaces and doing it safely and stuff like that, and
Speaker 1: to me, it very much felt like Java or SEA sharp,
Speaker 1: And you know, I left Java and C sharp and
Speaker 1: went into and you know, got into JavaScript and enjoyed
Speaker 1: JavaScript much more than I ever did Java or C sharps.
Speaker 1: So the last thing that I wanted was to go back.
Speaker 1: I think that the terminology that I was using back
Speaker 1: then was this is a poor man's Java. And I
Speaker 1: basically said, you know, kind of a little bit reflected
Speaker 1: some of the attitudes that Dagge proclaims still to this
Speaker 1: day that you know, I like the freedom, I like
Speaker 1: the duct typing, the monkey patching. You know, I don't
Speaker 1: like to feel constrained. I've got tests as if I
Speaker 1: need guardrails and stuff like that. And it took me
Speaker 1: a while. It took me a couple of years to
Speaker 1: realize the value the typescript actually actually has. When I
Speaker 1: started using typescript without without classes in interfaces, did you
Speaker 1: go through a similar phase or was it great for
Speaker 1: you from the get go?
Speaker 2: So it was great for me from the get go,
Speaker 2: I have to say. And I feel like, I'm not
Speaker 2: sure when type scripts implemented geox, but that's what they did.
Speaker 2: They implemented gosex and a few sort of nice niceties
Speaker 2: to like basically work better with React. And I was
Speaker 2: working on a React app at the time that was
Speaker 2: in JavaScript, and we translated that over sort of slowly
Speaker 2: to typescripts kind of as we were working, and it
Speaker 2: was just great from the get go for me. So
Speaker 2: I never actually received that marketing of like, oh, this
Speaker 2: is the new c sharp or something, or this is
Speaker 2: like you know, I don't think I really sort of
Speaker 2: thought about classes and interfaces, and actually, to be honest,
Speaker 2: React was quite class based at the time, so no,
Speaker 2: I didn't have that. I immediately saw the value and
Speaker 2: I immediately started putting it in a React app, which
Speaker 2: was mostly functional.
Speaker 1: The other aspect of it that was initially problematic for me,
Speaker 1: and to an extent it still exists, I guess, is
Speaker 1: the fact that the way that at least initially I
Speaker 1: thought about it is that I would write a JavaScript
Speaker 1: code and then I would add the types in. And
Speaker 1: what happened was that the JavaScript code, at least initially
Speaker 1: would come very fluently, very flu very quickly, but then
Speaker 1: I would literally like sweat bullets adding all the typescript in. Now,
Speaker 1: part of it was that obviously I didn't know typescript
Speaker 1: well enough. Maybe I still don't, but also that I
Speaker 1: was doing, you know, doing some more extreme dynamic style
Speaker 1: coding with JavaScript, and that didn't really sit well with
Speaker 1: the way that you, you know, you might write script.
Speaker 1: So there I was like sweating bullets about getting the
Speaker 1: proper type interfaces and and I'm kind of anal about
Speaker 1: these things. You know, it has to be perfect, you know,
Speaker 1: it can't just be any or stuff like that. And
Speaker 1: I was thinking, hey, I'm spending more time on implementing
Speaker 1: the types than I am than I had been on
Speaker 1: the original logic in JavaScript, and it's it's weird because
Speaker 1: at the end of the day, all this type information
Speaker 1: is basically stripped out, so when it's actually executed, it's
Speaker 1: just the JavaScript back again. So here I am putting
Speaker 1: all this effort into something that has literally zero impacted runtime,
Speaker 1: and it felt kind of, you know, redundant.
Speaker 2: You can feel like, oh, the features done. You know,
Speaker 2: I can see it working. Why do I have to
Speaker 2: do all this extra effort to exactly to just paint
Speaker 2: it really, to just you know, the cars working. I
Speaker 2: don't care what it looks like. And I think if
Speaker 2: I were to rebut that I think because I do.
Speaker 2: I think I didn't have a long leading as like
Speaker 2: a JavaScript developer really before becoming a time script maybe
Speaker 2: two or three years or so. But folks who've been
Speaker 2: writing JavaScript for a long time before that, their habits
Speaker 2: are absolutely set, you know, like and all of that
Speaker 2: sort of dynamic stuff, you know, like the monkey patching
Speaker 2: and all sorts of patterns are kind of typescript. Makes
Speaker 2: you be a lot more boring, you know, it makes
Speaker 2: you right in quite a sort of dull way. You know,
Speaker 2: you don't get a lot of a lot of the
Speaker 2: same freedoms that you do when you're working in JavaScript.
Speaker 2: Of course, I would argue that is quite a good thing.
Speaker 1: You know.
Speaker 2: It means that code generally starts like each other. Boring
Speaker 2: is good, you know. Yeah, Boring is good. Boring is efficient.
Speaker 2: Boring means that you can switch projects easily. Boring means
Speaker 2: that you know, boring is good. And I would say
Speaker 2: that what I start doing now, having worked in tapic
Speaker 2: it for a long time, is I do more type
Speaker 2: driven development now, is I'm thinking about the types and
Speaker 2: the flow of the types really before I'm thinking about
Speaker 2: the runtime architecture perhaps sort of as part of that.
Speaker 2: And so I tend to type my function parameters before
Speaker 2: I implement them, so I'll just get all my functions
Speaker 2: in a row and understand what's happening, and then I
Speaker 2: I'll start to implement. So I think that is definitely
Speaker 2: for someone coming from a long time JavaScript background, that's
Speaker 2: quite alien, you know, because that's really I need to
Speaker 2: think about the types before I implement the rest of it.
Speaker 2: But that's how I'm certainly thinking about my type of death.
Speaker 1: So first of all, by the way, one of the
Speaker 1: things that also clicked for me was when I started
Speaker 1: thinking about it, like tests. Again, you can write all
Speaker 1: your code without tests, and tests themselves again have zero
Speaker 1: impact on runtime. They're not part of the runtime bundle.
Speaker 1: So again, you know, you could say, well, all the
Speaker 1: tests are stripped out effectively, but you know, I really
Speaker 1: hate cool bases without tests. You know, it makes me
Speaker 1: feel insecure. And even though I sometimes, like, you know,
Speaker 1: I'm lazy, I sometimes writing all the tests that I
Speaker 1: need to, but you know, at the end of the day,
Speaker 1: it's worth it. And I look at the same way
Speaker 1: with types, and I've gotten really to the point that
Speaker 1: I really can't write JavaScript anymore. Even I love JavaScript.
Speaker 1: JavaScript for a long time, it's been my favorite programming language.
Speaker 1: I've been doing it since nineteen ninety eight. I'm really
Speaker 1: dating myself, so yeah, for a long time, more than
Speaker 1: many of our listeners have been alive, maybe, But these
Speaker 1: days I'm literally like, I literally like, if I'm writing
Speaker 1: just pure JavaScript without the type definition, it feels like
Speaker 1: something is missing m And.
Speaker 2: I think a lot of people feel that way as well.
Speaker 2: That seems to be why typescript is so sticky. It's
Speaker 2: not like people adopt typescript and then in my next job,
Speaker 2: I'll just write JavaScript because that was too hardcore. No,
Speaker 2: people who tend to go into typescript, they don't tend
Speaker 2: to leave because you're right, it just doesn't feel the same.
Speaker 2: You just I think there was a quote from the
Speaker 2: Typescript documentary that really stuck in my head, which is,
Speaker 2: when you're writing in JavaScript, you feel like you're carving
Speaker 2: in stone. Basically, it's really hard to then change that.
Speaker 2: Resulting code code feels a lot less malleable, a lot
Speaker 2: less movable, a lot less portable. You just can't change
Speaker 2: it with the same rapidity and the same surreness, Whereas
Speaker 2: in typescript, if you move something to the wrong place,
Speaker 2: it will give you all these warnings. You can check
Speaker 2: your entire project, and you can have a lot more
Speaker 2: security that your code works the way you think it works.
Speaker 1: I totally agree, and this was actually, you know, I
Speaker 1: literally experienced this very recently, as in a few days ago,
Speaker 1: because that where I work with just some sense, we've
Speaker 1: got a lot of legacy code. And one of the
Speaker 1: topics that I'll probably bring up with you is you
Speaker 1: know how to deal with legacy stuff and how to
Speaker 1: port existing jobscript projects to typescript. And I see bugs
Speaker 1: in the code that could not happen if the code
Speaker 1: had been written in typescript. And you know, there are
Speaker 1: a lot of challenges in adding typescript into an existing
Speaker 1: jobscript project, especially a lot one. But for me, the
Speaker 1: biggest challenge from what I see, is fixing all the
Speaker 1: bugs that you discover when you add typescript, because ideally,
Speaker 1: adding typescript into an existing job skiped project is basically
Speaker 1: just adding types, don't You don't want to be touching
Speaker 1: the business logic. But what I find is that I run,
Speaker 1: I find bugs in the business logic which I then
Speaker 1: need to fix. And and this to me is like
Speaker 1: the biggest hassle of adding job typescript into an existing
Speaker 1: job script project.
Speaker 2: M I mean, that's quite a good hassle to have, right,
Speaker 2: you know, like the hassle of making your code better.
Speaker 2: I suppose. I mean, in some ways, you know, it
Speaker 2: makes you code a bit more defensively. You need to
Speaker 2: make sure that you know that your inputs are all correct.
Speaker 2: But yeah, you're absolutely right. And that was definitely the
Speaker 2: experience we had is that when I first introduced type
Speaker 2: script in that very first project, is oh wow, that's
Speaker 2: a code path I just didn't see what's possible, or yeah,
Speaker 2: that's okay. That could either be a string union or
Speaker 2: string or number in that place instead of just a number.
Speaker 2: You want to dive into like how to migraines, because
Speaker 2: I've definitely got some advice there.
Speaker 1: Yeah, you know what. I was saving it for later,
Speaker 1: but it seems to naturally fit in here. So let's
Speaker 1: say I'll give the background. Let's say I have a
Speaker 1: large scale existing JavaScript project. Maybe it's React, maybe it isn't.
Speaker 1: I don't know if it matters really and and no
Speaker 1: typescript insight, and I want to add typescript into this project,
Speaker 1: you know I can. What's the best approach? Should I do,
Speaker 1: like like sit down and just try to do it
Speaker 1: all in one go? Should I do it incrementally? And
Speaker 1: if so, you know, what would be the unit size?
Speaker 1: How do I estimate the effort? How do I justify
Speaker 1: it to product and management? And I'm going to be
Speaker 1: spending all this time yet not adding a single feature
Speaker 1: into the product. You know, what can you say about it? Yeah?
Speaker 2: So it's a huge topic. Let's add another assumption as well.
Speaker 1: Well.
Speaker 2: Let's assume that the code base is actively being worked on,
Speaker 2: and that there's features being added as well, because that
Speaker 2: seems to be the most common case.
Speaker 1: Oh yeah, for sure. If it's not worked on, then
Speaker 1: what's the point Almost exactly right.
Speaker 2: So, like you're working on an active codebase, you need
Speaker 2: the CI to remain green all times as well. You
Speaker 2: don't want to be doing things which make the CI
Speaker 2: read for a certain period of time, and you don't
Speaker 2: want to be messing people's stuff up. So there are
Speaker 2: a few ways that you could do it. You could
Speaker 2: take every single JavaScript file, turn it into a typescript file,
Speaker 2: just like with a command or something, and then you
Speaker 2: know you're in type script with zero types. And then
Speaker 2: perhaps you could ramp down the strictness to the point
Speaker 2: where you get zero errors. Right, there's one way to
Speaker 2: do it. That's a bad way to do it. The
Speaker 2: reason for that is that, first of all, you break
Speaker 2: everyone's prs. You know, if anyone has any existing prs,
Speaker 2: then they literally can't you know that you would have
Speaker 2: to do all sorts of shenanigans to make them.
Speaker 1: Basically, they probably want to tell everybody we're doing it
Speaker 1: on this week, merge all your prs, don't create any
Speaker 1: new prs, and this is what we're doing.
Speaker 2: Yeah, big disruption you know, no good, especially to a
Speaker 2: big team working on a big mono REAPA, let's say.
Speaker 2: And then the thing that's hard after that is that
Speaker 2: it's really hard to ramp up the strictness in a
Speaker 2: way that's incremental, because you want the CI to stay green.
Speaker 2: And if you say, okay, today we're going to turn
Speaker 2: on the know any rule, then you turn it on
Speaker 2: and it affects your entire codeies, so the CI is
Speaker 2: basically red. So I think that that approach which a
Speaker 2: lot of people do take of turning every file into
Speaker 2: a touch grip file is a bad approach because what
Speaker 2: you should do, I think instead is you should add
Speaker 2: in a ts comfig into your projects, and you should
Speaker 2: install typescripts, and you should choose the highest level of
Speaker 2: strictness that you're going to get your desired level of strictness.
Speaker 2: And when you do that, you then take it file
Speaker 2: by file and you're just turning basically in one PR
Speaker 2: you would just turn one file into a touch gript file,
Speaker 2: and by doing that you might find external libraries that
Speaker 2: need to be important types and stuff, and you fix
Speaker 2: the types in there you can use like any at
Speaker 2: this point as well, you know, if you need to,
Speaker 2: if you need to get around it. But that's what
Speaker 2: I would start with. And the key there is that
Speaker 2: the order of the files that you choose is really important, right,
Speaker 2: because let's imagine that your code base is like a tree.
Speaker 2: You know, you've got the files that are imported very often,
Speaker 2: sort of at the top of the tree and sort
Speaker 2: of like spreading down like that, and the files that
Speaker 2: are used in lots of places. You want to do
Speaker 2: those first, and you want to translate in touch script first.
Speaker 2: The ones with the fewest dependencies You can use a
Speaker 2: tool like match I think to basically walk up the tree.
Speaker 1: You want the ones you want to start with the
Speaker 1: ones that have the fewest, that depend on the fewest things,
Speaker 1: and but on the other hand that a lot of
Speaker 1: stuff depends on them. That way you you create small
Speaker 1: disruption but quickly bring on the most amount of value.
Speaker 2: Yes, And the reason for that is so like your
Speaker 2: utilities folders for instance, or the files that contain you know,
Speaker 2: math or something or things.
Speaker 1: That we use which project does not have a utilis folder.
Speaker 2: Exactly right, that's where you want to start. The reason
Speaker 2: is is that if you start further down the tree,
Speaker 2: then your touch grip code is going to be depending
Speaker 2: on JavaScript code, and that's a really nasty place to
Speaker 2: be because all of the JavaScript code is just going
Speaker 2: to produce any's and so that anys are then going
Speaker 2: to filter through, whereas if you start with a typescript
Speaker 2: file that has no JavaScript dependencies, you're going to be
Speaker 2: in a really really good spot. And then you just
Speaker 2: slowly go down the tree. And so Century has an
Speaker 2: amazing article about this. They basically did this for Yeah,
Speaker 2: I'll drop a link certainly later, but if you google
Speaker 2: Century Typescript, it will come up and that's Century the Eralogua,
Speaker 2: not like you know, a century of time. And what
Speaker 2: they did was they basically said, Okay, we're just going
Speaker 2: to share this out among the devs. Whenever you have
Speaker 2: a free minute, whenever you finish your tasks for the sprint,
Speaker 2: just translate a typescript file and go down this list
Speaker 2: of all of our dependencies. And so they slowly did
Speaker 2: that over the period of about two years, and it
Speaker 2: took them a while to get it done. And I
Speaker 2: think there are still files in that codebase. It's an
Speaker 2: open source code base as well. There are still javascripts
Speaker 2: and mostly like tests and things that they just haven't
Speaker 2: needed to change. But every new file, of course, is
Speaker 2: still in typescripts. And so that was the process they followed,
Speaker 2: and I think it worked really really well. I interviewed Priscilla,
Speaker 2: one of their devs for my course, and she sort
Speaker 2: of explained the whole thing, and that is the process
Speaker 2: I would follow. Basically, make a dependency tree, workout which
Speaker 2: ones to do first, add in a TS conflict with
Speaker 2: the maximum strictness, and go file by file, keeping that
Speaker 2: CI always green, making sure you're not stepping on anyone's prs,
Speaker 2: and maybe during people's trs they can tend to script.
Speaker 1: Do you know what occurred to me, Maybe is an
Speaker 1: idea for a feature. If anybody from the typescript dev
Speaker 1: team is listening, or maybe you'll tell me it's a
Speaker 1: stupid idea, and in which case, don't do it. It
Speaker 1: might it might be beneficial to have like two levels
Speaker 1: of Typescript support. So if your typescript or TS or
Speaker 1: TSX file, then you go with the strictest definition, but
Speaker 1: there's a transitional period that your work. You're taking a
Speaker 1: JavaScript file and then you're transition translating into into TS.
Speaker 1: It might have been beneficial to have like a TS
Speaker 1: star or TS you know, TS two whatever file that
Speaker 1: that has like less strict settings, so which would allow
Speaker 1: you to gradually get that file to where you want
Speaker 1: to go without having too lower And that's because one
Speaker 1: of the things that I'm seeing is that, unfortunately, at
Speaker 1: least with some of these legacy projects, some of the
Speaker 1: files are pretty large. You unfortunately encounter like a one
Speaker 1: thousand and nine file. And now obviously you can say, okay,
Speaker 1: then part of the project is also splitting up such
Speaker 1: large files into smaller files. But that significantly increases the
Speaker 1: scope of the project. So ideally you would like to
Speaker 1: handle that, you would like to keep the file structure.
Speaker 1: It's also good good forget and stuff like that. And
Speaker 1: in that context, taking a one thousand line file and
Speaker 1: turning it all into strict from JavaScript into script type
Speaker 1: script in one go can be fairly challenging. Now, obviously
Speaker 1: you can turn off various rules in the scope of
Speaker 1: that particular file, I guess, but that's a pretty big asp.
Speaker 2: Not quite, I mean, you could, I suppose, I mean,
Speaker 2: there is a very complicated way of doing that. But
Speaker 2: in general, if you have a typescript project, the rules
Speaker 2: apply equally to every file. Essentially, one thing you could
Speaker 2: do with a file like that is just use any
Speaker 2: in lots of places or ts ignore all the errors
Speaker 2: or yeah.
Speaker 1: But then but then that means that you need to
Speaker 1: support any everywhere, which you may not want to do.
Speaker 2: Yeah, and if it's a file that's dependent on a lot,
Speaker 2: then if you have any in that top file, it's
Speaker 2: going to spread down like a virus into all the others,
Speaker 2: you know, exactly, Yeah, it's it's just hard. I think
Speaker 2: there will be situations like that. And honestly, starting with
Speaker 2: the utils folder, that's probably going to be the hardest
Speaker 2: to type.
Speaker 1: Right.
Speaker 2: You might end up needing some generics in there, some
Speaker 2: generic types and generic functions because those that so, but
Speaker 2: you might need that, and that's a hard place to
Speaker 2: start if you're just beginning a typescript migration and upskilling
Speaker 2: your team. So usually you do need someone who's going
Speaker 2: to be you know, the type script wizard on that
Speaker 2: team to tackle the utils file so that everyone else
Speaker 2: can benefit.
Speaker 1: Basically, whichly to another point, I've talked to people who
Speaker 1: are basically like thinking about doing this transition, and they said, well,
Speaker 1: the code base is one challenge. But the other challenge
Speaker 1: is my developers. Now these days, it's you're getting more
Speaker 1: and more front end or JavaScript developers that are effectively
Speaker 1: typescript developers, but there are still a lot of JavaScript
Speaker 1: developers who are not typescripts out there. And the reality
Speaker 1: is is that I had a team to tell me,
Speaker 1: you know, you want us to go full typeescript, but
Speaker 1: my debs don't really know Typescript. And it's a problem
Speaker 1: if I effectively have my developers working in a programming
Speaker 1: language that they don't know, what we will end up
Speaker 1: is them using a lot of Any's and if I
Speaker 1: don't allow them to use Any's, then they'll potentially get stuck.
Speaker 1: And now, obviously, you know, you're obviously working to address
Speaker 1: that by teaching developers Typescript, But if I have an
Speaker 1: existing team, like, what would be the best way to
Speaker 1: get the team into typescript, Well.
Speaker 2: I mean, the cool thing about Typescript is that it's
Speaker 2: not a really heavy lift in terms of learning. If
Speaker 2: this is what I don't like about other languages that
Speaker 2: are sort of trying to solve the same problem as Typescript,
Speaker 2: which is basically adding a type system to JavaScript. So
Speaker 2: things like OKAML or I'm not sure. I don't know
Speaker 2: okammeill that well, but I know that's one of its uses.
Speaker 2: Risen mL ELM, things like that. I don't like those
Speaker 2: because there are much heavier lift in terms.
Speaker 1: Of learning different programming language, different.
Speaker 2: Programming language, whereas and typescript people will say, surely that's
Speaker 2: a different programming language, isn't it. Well no, I don't
Speaker 2: think so. It's really just a sort of set of
Speaker 2: decorations on top of JavaScript, and you're using a lot
Speaker 2: of the same intuitions as you have in javascripts just
Speaker 2: to be able to add types to it. So I
Speaker 2: think when you do that, you do need someone who
Speaker 2: I think can lead or be the go to person
Speaker 2: at that company who can answer people's typescript questions. So
Speaker 2: I think a team that's just sort of like with
Speaker 2: zero typescript knowledge whatsoever going into a tapkript migration is
Speaker 2: I think going to have a pretty tricky time unless
Speaker 2: they invest in some resources to help them out. But yeah,
Speaker 2: you do need that person at the company who can
Speaker 2: just be the go to typescript wizard to say, help
Speaker 2: me out please. I'm just I'm just stuck on a
Speaker 2: problem because if you don't develop that intuition, it can
Speaker 2: take a while to muscle through on your own. But
Speaker 2: I think the basics of typescripts, I think you can
Speaker 2: get productive in tap script pretty quickly. Was that your
Speaker 2: experience of learning it?
Speaker 1: Well, to be fair, I came into typescript as a
Speaker 1: as a very experienced developer who's been around the block,
Speaker 1: and I actually started with statically type language. Well that's
Speaker 1: not actually true. I started with basic, but I pretty
Speaker 1: soon got into statically type languages. So most of the
Speaker 1: most of my programming career was actually spent in statically
Speaker 1: type languages to an extent. Going to JavaScript, I felt
Speaker 1: deliberation into an extent, and of putting all the static
Speaker 1: types behind and and you know, just saying, you know,
Speaker 1: the wild wild West, as it were, of you know,
Speaker 1: it can be whatever, uh, and dynamic object structure and whatnot.
Speaker 1: I by the way, one of the things that I
Speaker 1: like to say about typescript is that the tasks that
Speaker 1: they pick for themselves is literally herding cats. Because you
Speaker 1: have the poster chart for dynamically dynamic programming, you know,
Speaker 1: programming language which is not only dynamically typed, but dynamically
Speaker 1: structured and and everything is about duct typing and stuff
Speaker 1: like that, and then you're trying to, uh, you know,
Speaker 1: implement a static type system on top of that. It's
Speaker 1: it's it's pretty amazing what the types of the team
Speaker 1: has been able to achieve in that context. And I
Speaker 1: guess we'll get into some of the finer points if
Speaker 1: we have some time later on in this podcast. So,
Speaker 1: for example, I learned generics or templates as they were
Speaker 1: called in C plus plus. So by the time that
Speaker 1: I got to typescript the concept and then I used
Speaker 1: them in Java and in C sharps. So by the
Speaker 1: time that I got to typescript, that was already familiar
Speaker 1: with these concepts. So it was less of a hurdle
Speaker 1: for me. Then it might then it might have been,
Speaker 1: you know, had I not had that background.
Speaker 2: M hmm, I think you can. One thing that occurs
Speaker 2: to me is that you don't necessarily need to learn
Speaker 2: the really advanced parts of typescript in order to get
Speaker 2: productive with it. Often there are kind of like I
Speaker 2: think there are kind of two areas or possibly three areas. Actually,
Speaker 2: I think in terms of the level of typescript that
Speaker 2: you need to interact with it, which is you probably
Speaker 2: need someone on your team who's able to write kind
Speaker 2: of library level Typescript code, you know, like someone.
Speaker 1: Who killed folder exactly. Let's let's hold on off on
Speaker 1: that because I actually want to get into that specific
Speaker 1: point and and a bit later in our conversation, and
Speaker 1: before that, I have I have a different question for you.
Speaker 1: So what I really wanted you to ask. So you're
Speaker 1: obviously a Typescript aficionado. You really love the concept, you
Speaker 1: love you love the language. But by the way, one
Speaker 1: of the other things that I think we forgot to mention,
Speaker 1: but the big reasons for Typescript success, it's just the
Speaker 1: integration with development environments. This whole thing about you know.
Speaker 1: One of the things that kind of came out in
Speaker 1: that video that you mentioned about Typescript was the fact
Speaker 1: that you can look at it as a programming language,
Speaker 1: but you can also look at it as a tool
Speaker 1: uh and and tool for the JavaScript programming language. Uh.
Speaker 1: And the great integration that you had from almost day
Speaker 1: one with vs code is I think it made a
Speaker 1: huge difference. Obviously, now you also get the same level
Speaker 1: of integration with you know, with other tools like web
Speaker 1: Storm or whatever, but without that level of integration, I
Speaker 1: don't think. So the whole thing of this typescript service
Speaker 1: that's running on your computer and that the editor can
Speaker 1: communicate with it and it does all the type checking
Speaker 1: for you in real time. So that was a huge win.
Speaker 1: And coupled with that is all the type information that
Speaker 1: they created for existing frameworks and libraries. So all of
Speaker 1: a sudden, even if I'm just working in JavaScript and
Speaker 1: not Typescript, I'm getting a lot of the benefits of
Speaker 1: Typescript totally.
Speaker 2: So this was about eleven years ago when Timescript first
Speaker 2: kind of came out. And the thing that I think
Speaker 2: a lot of people probably or brought a lot of
Speaker 2: people in was one of my friends called Johnny Riley,
Speaker 2: who ran the definitely typed repo. He spent a weekend
Speaker 2: I think when his son was very very small, making
Speaker 2: typesquery and basically like typing jQuery, so you suddenly had
Speaker 2: autocompletes for everything jQuery could do, and he wrote these
Speaker 2: beautiful jas dot comments which are still there to this day.
Speaker 2: And I don't know, I mean that level of integration,
Speaker 2: the fact that not only was Typescript and vs code
Speaker 2: kind of being built at the same time, but typescripts.
Speaker 2: The VSC team went to the typescript team and said,
Speaker 2: we hear what you're working on is pretty cool. Do
Speaker 2: you mind if we use it to build VS code?
Speaker 2: So I don't think VS code because it was such
Speaker 2: a complex jawscript application. They really wanted a strongly typed language,
Speaker 2: so they were built actually at the same time using
Speaker 2: really within Microsoft Amazing.
Speaker 1: I just do. Yeah, that's the other thing I know.
Speaker 1: I mean when I look at projects that somehow get
Speaker 1: by with our typescript, they're usually very small, and it's
Speaker 1: a legitimate thing. But all the projects that I've been
Speaker 1: working on in the world of JavaScript development, be it
Speaker 1: in the browser or be it in node, in the
Speaker 1: past decade have been really large. I mean projects where
Speaker 1: you've got teams of at least ten, sometimes as large
Speaker 1: as fifty working on code basis that can be up
Speaker 1: to a million lines of code. Doing that without typing
Speaker 1: is bordering on insane.
Speaker 2: Yeah, because I mean, just in very simple terms, when
Speaker 2: you're working on like, the more developers you add to
Speaker 2: the projects, the more likely you are that one of
Speaker 2: those developers is going to make a mistake. You know,
Speaker 2: just the number of mistakes goes up as the number
Speaker 2: of developers working on something goes up. It's just you
Speaker 2: know how maths works, and when you have something that
Speaker 2: you can just sort of stick in a project, you
Speaker 2: can run on your CI Let's say, you know, whenever
Speaker 2: a pr comes in and just check if anyone's made
Speaker 2: a typo, check if a whole class of those mistakes.
Speaker 2: That's just so valuable for teams, and especially when you
Speaker 2: have code that's being worked on at the same time
Speaker 2: you want to check if that code is compassible with
Speaker 2: each other. Having an automated system for doing that is incredible.
Speaker 2: And of course touch Coupe doesn't catch everything, but it
Speaker 2: catches an enormous amount for a very low or comparatively
Speaker 2: low level of effort.
Speaker 1: I totally agree. And there's the other side of it,
Speaker 1: which is the fact that jobscript is so very forgiving,
Speaker 1: and so is the browser, and so so are basically
Speaker 1: in almost any environment that runs JavaScript. So you know,
Speaker 1: again people would say, why do I need JavaScript, I've
Speaker 1: got tests. But the thing is that the environment is
Speaker 1: so forgiving that you can have a catastrophic failure and
Speaker 1: still pass the test. So unless the test is specific enough,
Speaker 1: you can still get by with bugs. Like I mentioned
Speaker 1: before that I'm fixing legacy software, I'm catching a lot
Speaker 1: of bugs. These are often systems that have uh end
Speaker 1: to ntest that's saying place and the end to ntest
Speaker 1: pass because the browser is such a forgiving environment. But
Speaker 1: it doesn't change the fact that you you've had a
Speaker 1: stupid bug in there that you know, you've got some
Speaker 1: undefined in there where you should have had some value
Speaker 1: and it's somehow able to buddle through until you know
Speaker 1: maybe it does it anyway, So I would like to
Speaker 1: get to the next my next question. And you know,
Speaker 1: typescript keeps evolving, uh and and getting new features. What
Speaker 1: version are we at? Five point what.
Speaker 2: I think we're five point seven now? Is that right?
Speaker 2: Let me check five point seven is the new beta
Speaker 2: that's coming out, So I'm pretty sure.
Speaker 1: Okay, So first of all, let's start with with one thing.
Speaker 1: Let's start with what do you I think we kind
Speaker 1: of covered it, but maybe you can be more explicit
Speaker 1: about it. What do you like most about Typescript? But
Speaker 1: the other side of that equation, is there anything that
Speaker 1: you hate about typescript? And if so, what is that?
Speaker 2: Yeah, so there are lots of things I don't like
Speaker 2: about typescript. Definitely lots of things. I think they could
Speaker 2: improve features I wish they would add. I think we've
Speaker 2: got we've got the love. The thing I love is
Speaker 2: that it makes my ide ten times more powerful, It
Speaker 2: makes developing stuff easier, makes me feel more secure. So
Speaker 2: let's go on to the fun stuff. The stuff I hate. Flow,
Speaker 2: which is Meta's sort of version of typescripts. It's a
Speaker 2: version of strongly type JavaScript. It has something called exact
Speaker 2: object types. What that means is that if you create
Speaker 2: an object in flow and you say, okay, this is
Speaker 2: this is an object of this type, then you basically
Speaker 2: can't add any extra properties to it. So if you
Speaker 2: have an object with ABC, then you can never in
Speaker 2: any situation in flow add a d property to it.
Speaker 2: But in Typescript, in various situations you can do that.
Speaker 2: So touch script has open objects, objects that are open
Speaker 2: to extension, and that means that in various places you
Speaker 2: can actually get into situations where you have these random
Speaker 2: sort of properties kind of floating about. And if we
Speaker 2: if we were doing code, I could show you. But
Speaker 2: you can read my chapter of my book on exact
Speaker 2: object times, which is free by the way is you know,
Speaker 2: just google.
Speaker 1: It and what that means. Book. By the way, it's a.
Speaker 2: Total type Script Essentials, So if you go to total
Speaker 2: touch gript dot com clickbook, you'll you'll.
Speaker 1: Find it and recommended.
Speaker 2: Oh, thank you very much. This means that various things
Speaker 2: in touch script are not as good as they could be.
Speaker 2: So object dot keys, for instance, when you're iterating over
Speaker 2: an object's keys, when you iterate over a B and C,
Speaker 2: you would expect the type of that to be a
Speaker 2: B or C as aws a B or C, but
Speaker 2: in fact it's just a string, so it's extra wide.
Speaker 2: So it's wide because it's sort of it knows time
Speaker 2: script knows are well it could contain D and I
Speaker 2: don't actually know about that. And that means that that
Speaker 2: extra wide type sort of gets a bit frustrating to use,
Speaker 2: because when you go to index back into that object,
Speaker 2: it's horrible. So I wish, I wish, I wish, I
Speaker 2: wish timescript had exact object keys.
Speaker 1: I think it's something you can configure somehow with tears configure.
Speaker 2: It's just so baked into the way that typescript works
Speaker 2: that it's impossible to go back. It's a feature I
Speaker 2: wish they could add, but I I would be shocked if.
Speaker 1: They managed to do it, honestly, So you're saying it's
Speaker 1: such an integral or core aspect of the way in
Speaker 1: which they structured types of the language that backtracking on
Speaker 1: that on this now would be extremely hard, like adding
Speaker 1: a brilliant flag in the configure. Theoretically be possible, but
Speaker 1: practically it would be very.
Speaker 2: Challenging, very very tough. And I suppose they could add
Speaker 2: some sort of keyword, you know, like the exact keywords
Speaker 2: to make make it work, because Flow has exact objects
Speaker 2: by defaults, but you can make them like typeescript if
Speaker 2: you want to opt in. But yeah, I just don't
Speaker 2: think they they do it, because it does have benefits too.
Speaker 2: It's it means that you can pass wider objects to
Speaker 2: smaller ones, which is useful when you're doing things with
Speaker 2: classes and stuff. But I don't think they're gonna they're
Speaker 2: going to get around to it, which is a shame.
Speaker 1: M anything else, then you would wish.
Speaker 2: There's a lot of there's some more complex stuff, like
Speaker 2: the way that typescript works with generic functions. If you
Speaker 2: can actually pass types to certain functions. But then if
Speaker 2: you pass one type, then any other types that you
Speaker 2: don't pass don't get automatically inferred. So this is called
Speaker 2: the partial inference problem. I wish they would bloody fix that.
Speaker 2: I was talking to Tannel Linsley about this, I think
Speaker 2: three years ago, and he was saying, Oh, they might
Speaker 2: fix it, and they've been shaping up to maybe fix it.
Speaker 2: But it just makes certain APIs impossible basically you, and
Speaker 2: it makes things a little bit harder.
Speaker 1: So I would love to fix that too, you know what.
Speaker 1: I was saving this question for later, But since you
Speaker 1: brought up type inference, maybe you can explain briefly what
Speaker 1: type inference means, and then you might say what is
Speaker 1: your attitude towards type inference, Like if there is a
Speaker 1: place where type can be inferred, should it always be
Speaker 1: inferred or do you prefer to be explicit sometimes or always?
Speaker 1: So let's start with what is type inference and go
Speaker 1: from there.
Speaker 2: Yeah, so let's imagine you have a function and that
Speaker 2: function can either take in a string or a number.
Speaker 2: Then there are some things that Tychkriit can't infer. Like
Speaker 2: let's say you're creating a function. Whenever you create that
Speaker 2: function in strict mode, you have to annotate the parameter.
Speaker 2: That's usually where most people are writing their types. Actually,
Speaker 2: So imagine this function takes an input of string or number.
Speaker 2: Then we do like an if statement and we check
Speaker 2: if the input is a string. If we do, then
Speaker 2: we call like input dot two upper case or something.
Speaker 2: Otherwise we do something else. So if you imagine, there
Speaker 2: are kind of three blocks there. There's the function, there's
Speaker 2: the first if statement where we were checking if it's
Speaker 2: a string, and the second if statement if we'd check
Speaker 2: in if it's a number. Now, without this magical thing
Speaker 2: called inference, we would have to add types in all
Speaker 2: those places. Right, we have to say, Okay, it's a
Speaker 2: string or number up here, it's a string here, and
Speaker 2: it's a number here. But Typescript can actually infer that
Speaker 2: based on the behavior of our code, based on the
Speaker 2: It just looks at the code. It says, oh, yeah,
Speaker 2: it's an if statement that's checking this thing. It must
Speaker 2: only be a string in this particular closure.
Speaker 1: By the way, just to interrupt you briefly, that was
Speaker 1: one of the magical aspects for me of Typescript that
Speaker 1: initially didn't get because again I came into, as I
Speaker 1: said before, my background was from language statically type languages
Speaker 1: which usually don't need these types of shenanigans because something
Speaker 1: is a strict type, you don't have to infer that, hey,
Speaker 1: it's this type in this context and that type in
Speaker 1: that context. You might do some crazy stuff around templates
Speaker 1: to narrow to narrow the passing types, but within the
Speaker 1: code itself, you don't. And it took in the realization
Speaker 1: that you that typescript does static analysis of your code
Speaker 1: and narrows the types based on what it reads in
Speaker 1: your actual code, like ifs and stuff like that, and
Speaker 1: now you also have type guards and stuff like that.
Speaker 1: That was pretty amazing to me. And once I realized
Speaker 1: that that was one of the things that really like
Speaker 1: got me to to really appreciate typescript one.
Speaker 2: Hund And it's such a hard problem as well. I
Speaker 2: imagine building that from scratch, you know, something that looks
Speaker 2: at your code and understands, okay, in all of these places,
Speaker 2: this is what type these values are. It's crazy. They
Speaker 2: pulled it off. So it works. This is what's called
Speaker 2: narrowing in typescripts. You know, it works with switch statements,
Speaker 2: works with objects, works with now it actually works with
Speaker 2: functions too, So you can create a function that checks
Speaker 2: if something is a string and it will automatically. You
Speaker 2: don't need to add any type annotations apart from just
Speaker 2: the input. It's amazing the way it works. So that's
Speaker 2: what type inference is. It's typeescript looking at your runtime
Speaker 2: code and inferring the types from it. And I have
Speaker 2: an exercise in my course where I basically say, okay,
Speaker 2: we do all of this code, and I basically annotate
Speaker 2: every single place that you could possibly annotate, you know,
Speaker 2: like on variables, on function parameters, on function return types
Speaker 2: as well.
Speaker 1: And I just saw return types, by the ways, where
Speaker 1: I usually think about inference, Like you said, parameters usually
Speaker 1: need to be typed, I mean, because you really can't
Speaker 1: infer the parameters. That's the entry point. But the exit
Speaker 1: point is certainly the place there's something that you can
Speaker 1: often infer, Like you know, if it's an AD function
Speaker 1: that takes A and b in returns A plus b.
Speaker 1: If both A and b are numbers, then obviously A
Speaker 1: plus b is a number. So yeah, So the question
Speaker 1: then really becomes if the function return type can be inferred,
Speaker 1: should I be explicit about it or should I just
Speaker 1: let typescript inferred.
Speaker 2: Yeah, so this I go back and forth on this.
Speaker 2: This is a tricky question, and there are various cases
Speaker 2: where it's obvious that you should type the return time
Speaker 2: because what you're saying is when you create your function definition, basically,
Speaker 2: the types at the top are your description of how
Speaker 2: the function should work, and when you're in let's say
Speaker 2: a library setting or a utils folder setting, you probably
Speaker 2: always want to create those types actually, because it's a
Speaker 2: way for someone who doesn't want to read the body
Speaker 2: of the function to just go, oh, I see what
Speaker 2: this is doing, right, I understand. Okay, it's a function
Speaker 2: that takes in a string and returns an object with
Speaker 2: a value in our something. So what it means then
Speaker 2: to type those is that it gives you a contract
Speaker 2: that you have to be able to meet. And so
Speaker 2: it means that this is type driven developments. You're taking
Speaker 2: the types and saying this is what I want to create,
Speaker 2: and then you're creating it. If you don't do that,
Speaker 2: then it does give you a bit more flexibility. It
Speaker 2: means that the things that you're returning, for instance, from
Speaker 2: your function are just like automatically inferred. This is a
Speaker 2: really good, a really good example is React components. For instance,
Speaker 2: they are always every single React component is always going
Speaker 2: to return the same type, always going to return a
Speaker 2: type of React dot React node because you're just returning
Speaker 2: gsx so in every single React component, so you're going
Speaker 2: to be returning the same thing, And to annotate React
Speaker 2: components return type just seems a bit weird to me.
Speaker 2: There are link rules that force you to add a
Speaker 2: type to every single function return, and I find those
Speaker 2: extremely annoying because there are tons of use cases and
Speaker 2: tons of cases where I don't want to add the
Speaker 2: return type at all. But it is sometimes beneficial to
Speaker 2: just give yourself a guardrail, give yourself a contract that
Speaker 2: you need to meet, And honestly, I find myself doing
Speaker 2: it more and more and more because it just feels
Speaker 2: good to be able to say this function does this
Speaker 2: thing and then implement it.
Speaker 1: So basically you're saying is if I'm I'm doing the
Speaker 1: function outside in I'm actually specifying the function parameters and
Speaker 1: return types before I write the function body, then I've
Speaker 1: got the return type as a validation that what I'm
Speaker 1: returning actually matches that type. So I get two benefits.
Speaker 1: I get, You know, anybody looking at the function declaration,
Speaker 1: knows what the function will be returning without having to
Speaker 1: read the code. Although you know, there's an interesting point
Speaker 1: about that. I'll get to that in a second. And
Speaker 1: the other aspect is that the fact that you're providing
Speaker 1: a guardrail for yourself making sure that you are in
Speaker 1: fact returning the correct type. Yep.
Speaker 2: Absolutely.
Speaker 1: The interesting thing is, again looking at my experience with
Speaker 1: other statically type programming languages, there are programming languages that
Speaker 1: actively advocate the type inference approach, where ideally you even
Speaker 1: though they're statically typed, their inference is so good that
Speaker 1: you're expected to hardly ever write any types because it's
Speaker 1: it's basically you don't need to think what the type,
Speaker 1: what the types are, which again, which again takes me
Speaker 1: back to this aspect, because in a sense, if I
Speaker 1: don't really if if if my all my assignments are initializations,
Speaker 1: m so all my variables are calls like not variables,
Speaker 1: they're they're mutable to an extent, I don't need to
Speaker 1: think about I almost don't need to think about the type.
Speaker 1: So I'm assigning the return value of a function into
Speaker 1: a variable. It is what it is. I know that
Speaker 1: whichever way I use it is correct. I can only
Speaker 1: pass it into the appropriate functions, or if I do
Speaker 1: the dot, I'll get the correct completion. I don't need
Speaker 1: to be explicit about the type.
Speaker 2: There are situations where, of course, you do want to
Speaker 2: be explicit about the type, where you know, you know
Speaker 2: more about the type that something should be than typescript
Speaker 2: can infer from the run time. A really good example
Speaker 2: of this is like index signatures. So, for instance, if
Speaker 2: you have an object that you know, okay, I'm going
Speaker 2: to be adding keys to this dynamically like IDs for instance,
Speaker 2: and they're going to have this value of property on them,
Speaker 2: then you need to tell touch script that upfront, because
Speaker 2: if you just initialize like an empty object, then touch
Speaker 2: is just going to infer it as an empty object basically.
Speaker 2: And so I'm adding that level of you making a map.
Speaker 2: But even with a map, you need to you know.
Speaker 1: Yeah, maplicit. Yeah, you're obviously exhisit about the time. By
Speaker 1: the way, one of the things that kind of also
Speaker 1: blew my mind about modern typescript is how you can
Speaker 1: create types with string expressions that you can actually structure.
Speaker 1: Is say, not we give example before about keys that
Speaker 1: it's not just any string. It's it's the keys of
Speaker 1: an object. But it also can be a particular structure
Speaker 1: of a string, so a string that has like hello
Speaker 1: at the beginning or something like that, which is pretty
Speaker 1: insane to me.
Speaker 2: Yeah, if you, if you're following on at home, if
Speaker 2: you've got us in your ear and you're at your laptop,
Speaker 2: try just typing crypto dot random you U, I, D
Speaker 2: and call the function and see what if you just
Speaker 2: hover over the thing that it returns, you'll see that
Speaker 2: it returns basically it what it returns in real life
Speaker 2: is like a UID, so it's like five parts of
Speaker 2: a string separated by dashes, and you'll see in the
Speaker 2: return time that it actually does the same thing on
Speaker 2: the type level. It's crazy. It's crazy that you can
Speaker 2: basically represent these strings in a type safe way. It's
Speaker 2: absolutely wonkers.
Speaker 1: Another thing that really confused me initially when I got
Speaker 1: into typescript, because again of my actually my background with
Speaker 1: type languages working against me, with statically type languages working
Speaker 1: against me, was the document dot create element. The fact
Speaker 1: that the type returned was based on the string parameter
Speaker 1: passed into that function kind of blew my mind. This
Speaker 1: was not C plus plus. They're like, you know this,
Speaker 1: it's the fact that you know they had to do
Speaker 1: it from the get go because otherwise create element would
Speaker 1: have been pretty useless. And it's part of the dome.
Speaker 1: But the fact that if you pass in the string
Speaker 1: div the time, the return type is is HTML div,
Speaker 1: but if you pass in span, it's HGML span. If
Speaker 1: it's a button, then it's HML button. It's pretty insane
Speaker 1: to me. Yeah, and I think that was from day one.
Speaker 2: Yeah, I think because that's that's another thing that tapskib
Speaker 2: does too. Is it just it gives you a lot
Speaker 2: of confidence in these dom APIs, and some of the
Speaker 2: domapis are pretty funky, you know, in terms of what
Speaker 2: they do.
Speaker 1: And you talked about Jquerry. The dollar function in Jquerry
Speaker 1: literally could accept anything in what you passed in really
Speaker 1: determine what you got out. So the fact that it
Speaker 1: could infer what you got out based on on on
Speaker 1: the value of what you passed in was again pretty insane.
Speaker 2: I can't believe they pulled it off, to be honest,
Speaker 2: like it is. I mean that you've you've got an
Speaker 2: incredible team there, You've got Steve Luca, You've got Andres
Speaker 2: Hausbergs that are working on.
Speaker 1: This thing, and this is my god.
Speaker 2: You know, yeah, everyone's good. It seems like such a
Speaker 2: nice guy as well. And I'm never met him in person,
Speaker 2: but I would love to.
Speaker 1: I'll do a quick aside. You know that. You know,
Speaker 1: people know him from typescript and from C sharp, but
Speaker 1: for me, he'll be forever the person associated with Tubo Pascal.
Speaker 1: I really, you know, you know what Tubo Pascal was
Speaker 1: or is.
Speaker 2: I don't think I do. I mean, I know the words,
Speaker 2: but I don't know the.
Speaker 1: So so so. Pascal is a programming language that originated
Speaker 1: back in the I don't remember if it's the seventies
Speaker 1: or the eighties, created as a strongly typed language intended
Speaker 1: for teaching computer science in the universities, quickly open sourced,
Speaker 1: which made it fairly popular. And what happened, so we
Speaker 1: are everybody working on on PCs back in the in
Speaker 1: the day and back in the eighties or early nineties
Speaker 1: was basically working in Basic, which was a terrible programming
Speaker 1: language in a lot of ways. And then Anders as
Speaker 1: this young man, released Tubo Pascal, which basically was an
Speaker 1: implementation of Pascal and an ID, so it was both
Speaker 1: the programming language, the compiler, and an integrated ID, which
Speaker 1: was miles ahead of anything else available at the time,
Speaker 1: ran on really low endpcs with blazingly fast compilation. So
Speaker 1: all of a sudden we went. I went from writing
Speaker 1: slow code in Basic to writing super fast code in
Speaker 1: Tubo Pascal in Pascal, and it literally blew my mind,
Speaker 1: rocked my world, and made me into the developer that
Speaker 1: I am today in a lot of ways. So if
Speaker 1: I'm thinking about people that I owe my career to,
Speaker 1: Andrews is high on that list.
Speaker 2: Wow, I guess me too, man, I'm me too. I
Speaker 2: mean he didn't invent Touchkik like a lot of people think,
Speaker 2: but his influence and his guy didn't say very I
Speaker 2: mean he's still involved today, is still making pians today.
Speaker 1: He's an incredible guy anyway, So I have a few
Speaker 1: more questions. So we talked about the things that we
Speaker 1: like or did like, or you like or don't like
Speaker 1: about typescript. By the way, we are starting to run
Speaker 1: a long I don't know how much time you have.
Speaker 1: I would love to have as much time with you
Speaker 1: as I possibly can, but don't hesitate to let me
Speaker 1: know that you need to stop or whatever.
Speaker 2: I've probably got a hard stop at half past so
Speaker 2: in eighteen minutes, sadly.
Speaker 1: Okay, So maybe we'll you know, just need to schedule
Speaker 1: a follow on, so I'll try to get one or
Speaker 1: maybe two more questions into there. The next question that
Speaker 1: I have is, again, given the new versions of Typescript
Speaker 1: coming out, what recent or upcoming addition to Typescript has
Speaker 1: you the most excited.
Speaker 2: Yeah. So the thing that really got me excited was
Speaker 2: five point five, and I want to get this right.
Speaker 2: This was five point five Typescript which built or added
Speaker 2: something that I just did not think they'd ever add,
Speaker 2: which was inferred type predicates. This is something I sort
Speaker 2: of touched on earlier, which is when you have a
Speaker 2: function that you can check whether it's a string or
Speaker 2: not a thing that's passed in before. To get this
Speaker 2: to work in Typescript, you would need to add this
Speaker 2: kind of slightly janky looking input is string return type,
Speaker 2: which checked whether the basically sort of duplicated the runtime
Speaker 2: logic in the type level. And now you can just
Speaker 2: delete that and Typescript will infer it automatically. This makes
Speaker 2: many things a lot easier. For instance, if you need
Speaker 2: to filter, if you have an array of things that
Speaker 2: might be string or null, then you can actually filter
Speaker 2: those with array dot filter, and then you can write
Speaker 2: a little inside that. Top filter basically just says a
Speaker 2: type of string, a type of input equals string, and
Speaker 2: before again you need to do this junky little thing,
Speaker 2: but now you can just delete that and it infers
Speaker 2: it automatically. So it's just something that has a huge
Speaker 2: downstream effect.
Speaker 1: So basically all the arra utility functions or iteration utility
Speaker 1: functions now emit the proper type definition. I think I
Speaker 1: saw this as well, and it also kind of blew
Speaker 1: my mind. And it will be especially especially interesting to
Speaker 1: see if it is able to work with iterator helpers.
Speaker 1: If they get that to work, that will be like
Speaker 1: really insane.
Speaker 2: Yeah, that's very cool.
Speaker 1: Yeah.
Speaker 2: This was made by Dan Vanderkam, who's another timescript author.
Speaker 2: I think he went on like a coding retreats for
Speaker 2: a couple of weeks and just built a feature, his
Speaker 2: first ever PR timescript and they accepted it and it's
Speaker 2: now an incredible, incredible feature.
Speaker 1: Which again I don't I don't think will have enough
Speaker 1: time to talk about it. But again, one of the
Speaker 1: things that I especially learned to love about typescript is
Speaker 1: null safety. Yeah, people don't appreciate it that whether or
Speaker 1: not something is noullable is part of the type and
Speaker 1: if you pass a non noble argument in then you
Speaker 1: don't need to worry about it being null. So the
Speaker 1: if you're doing it correctly, all the null errors that
Speaker 1: what's known as that you know, that famous one billion
Speaker 1: dollar mistake, even though it's probably way more than one
Speaker 1: billion dollars by now, all those null references. If you
Speaker 1: do typescript correctly, it's it just solves that.
Speaker 2: And the fact that it discriminates between null and undefined
Speaker 2: as well, which is that that's like a strictness setting,
Speaker 2: So you can basically sort of turn that I always
Speaker 2: recommend you turn on. And that's part of strict true,
Speaker 2: which is timescript sort of basic strictness level. The fact
Speaker 2: that it discriminates between those two as well is just
Speaker 2: you can feel extra strict sometimes, but it just saves
Speaker 2: you an extra level of pain.
Speaker 1: Yeah, I do wish, you know, if I could have
Speaker 1: gone back in time to nineteen eighty five and whisper
Speaker 1: on Brendan Ike's ear I would have said, maybe not both,
Speaker 1: maybe just one or the other.
Speaker 2: I strongly agree, and maybe just fix the thing where
Speaker 2: type of nell is an object as well.
Speaker 1: That's blood. You know, that's a funny one that one
Speaker 1: actually slightly bothers me less interestingly enough. I get why
Speaker 1: that is. Let's put it this way. But again I think,
Speaker 1: you know, that's a different discussion. And there is one
Speaker 1: more thing that I would like to touch on before
Speaker 1: we finish, and it kind of goes to the fact that,
Speaker 1: as you mentioned, whenever converting a project, there's likely a
Speaker 1: UTILS folder, And on the one hand, you want to
Speaker 1: start there because probably everything is dependent on you tills,
Speaker 1: but utils is probably not dependent on anything, or at
Speaker 1: least or not on anything internal and the question. But
Speaker 1: on the other hand, it's the one that's most likely
Speaker 1: to need advanced Typescript features like generics and stuff like that,
Speaker 1: so you're probably also starting with the hardest part. And
Speaker 1: my question here is so generics, like, does every Typescript
Speaker 1: developer need to understand generics or is this something that
Speaker 1: we can be relegated to a few like quote unquote
Speaker 1: Typescript wizards. And in this context, I think it was
Speaker 1: THEO if I'm mistaken, then I apologized. Who once in
Speaker 1: a video kind of made a distinction between the typescript
Speaker 1: at the app level versus typescript at the library level
Speaker 1: that when you're working at like the userland slash application level,
Speaker 1: you can be you don't need all the fancy schmancy
Speaker 1: Java typeescript features. It's basically mostly simple or very explicit types.
Speaker 1: But when you work at the library level, then you
Speaker 1: probably need to get into various APIs and sorry, you
Speaker 1: need to deal with sophisticated APIs, and then you need
Speaker 1: stuff like generics, and we talked about covariant and contravariant
Speaker 1: and stuff like that. So do you agree with this distinction?
Speaker 1: Do you think it should exist or should Does every
Speaker 1: typescript developer need to know generics one? You know, sooner
Speaker 1: or later.
Speaker 2: Let me break this down in a couple of places.
Speaker 2: The first place I'll break it down is that generics
Speaker 2: as a concept. I think there's kind of three or
Speaker 2: two things in there, which is that there's generics as
Speaker 2: a consumer, which is basically the person consuming the functions,
Speaker 2: calling the functions. You need to know, for instance, how
Speaker 2: to pass a type to another type which is generics,
Speaker 2: you know, So if you have an ACYNC function, you
Speaker 2: need to understand how the promise type helper works, which
Speaker 2: is of course a generic type. But then the thing
Speaker 2: that I suppose we're really talking about is generic functions,
Speaker 2: declaring your own generic functions. Designing APIs. If you're in
Speaker 2: the business of designing an API, and I mean like
Speaker 2: an API for a function that other people are going
Speaker 2: to call, then you will probably need some generics at
Speaker 2: that point. And that's when we start to get this
Speaker 2: sort of spectrum coming in of we've got the app
Speaker 2: developers on one side, who are mostly just consuming generic functions,
Speaker 2: and then we've got the library developers on the other side,
Speaker 2: who are creating the generic functions, you know. And this
Speaker 2: sort of is a nice feature of typescripts, I think,
Speaker 2: because it means that a lot of complexity can just
Speaker 2: be held inside those generic functions and then just used
Speaker 2: in a very simple way with very few type pannotations
Speaker 2: by the app developers. I would say, I think of
Speaker 2: there as being three places, three sites of three levels
Speaker 2: of tacticrit wizardry. Let's say where you have the app
Speaker 2: developers on one side, you do have the library developers
Speaker 2: on the other side, who had to deal with all
Speaker 2: sorts of stuff like infer and conditional types and typescript performance,
Speaker 2: you know, like which is the performance of your types?
Speaker 2: You know, how fast does your idea update and things
Speaker 2: like that. And then I'd say that the utils folder
Speaker 2: is like a level in between where you don't necessarily
Speaker 2: need and this is not my idea is to actually
Speaker 2: orto the Rocks's idea. Who's a great typescript term was
Speaker 2: on the touch script team, great typical contributor, and the
Speaker 2: utils folder. I think you can get by with just
Speaker 2: a bit of types of knowledge, especially now you have
Speaker 2: things like gubt with Claude that can help you out
Speaker 2: a little bit with these. If you can declare a
Speaker 2: generic function, declare a generic type, I think that is
Speaker 2: going to really help you just in terms of your
Speaker 2: app developments, because it's going to mean that you can
Speaker 2: design your types a lot better. You can make types
Speaker 2: that sort of flow in beautiful ways, you can make
Speaker 2: generic fund make functions that do what you want them
Speaker 2: to on the type level as well as the runtime level,
Speaker 2: and so you don't if you're starting and it's like
Speaker 2: your first month doing type scripts don't dive into generics immediately.
Speaker 2: You know, there's no need, you can just consume generics.
Speaker 2: Just do that. But I think that as your apps grow,
Speaker 2: as more code gets shared, more code goes into the
Speaker 2: details folder knowing this stuff is going to just benefit
Speaker 2: you enormously.
Speaker 1: Yeah, I think that's the key point. I think it's
Speaker 1: totally fine to start before your quote unquote and expert.
Speaker 1: If we all waited to become expert before we actually
Speaker 1: started doing something, that we will never stop. Like the
Speaker 1: worst enemy of good is better, you know, fake it
Speaker 1: till you make it, and whatever is actually is actually
Speaker 1: a legitimate approach in this context that said, don't stop.
Speaker 1: If typescript is a core part of your development process,
Speaker 1: then I think that you owe it to yourself, to
Speaker 1: your career, to your team, to your product to become
Speaker 1: as proficient as possible in it. And I think that
Speaker 1: it's definitely worthwhile to put in the effort to go
Speaker 1: to websites like yours, to read the newsletters that you
Speaker 1: put out, to try things out, to make sure that
Speaker 1: you do understand you know, how things actually work, and
Speaker 1: stuff like that. So as long as you you know,
Speaker 1: say okay, I am going to put in the effort
Speaker 1: to fill in the blanks. I think it's a legitimate approach.
Speaker 2: Yeah, and learning this stuff as well, learning the mental
Speaker 2: models behind it. They just benefit you so much when
Speaker 2: you're building stuff because you just you don't get stuck
Speaker 2: so often. You know, you can just work your way
Speaker 2: through errors. You can understand what's going on.
Speaker 1: Now, if you've got another minute or two, I want
Speaker 1: to pick up one question that we got in in
Speaker 1: the in one of the chats. Let's see if I
Speaker 1: if I properly understand it or if you do. It's
Speaker 1: from either Poe or Poan. I hope I'm pronouncing it correctly,
Speaker 1: and he asks, how can we automatically convert typescript to
Speaker 1: runtime assertions? What are the options and the tool sets?
Speaker 2: Yeah, so one key part of typescript understanding is that
Speaker 2: it just doesn't operate at runtime at all, like.
Speaker 1: It's just gone.
Speaker 2: It's gone. It's just you know, like they're they're just
Speaker 2: cleaned out those types and so there can iterate.
Speaker 1: You can't iterate over like a lot of people like say,
Speaker 1: I hate the fact that you kind of define certain
Speaker 1: things like twice part once as values ones in types
Speaker 1: and one can can iterate over the type you can
Speaker 1: because it's not part of the run time, not part
Speaker 1: of the runtime.
Speaker 2: They just don't exist at runtime. And so this I
Speaker 2: think this question is sort of asking how do I
Speaker 2: make a type and sort of pull it into the runtime.
Speaker 2: And you probably could with some kind of cogen library,
Speaker 2: you know, an AI could probably m could probably do
Speaker 2: it for you. But yeah, I mean, there's there's no
Speaker 2: I think people who ask this question are asking the
Speaker 2: wrong thing, which is, instead of taking a type and
Speaker 2: putting it into the runtime, you should be thinking how
Speaker 2: do I take the runtime and turn it into a type.
Speaker 2: Because there's a really nice operator called the type of
Speaker 2: operator in typescripts, which it's same as the JavaScript operator
Speaker 2: but sort of operates slightly differently, which just lets you basically,
Speaker 2: if you're using something like zod which is a runtime
Speaker 2: validator runtime schema library, then you can take that and
Speaker 2: you can say type of z dot's schema and it
Speaker 2: just gives you a type of.
Speaker 1: The simple example. The simple example is the key is keys.
Speaker 1: Is the fact that you can use specify like an
Speaker 1: object with various keys infer a type from that. So
Speaker 1: now you've got the actual object which you can use
Speaker 1: at run time, but you've also inferred the type that
Speaker 1: you can use at you know, build slash programming type.
Speaker 2: Yeah, totally. A really good example is let's say you
Speaker 2: have an object of APIs that you want to hit
Speaker 2: with different sort of environments attached to them. So you
Speaker 2: have your your QA environment, your development environment, and your
Speaker 2: production environment. You have that on an object. You can
Speaker 2: pull those keys off and suddenly you have a union
Speaker 2: of those three keys. So I call this derived types,
Speaker 2: where you basically derive some sort of type from the
Speaker 2: type of thing. And this could be really powerful because
Speaker 2: it means that you don't need to maintain the type
Speaker 2: in two places. You just add an the key you
Speaker 2: had a staging environment, and then that suddenly appears in
Speaker 2: the type. It's really really powerful stuff.
Speaker 1: So before we've really run out of time, if people
Speaker 1: want to get in touch with you to you know,
Speaker 1: get on your news letter, your website, your book, whatever,
Speaker 1: what's the best way to find you? How how how
Speaker 1: do we you know, find all your stuff? Excellent stuff
Speaker 1: that you're putting out.
Speaker 2: Thank you. So this is total touch. Script dot com
Speaker 2: is basically the site where I put pretty much everything. Now,
Speaker 2: so there is a newsletter.
Speaker 1: There.
Speaker 2: There is my free book on there, which I mean
Speaker 2: it's a free book. It sounds like it's just a
Speaker 2: cheap giveaway. It took me nine months to write this thing,
Speaker 2: you know what I mean. Like, and it's being released
Speaker 2: as as an actual paper book as well. And I've
Speaker 2: got a course up there, and there are tons of
Speaker 2: free tutorials and sixty articles I've written up there. It's
Speaker 2: a it's a really solid resource.
Speaker 1: And in terms of paid stuff that you put out,
Speaker 1: what do you what is there? What's there? What's Yeah?
Speaker 2: So I've got I've got two courses, or two levels
Speaker 2: of courses, one which is pro Essentials, which is I
Speaker 2: mean it's about two hundred two hundred and forty exercises
Speaker 2: I think where basically it takes you from total beginner
Speaker 2: in tap script to sort of like the bottom end
Speaker 2: of Wizard, I'd say, So we cover generics, and there
Speaker 2: we cover all sorts of stuff related to typescript, and
Speaker 2: then the other stuff, which is the complete volume is
Speaker 2: I've got a series of really advanced workshops which I
Speaker 2: taught live, which are basically sort of I turned into
Speaker 2: a self paced course as well. So the whole thing,
Speaker 2: I think it's about five hundred exercises or so, like
Speaker 2: it's an enormous, great, big thing, But I love the exercises.
Speaker 2: You can just sort of dive into them in an
Speaker 2: your lunch break. Basically it should take about sort of
Speaker 2: five or ten minutes to solve each and there we've
Speaker 2: gotten feedback that it's just like a really addictive process.
Speaker 2: You can just go bam bam bam bamm solving all
Speaker 2: the exercises and it's great fun.
Speaker 1: And the very last thing before we let you go,
Speaker 1: is there anything interesting that you're working on now, something
Speaker 1: that we can look forward to.
Speaker 2: Well, I'm diving into the world of AI, I think,
Speaker 2: and I'm starting to find that I'm someone who's kind
Speaker 2: of allergic to hype. Really, I just hate the whole
Speaker 2: hype cycle for things like crypto, and I just want
Speaker 2: to get to the interesting stuff and the meat that's
Speaker 2: gonna kind of make me more money or make companies
Speaker 2: more productive, or like somewhere I can provide value, you
Speaker 2: know what I mean. I don't want to speculate on
Speaker 2: crypto rubbish. And AI has got a lot of hype
Speaker 2: around it, but it's also very, very real and based
Speaker 2: on a lot of good science, and yeah, I'm finding
Speaker 2: it very very interesting and potentially thinking about making something
Speaker 2: from it.
Speaker 1: Oh so very cool. So you know, people are used
Speaker 1: to us also having a pick section, but I think
Speaker 1: we've kind of ran out of time. I would love
Speaker 1: to have you on again. There are so many questions
Speaker 1: on my list that we didn't get around to, and
Speaker 1: we didn't about AI at all, So hopefully I can
Speaker 1: get you on again. In any event, it's been excellent.
Speaker 1: I've learned a lot. It's been such a joy speaking
Speaker 1: with you. I hope our listeners have learned as well.
Speaker 1: So thank you for coming on our show, and to
Speaker 1: all our listeners, you know, thank you for listening to us.
Speaker 1: And again reminder if you're thinking about filling in the
Speaker 1: job as the JAS survey mention us you know given
Speaker 1: excellent content like this one. And thank you all and goodbye.