TypeScript, TS ESLint & the Learning TypeScript Book with Josh Goldberg, Open Source Developer

Josh Goldberg joins Nick Taylor to discuss TypeScript, TypeScript ESLint, open source, and Josh’s new book, Learning TypeScript.

Links:
- Stream on YouTube, https://youtu.be/qFN8PC8Knic
- Website, https://www.joshuakgoldberg.com
- Twitter, https://twitter.com/JoshuaKGoldberg
- Twitch, https://twitch.tv/JoshuaKGoldberg
- YouTube channel, https://www.youtube.com/channel/UC1ag6LufUK30vkwS9lWHA8Q
- GitHub sponsors page, https://github.com/sponsors/JoshuaKGoldberg
- Learning TypeScript book, https://www.learningtypescript.com
- Tour de Source: TypeScript ESLint, https://sourcegraph.com/notebooks/Tm90ZWJvb2s6MTA2OA==
- TypeScript ESLint - Abstract Syntax Trees (ASTs), https://typescript-eslint.io/docs/development/architecture/asts

Transcript

Nick Taylor: 0:00

So Josh is joining me today. Josh has been doing a lot of stuff. We're gonna, we're gonna talk about all kinds of stuff. We're gonna talk a bit about open source TypeScript, TypeScript. Es Lin and Josh also has a book that came out, I can't remember when it came out, Josh, but it's, Learning TypeScript. I'm gonna drop a link to it. You should be able to sit there in the chat. Yeah. When did the book come out? I can't remember.

Josh Goldberg: 0:25

I forget. Let's, I wanna say end of July, Middle of July.

Nick Taylor: 0:29

We'll get to the book in a bit, but I kind of wanted to, touch on TypeScript, to begin with, and I know you've been doing TypeScript for a while. Myself, I got exposed to . It makes it sound like I got a disease. Sorry. The first time I started messing around with TypeScript was I think fall 2015. I used to work in the .NET ecosystem, so I was at a Microsoft shop and the CEO at the time was like, we're gonna use TypeScript for this new, We were working on a e-commerce starter site. I got exposed to it early and, I found my ramp up to TypeScript wasn't too bad because I came from C#. Uh, and for, for folks that might be new to TypeScript, Typescript's created by the same language creator as C#, Anders Hejlsberg. So there's a lot of inspiration in TypeScript from C#. Um, but I, was kind of curious to hear about like your beginnings with TypeScript, kind of, you know, what you've been doing with it. And I, I will, that'll kind of tie us into maybe, TypeScript ESLint in a bit too.

Josh Goldberg: 1:32

I had a similar exposure, actually I was also in a .NET shop in that I was at Microsoft interning, uh, summer 2014 and then started 2015. So I was also doing full stack .NET and I just liked it, you know, It was better. I don't remember. I, I think there were like a bunch of people yelling at me to try it out cuz it had already been open sourced for two, three years at that time. But it's just a better way of organizing and structuring your JavaScript. Like at the time, I think it's fascinating. At the time TypeScript for the first few years was being advertised as better organized, structured JavaScript. Now that JavaScript has advanced a lot and has a lot more features, that the emphasis has shifted to just be JavaScript with better type checking, which is different. They've stopped advertising classes cuz people now realize that yeah, it's not the best thing to use all the time.

Nick Taylor: 2:22

Yeah, I think, I think they still have some in the handbook, like if you go to the examples, but, But yeah, I agree. Cause like coming the, the way I saw it initially, like one thing that was great about it when, like I was working on that starter site was we had a bunch of back end devs who were able to actually, you know, they didn't know front end, but they could actually write business logic and stuff in TypeScript, you know, because it was very familiar. So, But you are right. It has moved. I really feel like it, it is definitely a type checker, but also like, just, you know, guides you like, I always kind of crack up when, when people say they don't like TypeScript, but they're fans of VS code because I always hate to break it to them, but like, you know, when you're doing that, rename that variable or move something that, that's all TypeScript under the hood. So that always makes me chuckle a little bit, but that, that's where I've seen a lot of the power. From it, you know, Also the discoverability, cuz like it's, I mean you did.net as well, so you're familiar with Visual Studio Code and, and like anybody else that's done any kind of type language with some editor like maybe IntelliJ or something, stuff like Intel Sense and refactoring tools have been around for a long time. It's just, I think in the front end space it was, it was really search and replace for the longest time until something like this came along.. Josh Goldberg: Yeah. We've infected everyone, as you said. Yeah. Exactly. Exactly. But, it's also interesting, like you said, it has changed over the course of time. I mean, for the better I think. But like, there's a lot of things you couldn't do when type screw came out cuz like, obviously it takes time to, to get to where they are today. But like, like for example, like the infer keyword didn't exist like in the beginning. It type like types it as well, Like this kind of ties into open source, but like, I think people kind of take the types for granted nowadays because they just expect them to be there. But in the early days there's a project called, uh, DefinitelyTyped on, on GitHub and, I'm sure you've contributed to there. I, I haven't, I think I might have had one contribution, I can't remember. But, you know, it was pretty amazing to see the community just start saying like, Hey, I don't have types for this. I'm gonna go create some. And, and that's like evolved over time and it's still widely used, but I mean, a lot more projects that go to TypeScript now, you don't need to do that because obviously the types come with it. I still find it pretty amazing that that project gains so much steam. It's obviously directly related to the popularity of TypeScript, but, I'm still impressed cuz that that's not even a, as far as I know, it wasn't a Microsoft initiative. I think it was just somebody from the community. I, but yeah.

Josh Goldberg: 5:05

Yeah, actually I just, I couldn't, couldn't remember the name of the post till now. But yeah, there's a great history of DefinitelyTyped. That post that I'm gonna post in the chat from John Riley.

Nick Taylor: 5:16

Uh, Okay. Yeah.

Josh Goldberg: 5:17

Which, he's one of the, the folks who was involved in it. It's like one of the, the biggest, if not the biggest repo in terms of activity on GitHub. It's got all the type definitions for every third party typing, like all the packages that don't have their own TypeScript. It's all there. It's huge. Like it, The amount of automation they have set up honestly inspires me. Like every poll request gets like automatically assigned reviewers in a bot that posts your status checks and lets you know if there's stuff you have to do. It's, it's wonderful. Yeah. Really, really cool people.

Nick Taylor: 5:49

Yeah, I'm just opening it up here in the, so folks can see it on screen. They can definitely check it out. I've never seen this before, so I'm, I'm definitely gonna give this a read. And like Josh said, he, he also dropped a link to John Riley's tweet there, But if, if you're not following John Riley and you're, you're a fan of TypeScript or, or just dev in general, definitely give him a follow as well. But yeah, this project, like it completely exploded and. I don't know. It, it's, I don't know. I, I still find it pretty mind boggling, honestly, that it, it gains so much traction. Yeah. And this, this ties into some other open source initiatives. So people are familiar. I think a lot of the people in the chatter are front end devs, but most people are familiar with ESLint and I can't remember when it came out, but there was a project that preceded, TypeScript ESLint called TSLint. I'm gonna try and load that up here, but, okay. Was it from Palantir? I can't remember who initiated. So I guess it's from Palantir, but this was kind of the way when you were working with a TypeScript project, like if you wanted linting and. I think this is a kind of good segue to talk about TypeScript ESLint because there, there came a point, I can't remember when it was, 2018 or 2019, but it was just kind of like, there was people like yourself. Uh, his name's escaping me. Henry, what's his, his last name's Henry?

Josh Goldberg: 7:10

James Henry.

Nick Taylor: 7:11

James Henry. Thank you. Yeah. I don't know if he's at Narwhaal anymore, but he was, working on TSLint as well, and then it, it kind of, Yeah. Okay. It says 2019. I'm, I should just read it right in front, front of me . So basically, yeah, in, 2019, I think, what happened was, like ESLint was obviously widely adopted and, a bunch of you said, Hey, I, it's probably a good idea if we just kind of, let's, use the existing project and see what we can do. Or, or do you kind of wanna maybe speak to that?. Josh Goldberg: Sure. Yeah. That is one big aspect of why we switched, so yeah. Okay. Back in, back in the day, there were two linters. There was ESLint and TSLint. ESLint for JavaScript, TSLint for TypeScript. That simplicity of description is really nice. But it meant that every time a feature would land or a community rule set, like the React rules of hooks were published for ESLint, we would then have to implement it in TSLint. I was active with the project eventually became a maintainer. That's a pain in the butt, and at the time pipe Skip was even smaller of a subset of the JavaScript community than it is now. So TSLint just wasn't as good. It didn't have as many features, but it did have access to the TypeScript type checker, which is awesome. That makes for really powerful link rules. Also, as you said, Palantir is the corporate sponsor of TSLint, which means a lot of people didn't wanna use it cuz Palantir has a lot of politically not so great associations and things that they've done. Yeah, yeah.

Josh Goldberg: 8:35

I did not work for them, but I do remember getting directly called a fascist on GitHub issues once. So that was, that was great.

Nick Taylor: 8:41

That, that's interesting. Okay.

Josh Goldberg: 8:44

Yeah. For the record. Not a fascist, but, eventually, eventually, the, the TSLint folks prior to me that the people who actually knew what was going on worked with TypeScript and ESLint folks, and, made this new tooling TypeScript, ESLint, which I, again, did not create, but I'm now a maintainer on, that

Nick Taylor: 9:03

yeah,

Josh Goldberg: 9:03

let's you use Esly with support for TypeScript rather than a whole separate other package.

Nick Taylor: 9:09

Yeah, no. And

Josh Goldberg: 9:10

typescript-eslint.io.

Nick Taylor: 9:13

Yeah, I was, I was gonna say, this was so great when this happened. I, I remember it was a little rocky at the beginning cuz, you know, obviously it took a bit of time to to, to get it working completely, but, from what I remember at least, but once, once it was in ESLint, I was like, Oh, this is so much better. Because like you were saying, just having to maintain the two things. I had some stuff that was JavaScript as well in a project, but TSLint you know, and like just extra stuff. So it was, honestly, it was so nice when this got merged. Hat tip to you and everybody that's been contributing.

Josh Goldberg: 9:43

Thank you. I think there's a really interesting parallel with the ESM, the Equis script modules, migration and change in Node and JavaScript as a whole. That there was a lot of pain in the ecosystem now from people needing to switch from common JS to Node modules.

Nick Taylor: 9:59

Mm-hmm.

Josh Goldberg: 10:00

Just as there was a lot of pain switching from TSLint to TypeScript ESLint, for example, TypeScript ESLint still has performance issues as was mentioned in the chat. Thank you.

Nick Taylor: 10:08

Yeah.

Josh Goldberg: 10:08

That builds that need type information. Like the full power of TypeScript are slower and we just aren't architecturally having a hard time. Yeah., but getting everyone over to Ts or over to Lin from TSN was necessary. We had to deprecate the thing. So we're this transitory period now where a lot of people are still switching over Fun Fact, Definitelytyped is still using TSLint. I I'm working.

Nick Taylor: 10:31

Oh, okay. I didn't know that. I'll drop that in the chat too.

Josh Goldberg: 10:34

They got some custom rules that were just hard to migrate. But once everyone's over and once we fix those issues, it, it's so much better to be on the same tooling. Same with ESM. I'm so excited for everyone to support it. It's gonna be so good.

Nick Taylor: 10:47

Yeah, I know. There's definitely a big push to support ESM. I know, like, I always say his name incorrectly, but, Sindre Sorhus or, sorsh I, I can't remember how his last name's spelled, but he's prolific, um, maintainer and contributor to the ecosystem and he wrote a blog post, I think it was last year, saying as of like, new versions of anything he's doing, it's ESM only, you know, and this kind of driving, you know, it causes some pain points cuz like you said, you, you run into it. We need some stuff to drive that because there's still, I mean, one thing that TypeScript does well is, you know, it has the compatibility to, so that you can have both still and not, you know, have less problems. But yeah, I'm, I, definitely prefer, I mean, I don't know, I, I just seem to prefer like the imports in tax versus the require anyways. I mean, Just, I, I dunno, the aesthetic of it has kind of enamored me, which is not a good reason to say we should use it, but I, I, I'm just so used cause I,

Josh Goldberg: 11:50

No, the aesthetics are important. It, that is a, it's maybe not the most important reason, but it is a good, important and valid reason that it's just better aesthetics. It, it stays at the top. It's orderly, it's organized, it's a formal way of doing things That formalization is, is good. A lot of us language nerds call it developer ergonomics, which is a fancy way of saying it looks nice, Heck yes.

Nick Taylor: 12:10

Yeah. Yeah, no, that, and I mean, you know, also you end up with the dynamic import and stuff and, and there's, there's just been a, Yeah, just a lot of things going on in the ecosystem. Cause like, there's the TypeScript checker, compiling to TypeScript, there was Babel that used to, well, it still does it, but just strips the types and gives you the JS. And then you have tools like ES build wi or like Vite you know, that's doing similar things to, I, I'm not sure what esbuild uses under the hood. Is it swc? I can't remember.

Josh Goldberg: 12:43

It's its own thing. It competes with that.

Nick Taylor: 12:45

Oh, it is. Okay.

Josh Goldberg: 12:47

They're different languages. One is the formers. Go, swc is, Rust I wanna say.

Nick Taylor: 12:52

Yeah, awesome. No, that's right. Yeah.

Josh Goldberg: 12:53

Big fan of both.

Nick Taylor: 12:53

Yeah. There, there's so many ways to do things, but I've also noticed, there's been in TypeScript itself, the, there's been a lot of speed improvements, from what I've seen, cuz like, I don't know about others, but I, I always had to use ts-fork when I was using, Webpack before to just kind of spin off, you know, checking in another, Stuff. And, and even with that, it was still, I don't know, problematic sometimes, but I guess it really depends too. When do you wanna do your type checking? Cuz like if you're in the editor, you know, if you have all the tools enabled, like VS code will tell you what's wrong. You don't necessarily need the watch going all the time. Like, that's how I used to work. I'm curious kind of how you work when you're in a TypeScript project.

Josh Goldberg: 13:36

Such a great question. I agree. I do not like fork TS checker or ts loader or any of those things. ts-loader especially, I'm a big fan of how it's implemented. It's a great package if you should, if you're in a system like that, needs that type of thing, great. But my personal preferred way of running TypeScript in a, like a Webpack e or v e project, is to just use what you described earlier, a Babel or swc or ees filled, stripping out all the types. As you said, if your editor already giving you in Intellisense with their little red squigglies, there's no need for your webpack to spend a bajillion seconds cycle to build things. Just remove type checking from your webpack builds altogether and then have some CI jobs. So like if you send a pull request block on failing TypeScript builds, same with ESLint. I don't think ESLint should ever be integrated with Webpack. Run that separately and then have an editor extension that gives you ESLint complaints. There are bajillion. Utilities you could run either in webpac or outside, but like as a developer trying to get something working locally, it should be as fast and painless as possible to get, get some crap on the screen and like, there's no need to block your scripts. So I block your webpac builds from running on your TypeScript errors. That's so annoying. I remember I set up a project once and didn't re disable that and someone new to the ecosystem very correctly called it like the world's most annoying winter yelling at you every time you have anything.

Nick Taylor: 15:00

I always used to think, Oh, yeah, it makes so much sense that I'm watch, I'm, I have the watch of these things going on, and then it's, yeah. Now, now it's just like wasted cycles, you know? Typically what I do in a project is like some people don't like pre-commit hooks. I like pre-commit hooks, but I'll, I'll run stuff there with like lint-staged and Husky, but people can bypass that, you know, with like the no verify on in git so typically, Like when I worked at dev.to, we had a ton of linting errors. It wasn't a TypeScript project, but basically just had a year long of like let just keep squashing the lint errors. And then when it got to zero lint errors, that's when I added a CI check to run the lint and it, you know, just cuz like at the time I was the only front end. So it's like, for me it was like maintenance nightmare if they kept creeping back in. And that's, that's kind of what we do. Like, we have some TypeScript projects at Netlify. So we have the lint that goes in on CI as well as, pre-commit hooks and stuff. And yeah, I find that flow a lot better. I haven't used like the watch for TypeScript or like, I haven't used a project with Webpack in a while. Typically go with what's in the editor these days. I know not everybody's using Visual Studio Code, but you know, I guess the only thing is like, I don't use Vim, but I know that there's a TypeScript plugin for Vim, so I imagine you can still get all that same kind of goodness as well in there. But I, I don't use Vim, so I can't really say for sure.

Josh Goldberg: 16:23

No, you're right. That's one of the nice things about working in a, like a mainstream popular language. Like there are a lot of people who insist that you should use Reason slash Rescript or Elm or whatever, which may be legitimately great languages. TypeScript is everywhere. Like every single popular, and even most of the unpopular editors slash IDEs have a really good TypeScript plugin. Vim, emacs, everyone. Yeah.

Nick Taylor: 16:48

Mm-hmm.

Josh Goldberg: 16:49

It's nice.

Nick Taylor: 16:50

Yeah. No, exactly. We'll get to the book shortly, but like you've been working in open source for a while. I found it really interesting that you went from, what I can only assume was a great job. You were at a ed tech company, right? It was, Was that it? The name's escaping me.

Josh Goldberg: 17:06

Yeah. Code Academy. It was a great job. Highly recommend Code Academy as a, as a product and a place. Lovely people there.

Nick Taylor: 17:13

So you were having fun there. You were enjoying it. You were still contributing an open source, but, I'm curious. What the decision to go full or why did you decide to go kind of all in on working full time on open source? Because I'm sure there's a ton of people curious about this.

Josh Goldberg: 17:28

A lot of people who themselves are thinking about it, but it's a scary jump. It took me a while to get there. I'd say working at a company is a good thing for most people. You want to have that support of people around you, a team, a manager, a mentor, mentors, plural. If you can. But I really like open source software. I like doing things that benefit everyone. Like when I work on TypeScripts or TypeScript BS links, I benefit everyone who uses those tools. Like if I spend. 10 hours, let's say, on some bug fixes and a feature in TypeScript. I have just saved the world's un unknowable, but large amounts of time, like I've sped up the rate of human development. Like, that's cool. I say these things which make myself sound so much cooler than I really am, but it makes me feel good. And when you're at a, when you're a company, even if you have a lot of thank you, even if you had a lot of time in your day to day to work on open source, it's still for the company. Why would they hire you to do things that don't benefit them? Yeah. So you don't have as much time or control over your open source stuff. And I just, I just want to do this all the time. So I'm now one of those people very, small but hopefully growing group of people who work on open source full-time. And instead of a job with health insurance and 401K and all this, I ask for money on the internet. So this is my first shameless plug of the stream. You told me I could. So I will.

Nick Taylor: 18:52

Yeah. Shamelessly plug. Yeah, I dropped your GitHub there, so folks can check that out.

Josh Goldberg: 18:59

Thank you. Yeah, the more money people give me, the more I'm able to work on open source that makes your life better. So thanks. But this exposes something real bad, which is that as an industry, we, we don't know how to make people like me work. Like the, the situation I described of, I work in open source tooling that benefits everyone, and somehow I get money. Like that's not figured out yet. We have ad hoc things like get hub sponsors Open Collective before that Patreon. But like there's no strong incentive for most companies to give to open source other than developers are yelling at finance that someone should do it. And it's like vaguely good for marketing and recruiting. So I wish we had like, like a, like a B Corp style, like you should do this, or we all feel bad about you and don't join. But that's not really standard.

Nick Taylor: 19:43

Yeah, it's definitely interesting cuz like I'm working at Open Source at Netlify right now. I worked, when I was at dev.to, I was working at open Source and that was my job, so getting paid at like that, those are, that's, it's a really compelling reason why I. Took those jobs too. I'm a big fan of open source and like, you know, just like you said, being able to get paid to work in open source is amazing. So like I happen to find places that did it, but it, there's. You know, then there's, there's kind of like three scenarios. You know, There's like somebody like me who might be working at a place that does open source. There's people that do it in their free time, and then there's people like yourself who are looking to get sponsored, and it's, you're totally right. It's like, how do you formalize that? Because like, you know, it's weird too because like large companies, you know, like Babel for example, which has had so many hours put into it, I know Henry Zoo gets compensated now through a, I dunno if it's GitHub sponsors or Patreon, and I, I don't know if the other contributors do as well, but you know, that came out of like, I don't know if he went the same route as you or I can't remember the, the story there, but you know. It's kind of amazing that like most of the planet runs on open source like Linux, and like all these like big companies and maybe Linux people are definitely putting money into it, I guess. But like, you know, I would think, all the places that have been using, you know, like Babel, Webpack, all that stuff, why aren't people or companies, you know, putting money into that, and it's, I don't know how to, I don't have an answer or anything, but it, it is just kind of weird, like, cuz like myself, I do sponsor people, but there's only so much I can do, you know. Like, I mean, I, I need to use money for other stuff too. And it's like, it's not like I'm about to sponsor 200 people. I, I definitely see the aspect where like, you know, the micro payments could definitely, stack up for sure. Like if a thousand people started paying five bucks a month, you know, that's definitely changes the game. But, why aren't companies like monthly, you know, just donating. I find it kind of weird is all.

Josh Goldberg: 21:51

Individuals donating is like yelling at people to use either no straw or paper straws, like, yes, you are doing a good thing, but the real issue is systemically, the capitalist society we in has not adjusted to, to do public goods and services and similar like open source. That's my rent for the morning.

Nick Taylor: 22:08

It's all good. But I do appreciate all that you're doing cuz I do use, ESLint and TypeScript, all the time. Josh has a, a bit of a hard stop today, but I don't wanna miss talking about your book cuz, this ties into everything basically. Uh, you've been doing TypeScript for a while, you've been doing open source. I guess I, I'm gonna grab the book in a sec cause I do have a copy, but I guess kind of speak to, I can't even fathom writing a book, honestly. So I'm curious like what that, how, how that all came about. And I'm just gonna grab your book.

Josh Goldberg: 22:38

Sure. Thanks. It's, I also was of the opinion, Oh, I couldn't write a book like that. It's, that's some, that's some real stuff. Like I have to be, you know, 50 years old with 30 years of experience and all this, but like, I write blog posts. A lot of people write blogs. I think you might be familiar with dev.to. You mentioned like you've seen a lot of people, you yourself have a billion posts. Just keep doing that over the course of a year. You'll have like a book level amount of stuff. I had been like talking at the occasional conference and posting on Twitter a whole bunch. Some of some of my posts were even useful and thought out. So O'Reilly contacted me. They said We need a book. And this is true, I think. It introduces TypeScript for people who don't have, say,.NET or other typed language or framework support, understanding.

Nick Taylor: 23:27

Yeah.

Josh Goldberg: 23:27

Like people who've just written JavaScript, nothing else. And I think that's a really good thing. I think every language should have a good set of introductions, book video tutorials, online workshops, similar, that teach you it if you don't yet know, you know, related similar tech. So that's kind of the,

Nick Taylor: 23:44

Yeah.

Josh Goldberg: 23:44

the perspective that I, for Learning TypeScript, like what is a type system? Why do you care? How do you use it. What are all these ridiculous TypeScript errors as the first part and then we go into TypeScript support for random other features. So, yay. Thank you for, Thank you for getting the book. I appreciate it.

Nick Taylor: 24:00

I got a hard copy so, I was in Hawaii for my offsite, not bragging, it's just that's where I was, but I, I was reading it on the beach. I still feel a little cautious about bringing an iPad on a sandy beach. I think I'll probably get like a, a Kobo or something eventually. But yeah, I wanted to talk about the book because, you know, is somebody that. I've been doing TypeScript for a while, I bought it too, cuz I know whenever I read something by people who know what they're talking about, I'm still gonna learn something. Even though this is, I think technically like a beginner book, getting interested, in TypeScript. But I think a lot of your, I I've never done anything on Codecademy, but I think your ed tech background probably helped with the approach to this book. I like how it's broken down. I like how you're saying, you, you talk about the type system and like, why we need it. What is it? And you kind of go in each section of the book there's, you know, I, I think things are explained really well with examples, but then you pause every chapter and I have it open here, but like you can go through and do some code samples and stuff to just kind of solidify what you just learned there. And I just thought, that's pretty awesome. I'm not finished the book yet cuz, I did get a little busy, but I'm about two thirds of the way through. But it, I just like the way it's structured, I think one of the things I was curious about, and it's not necessarily book related, but I'm, I'm curious what you think or what you've seen that people typically struggle with TypeScript. There's the, I've never used types part for sure, but I'm wondering if there's like concepts that kind of, people are just like, ow, my brain. What's going on here? Or what you've kind of seen with people that you've, taught or, or spoken to.

Josh Goldberg: 25:43

That's a great question. As a side note, I'm realizing I should put a chapter's section on this site that just explains what's in each chapter.

Nick Taylor: 25:52

Uh oh, okay.

Josh Goldberg: 25:53

That's, that's a big thing. I think, well, and every language, generics is the worst. It was my least favorite chapter to write. It's just, I, I had to rewrite it like twice for something like this, like at least once. It's just a hard concept to, to explain and understand for a lot of people because it's explained so poorly by so many places. Like, I don't think it. As a concept. I don't think generics is actually that, I don't wanna say difficult, but like, I don't think it's like so shockingly advanced that you that like most people wouldn't be able to understand it, but it is hard to explain Well, which then makes it a difficult concept for a lot of people.

Nick Taylor: 26:30

Yeah,

Josh Goldberg: 26:31

it just, the terminology is hard. Like, did you know there's a difference between parameters and arguments? Like this is something I learned writing TypeScript content.

Nick Taylor: 26:38

Yeah, I Do you remember which one to switch? I'm trying to remember. Uh, cuz I, I honestly used these interchangeably all the time before, and I, and I think, honestly, I think it's when I, I think I got it from when I read your book, the parameters are what you can pass in and the argument is the value of the parameter. Is that right? I can't remember. I I always reverse that.

Josh Goldberg: 27:00

You're absolutely right.

Nick Taylor: 27:01

Okay. Yeah.

Josh Goldberg: 27:02

Yeah. Parameter. That's a very good sentence. Thank you. I think you said this person's name is Nicky Meuleman. The way I personally remember it is that you can give an argument. I give my spouse, my wife arguments all the time. So like you give an argument to someone and then parameters are like you describing, these are my specs. In order to effectively read generics documentation, because a lot of it is so technical and jargony, it's really helpful to know the difference. But then people also use the two interchangeably. So now you have like four things, like type arguments, value arguments, type parameters, value parameters. The whole thing.

Nick Taylor: 27:34

I would agree that generics is probably the one that kind of breaks people a bit. I'll go back to like, cuz you, you did C# as well. I think this is probably one of the more difficult concepts of TypeScript, but I, I found I eased into this well because I had been doing generics in C# for a long time. It felt pretty natural, but I could 100% see this as like, if this was a first time, kind of what's going on here, You know? There's also the, like for the type parameters, like with the generics, from C#, they always used to use like T, U, and V like capital and it, that broke so many people. Like I remember. I've seen at least one blog post from Kent C. Dodds saying, Please name your type parameters. Like not T you know? Uh, and it makes sense. Yeah. Uh, I think it, it's okay maybe if it's like literally just like a lambda in there, you know, like from like C#. But even then it's still, it's not explaining anything aside from saying this is a placeholder for something. I think this ties into it being inferred cuz before it never, I don't think it used to be inferred when generics came out. Like, like if you said like, identity of T. arg colon T here. I think you still had to specify the T in the generics initially. I'm not positive about that, but cuz like nowadays you don't need to because if it's a generic function, like this identity, if I pass in string, sorry, if the argument is a string, then it's gonna know it's a string that it's handling. I'm not positive about that, but, this is definitely the one that totally trips it up. I, I think the other thing with generics, I've seen with people that get thrown off by it is they'll understand, okay, I can pass in this certain thing. Say a generic function takes an array, for example. And then you're like, Okay, I have my array. So like, because it's a generic array, you only get the methods of the array. But I've seen people go like, I passed in an array of like People. Why can't I access the person properties in that, you know? But it's because it's a generic array. You only get like the sort, the, the map or whatever. So I've seen that happen with people too, with the generics.

Josh Goldberg: 29:40

Yeah. I, on a few points here, one, I agree with you and Kent C. Dodds, that you should most of the time name your generic, something useful. The T whatever, it's the same as using variable names. If you have a for loop, for let i less than equals like less than, that's fine. That's a convention. But like if you have a function that takes in three type parameters, T, U, V, like what the F is that? You know, like that's

Nick Taylor: 30:04

Exactly, exactly. I think it's less problematic if it's one parameter, but even then you might, as you know, it's, it's gonna get stripped out when it's compiled. But having said that, coming from C#, I was guilty of the single letter parameter names for my first few years of TypeScript.

Josh Goldberg: 30:20

That's okay. That's a community convention thing and the C# community just needs to get its act together. Although, I will say I've loved C# as a language. It's so good. Thank you. async await. Another thing I wanna point out. I think also that I have learned the hard way to try to frame things in terms of foundation, like how high up in the stack you need to use them. A lot of people phrase generics as advanced, like the word advanced or experts or similar to that. And then that scares a lot of folks. Like they hear this reputation online that generics are impossible, hard to learn. You have to be an expert. But really it's that you have to be an expert to use the really advanced, fancy features of like multiple conditional maps types put together. But having a single generic on of function is not an advanced, it's not beginner, but it's not an expert level. One of the things that I set on at or learned and was taught at Codecademy working there is how to frame contents in ways that are accessible to newcomers. For example, by calling things foundational versus built up or, non foundational rather than beginner and expert. By saying beginner, you're implying that other stuff is for experts, which makes people not wanna do other stuff.

Nick Taylor: 31:32

Yeah.

Josh Goldberg: 31:32

Fun facts.

Nick Taylor: 31:32

I know we're not gonna have a chance to talk about these, cuz you gotta go in a few minutes, but I'm gonna drop the, two links for the. ESLint, like the AST, link you sent me and also the tour de source from Sourcegraph there. I can pop 'em up real quick here. I'm gonna drop 'em in the chat, but, if we come back to screen sharing for a sec.

Josh Goldberg: 31:54

We'll, we'll have to do another screen just to talk about it. It's such a juicy topic though. How does a language work? This is another thing. A lot of people think in order to understand abstracts syntax trees, like how do linters, tooling like TypeScript, how do they work? You have to be some genius expert with two decades of experience. You can learn this stuff relatively quickly after learning TypeScript for the first time. And it can be very approachable if you find, you know, good documentation. If you don't mind me saying, so the stuff you're putting on screen that I helped make.

Nick Taylor: 32:24

Yeah, yeah. No, it's great. I'm gonna definitely check this stuff out. I think that'd be amazing if, if you're up for it. It'd probably have to be in the new year, but, if we could kind of do a bit of a dive in the ASTs it obviously, because also, just to kind of like, I know there's definitely some people in the chat that are familiar with ASTs, but you know, it's not just for ESLint. It's also like stuff like prettier, you know, they all. The ASTs to, to be able to parse the code to put the beautiful output or, give the specific errors and stuff. This is definitely a topic I would be interested in because like I was telling you before the stream, I've been a consumer of tools that uses, so like obviously ESLint and Prettier, I've ran some code mods, like I was saying, like when React pulled out prop types. I remember it was so magical just running that code mod and it updated like a hundred files. Compiled right away.

Josh Goldberg: 33:14

beautiful.

Nick Taylor: 33:15

You. You know, and I've been in AST explorer, tinkering around, but I've never actually built anything with ASTs and I think that would be something cool if we could maybe, next time, you know, like, Hey, let's make up some TypeScript, ESLint rule. It doesn't necessarily mean it's gonna be a real one, but just to kind of go through the process, I think that'd be super interesting and. Also just from, like I said, from a selfish point of view, it'd be good for me to to just dive into it.

Josh Goldberg: 33:41

Awesome. I'm very down.

Nick Taylor: 33:43

I just wanted, before we go, I'm gonna drop a link again to your book and to your link. So your GitHub and your Twitter. Definitely give Josh a follow on Twitter if you can and you want to sponsor him. And yeah, just thanks for all the work you've been doing in the TypeScript space. Before we wrap things up, anything you wanna say before, uh, you head out?

Josh Goldberg: 34:03

Well, first of all, thank you for letting me go on and again, apologies for the hard stop in a couple minutes.

Nick Taylor: 34:08

Oh, it's all good.

Josh Goldberg: 34:08

It's, this has been fun. Thank you for listening to me. Definitely. Let me know, reach out to me if there are any like features or things you want me to work on in the TypeScripts, ESLint area. Early on is mentioned the chat performance. That's something I'm gonna be looking at later this year, trying to get TypeScript ESLint as speedy as we all think it should be. Also, please again sponsor me on GitHub and or sponsor the TypeScript ESLint project. We actively work to make the TypeScript dev experience better and we have so little money it's really hard to get things done. Fun fact actually about TypeScript BS slt, our parr. The thing that parses TypeScript syntax, is used by Prettier. So we actually have more downloads.

Nick Taylor: 34:49

Oh, I know you gotta go, but John Riley popped in the chat, so, Hey John. Thanks for all you've been doing in the community. Cool. All right, well, have a good day. I know you gotta get to your thing, so I'll let you run outta that WeWork. And, next week folks, gonna be hanging out with Zach Leatherman talking about WebC and all the Eleventy goodness. So thanks again, Josh, and we'll see you all next week. Bye bye.