WTF Typescript?

Trash presents his Typescript presentation from Render ATL (Sorry if you are audio only listener) 🔗 Sponsored by Sentry https://sentry.io | Code breaks, fix it faster 📌 Chapters: 00:00:00 - Intro 00:00:42 - Who’s actually a “web developer”? 00:02:31 - Trash’s live intro & TypeScript presentation setup 00:03:59 - Sentry #ad 00:04:38 - Excess property checks in TS 00:09:42 - WTF: Object spreads silence type errors 00:14:30 - React prop spreading madness 00:18:22 - Structural vs duck typing debate 00:24:00 - WTF: Enums and why everyone hates them 00:27:45 - Enum strings vs numbers behavior 00:33:10 - Why enums in Node are cursed 00:36:55 - Safer enum alternatives using const objects 00:43:10 - TS quirks: Boolean filter keeps undefined in types 00:46:40 - TSReset: The “CSS reset” for TypeScript 00:49:01 - WTF: Empty object {} lets everything through 00:52:32 - Doom rendered in TypeScript type system 00:54:00 - Type-level math in TS (it’s real) 00:56:33 - Scaling hell: TS performance bottlenecks 01:00:01 - Flamegraphs and fighting TS perf without docs 01:04:55 - TS inference vs explicit typing in large codebases 01:09:30 - Prime’s favorite TS bug strikes again 01:14:01 - Casey breaks down the compiler logic 01:17:50 - Is this a TypeScript bug or a feature? 01:22:44 - Final thoughts and community love --- **Topics Covered:** • TypeScript excess property checks • Enums vs object literals • Structural vs duck typing • TS compiler edge cases • WTFs that break your mental model • Type-level math • Performance debugging hell • Massive monorepo pain points • The one TypeScript bug Prime can’t let go

• 0:00Speaker 00

  This is the episode though where Casey's gonna find out that like he's been calling all three of us web developers, but Trash is the only one who actually knows how to develop for the web.

• 0:11Speaker 01

  I mean, you could use TypeScript in the server.

• 0:14Speaker 02

  Okay, so Trash is a web developer and you guys are web developers is what you're saying.

• 0:19Speaker 00

  Yes, thank you. It's what I've been trying to say all.

• 0:22Speaker 01

  I'm just a normie, but everyone's so bad at their craft that I just rise to the top.

• 0:28Speaker 01

  Which is really funny. You can just be like, normal, and that's like really good.

• 0:36Speaker 00

  Nice. Then they give you talks at Render ATL.

• 0:38Speaker 01

  Exactly. They're like, this guy's a genius. I'm like, ah, no, I just know the basics.

• 0:42Speaker 00

  Oh, hey, Prime.

• 0:43Speaker 03

  Oh, howdy doody.

• 0:45Speaker 01

  Hello? Hello?

• 0:47Speaker 02

  Are you ready for some TypeScript Prime?

• 0:49Speaker 03

  I am so ready for TypeScript.

• 0:55Speaker 03

  Uh, anyways, I'm sorry. Alright, hey, I'm gonna do the introduction right now, okay?

• 0:59Speaker 01

  I'm low-key freaking out right now.

• 1:00Speaker 03

  Okay, okay. Uh, hey!

• 1:02Speaker 02

  You got this, Trash. You got this.

• 1:03Speaker 03

  Trash, you're the man, Trash. Trash, you are awesome!

• 1:06Speaker 00

  You got this.

• 1:06Speaker 01

  I'm freestyling this, okay? This isn't gonna be...

• 1:09Speaker 03

  Trash! Alright!

• 1:09Speaker 01

  Oh, just go, just go, just go.

• 1:11Speaker 03

  Here we go. Today's, let's see, today's stand-up is a special one. We have with us a legendary engineer, Chris Batista, you probably know better as Trash Dev, gonna give us an amazing presentation about TypeScript, build system speed, performance, usability, all the good stuff. Uh, Trash, unironically, drinks from a mason jar, just like me, so good job Trash, really appreciate that. Hey, cheers, buddy. But second off, he's actually a very talented engineer, and if I were to have TypeScript problems, there's the first person I would call would be Trash. He's actually quite excellent, so I'm very excited for this talk, and I'm even more excited about Casey being confused by the fact that there is JavaScript that's not JavaScript, that can't run, that takes a long time to make into JavaScript.

• 1:56Speaker 03

  And just, this is just, I'm very excited about this whole thing, so this is gonna be excellent. So Trash, could you please take it away for us?

• 2:03Speaker 01

  So this is how I'm gonna approach this, because I want to get through like... The less interesting parts, I feel like, in my opinion, and get to the stuff that I think Kase will get interested in. So I'm gonna pick pieces of my presentation to show you, just stuff like weird quirks that happen in TypeScript. And then we'll kind of like go into the more in-depth stuff and kind of just like, then we'll probably just end up freestyling at that point. And this is also weird for me because I only have one monitor. So I have to like, you're basically gonna see me like finangling all this stuff live. So Joshua, whoever's gonna edit this can edit it. So, so first things first is like, TypeScript is an interesting language where,

• 2:41Speaker 01

  in my opinion, there's like a spectrum of like skill level, I don't want to say skill level, but just like familiarity with the, with the language. And I feel like most people don't take the time to actually jump over that hurdle and get to the more advanced stuff. Not because it's their fault, but more of like the work that they're doing doesn't really actually call for it. So like the talk I'm doing, it's very high level. Because I think most people fall into that kind of bucket. But then there's pieces of my talk that I kind of skim over because I don't want your eyes to glaze over during a presentation, right? And I was also at the end of the conference.

• 3:14Speaker 03

  Trash, can I interrupt for one second?

• 3:16Speaker 01

  Yeah.

• 3:17Speaker 03

  What is the title of your talk?

• 3:18Speaker 01

  It is called WTF TypeScript, literally. Dude, I had some bomb-ass memes during this presentation that I was so terrified that weren't gonna land. But thankfully, everyone started laughing and I just like, then all my like nervousness went away. I like called it out in the beginning. I was like, guys, I'm like freaking out right now. And I was doing a sound check. The emcee was introducing me and I had a, like a remote mic on my shirt. And when I was sound checking, my mic wasn't that loud. So while the emcee was introducing me, I went skirt into the mic and it just like filled up the stadia, not the stadium, it filled up the room and everyone just like looked at me and I just like frozen terror. It was like the worst thing ever. But anyways.

• 3:59Speaker 04

  Did you find the errors? I don't even know what they look. What do they even look like? They're in the phone. In the phone? Yeah, they're definitely in there. I just don't know how we labeled them.

• 4:10Speaker 03

  I got it. Don't worry.

• 4:12Speaker 04

  You gotta figure it out. We're running out of time, Prime. You gotta find them and meet me at the stand-up.

• 4:18Speaker 03

  Roger.

• 4:20Speaker 05

  They're in the phone. It's so simple.

• 4:28Speaker 03

  Get all the context you need to debug your problem. Because code breaks, so fix it faster with Sentry.

• 4:38Speaker 01

  Alright, I want to show Casey access property checks. Oh no, on this screen it kind of like makes things crap, but it's fine. So access property checks, so check this out. So, this is a type, so you've never seen TypeScript before?

• 4:50Speaker 02

  I've never.

• 4:50Speaker 01

  Okay, so the function looks like JavaScript to you. The only difference between JavaScript and TypeScript, in my opinion, you see these little colons here and that's your type afterwards. And then the type definition is at the top. Hopefully that's pretty obvious, right? So you have type person, it's an object-like structure and has two properties. First name a type string, age a type number. And then this function obviously will have taken its own parameter and it's of type person. So, the interesting part with TypeScript is, okay, if we call it like this, this looks normal, right? This doesn't error out. Business as usual, if you actually work in the TypeScript ecosystem, if you pass in an extra property, it's going to actually break with extra prop. So hopefully this all makes sense.

• 5:32Speaker 01

  Like this is actually like aligning with most web developers' mental model. But what's interesting here is if you extract this object, the type error goes away. Right, which isn't the biggest deal. So the difference here is like TypeScript is structural. So as long as it satisfies the contract of first name and age, TypeScript's like, cool, I don't care. We have those two properties, I don't care about the rest, right? Which may not be what you want. So if you actually want that behavior of like getting that error that we saw on the previous slide, you have to explicitly type it. Right? So this kind of makes sense, has an extra prop, it breaks. But if you're just like really want to add this extra property, you can literally just spread an object into this and then the type error goes away.

• 6:15Speaker 01

  So, that's literally the first WTF of TypeScript, right? So this actually blew people's minds. They're like, what, I didn't know you can do this? Honestly, like pragmatically, you probably would never do this. Most people don't even-

• 6:27Speaker 00

  Except people do.

• 6:28Speaker 01

  Yeah, exactly, exactly.

• 6:30Speaker 03

  So why does that work? Because I thought spreading TypeScript was able to trace the types through and the properties that you get. Why does that work?

• 6:38Speaker 01

  So I don't know the technical reasons, but I just don't think TypeScript can actually follow it. Right? I just think it just sees the first two properties and then it just can't. I think it's like the same scenario where you extract it like this. It doesn't know what's in there and it kind of just treats everything in this object as a excess property. At this point, so I don't know, I don't know like the actual technical reasons if you go into the compiler. I'm sure some like team member can tell you why I just know if you do this, it makes it go away. And I've seen this actually like in some like.

• 7:05Speaker 03

  So why wouldn't you just use a TS ignore at this point? Or an as person?

• 7:10Speaker 01

  TS ignore just opens up a whole nother, opens up a whole other thing of like can of worms. Usually what people do is they'll opt for this. They just want to explicitly talk about it. Cause at the end of the day, as long as you have first name and age, it doesn't actually matter. Like your code is only typically going to look for those two properties. Unless you have like some validator that's actually like enumerating the properties of the object, it could actually break stuff. But more times than not, this would usually be fine. So this.

• 7:35Speaker 00

  Trash, I got a question.

• 7:37Speaker 01

  Yeah.

• 7:39Speaker 00

  If this, if this behavior didn't exist, wouldn't like everybody's strategy for passing around properties and react just like completely get demolished? Right? Isn't this what everybody does is like you've got some big object with a bunch of context. Everybody just spreads it all the way down, right? Do they not?

• 7:56Speaker 01

  That's like a whole other conversation of just like dumping bags into like other functions and you have no idea what's in there. This is a problem. I don't, I don't know like the exact react types, but I know the practice of just like taking a bag of anything and just passing it down is a thing.

• 8:10Speaker 00

  Yeah, you're just like, we just pass.

• 8:12Speaker 01

  Yeah, you literally just spread props. It's actually a real big problem and I've experienced this pain firsthand and I actually hate it. I don't think it actually at the type level catches it. Cause I've been in code bases where we're just like, I don't even know what's in here, but I'm just going to spread it. I'm just going to spread it down. And drill it to the core of the earth. Cause I have no idea. So yeah, I don't know at the type level. I'm not too familiar with like the react types in depth, but potentially, right?

• 8:34Speaker 03

  Casey, just so you know, when someone spreads, it's actually taking that object and copying it key and value in. Not doing a deep copy, just a shallow copy of key and value, which means that every time react renders, every single component recopies the same object. Through all the way down. So if you have thousands of components, you create thousands of copies of objects every single time. Just so you, just so you understand, because I feel like this would be kind of like a fun, like illuminating fact for you.

• 9:02Speaker 02

  Actually, Trashed, I mean, this is gonna be one of those things because since we're all actually interested in this, like, this is gonna be like, one slide per podcast.

• 9:10Speaker 01

  No, this is perfectly fine.

• 9:12Speaker 02

  And six weeks from now, we'll have gotten through the presentation.

• 9:16Speaker 02

  Sorry, just for my benefit, so, can you go back to the thing where you called the function and you got the error in the first place?

• 9:24Speaker 01

  Sorry, I'm not supposed to go backwards in these. This one.

• 9:27Speaker 02

  Oh, I'm sorry. Okay, well, I just was curious. Never go back. So I'm just wondering, compiler-wise, why does it see a difference between these two things? Because to me, when I look at that, I'm like, okay, what that would normally do is first it would evaluate to an object. That object should be the same as the person object you were creating before, because it has exactly the same members, in exactly the same order, written exactly the same way. So, there's a special case in TypeScript for if you're constructing an object only inside the call to a function, and in that case, it will check?

• 10:04Speaker 01

  Yeah, so the compiler will treat inline objects this way, but outside it won't do it.

• 10:11Speaker 02

  And so-

• 10:11Speaker 01

  I don't know the exact specifications on why, but this is the behavior that everyone's kind of been accustomed to.

• 10:17Speaker 02

  So that kind of suggests this is very intentional, right? Because that means they probably special-cased this and said, "Oh, if this object has a property that isn't used, because the only place that it actually would go is someplace where it's not used, we'll give you an error about that. But if you have a regular object and you could pass it to a function that would work, we're gonna make that work." So that, it kind of feels like that must be intentional. It's called duck typing, right?

• 10:41Speaker 01

  Yeah, exactly.

• 10:42Speaker 02

  They have a term for that, right?

• 10:43Speaker 01

  Exactly. If you think about how just JavaScript works, it doesn't care about any of this. You can pass anything, right?

• 10:47Speaker 02

  Duck typing's all fake!

• 10:49Speaker 01

  Yeah, I mean, like you said with duck typing, if it just has these properties, it must be a duck, right?

• 10:55Speaker 02

  And this is not necessarily a bad thing, TJ. Duck typing is a feature, right? It's a thing that, and so, you know, when you're making a language like they were with TypeScript, they have to decide what's the default behavior, and maybe their thing was like, "Okay, we're gonna decide the default behavior is duck typing." And if we detect somewhere where it's clear that you probably didn't actually want that, then we'll error. Like, in this case, because there's no way extra prop can be used here. It's only going towards a function that, right? So, you know, I'll be honest, I'm-

• 11:28Speaker 02

  I know people probably expected me to think that everything sucks, but looking at this, I'm like, "That sounds like an adult designed this." Just completely honest, that seems like an adult designed this, to me.

• 11:40Speaker 01

  Yeah, I mean, like, just imagine just trying to type a dynamic language like JavaScript. Like, it's never gonna be perfect, right? So you can always get as close as you want. And then you kind of make these arbitrary decisions on like how you want this experience to be.

• 11:52Speaker 02

  So Casey's thumbs up so far. Sorry, guys.

• 11:55Speaker 00

  Let's go!

• 11:56Speaker 02

  I'm thumbs up so far.

• 11:57Speaker 00

  Can I ask, Casey, do you think it's... Is it... Do you like that? Because I agree, I like this one, where it says, "Yo, you passed an extra prop, you shouldn't do this." But do you like being able to do the next phase, where it's like, "Oh, I just put... I just have an object and I pass it and it has extra properties." Because that, like...

• 12:15Speaker 02

  Yes.

• 12:16Speaker 00

  Okay, alright, cool. Just making sure.

• 12:18Speaker 02

  Like I said, it's... So Duck... I actually like Duck typing if I ask for it, right? So like, I would prefer that more languages have the ability to do Duck. For example, you can think of C++ templates as supporting Duck typing. Because if you pass something as pass... I mean, if you instantiate a template and you have a parameter that has the necessary things, but also a bunch of other things, it will work, right? Because it's... What it's doing is it's gonna create code that works for anything that supports that feature at a minimum. It's not gonna say you can't have these other things. And to me, that's actually better, because it gets me more code leverage. It means I can use more functions on more types, as opposed to the opposite, which is when you try to do the object-oriented,

• 13:01Speaker 02

  like, very Procrustian, like, type hierarchy thing and make it's like, "We only... Everything has to be the minimum set, and functions can only work on exactly the things we said, right?" That really handcuffs you, right? So, to me, Duck typing is great. Would I have wanted it in an ideal world, perhaps, to be more explicit? Like, I say if I want Duck type or not? Maybe, but again, in the context of a JavaScript front-end, which is what TypeScript is, I think this is a reasonable choice for a language designer to make, because most of the existing JavaScript ecosystem is being Duck typed by default. So if you make it really... Onerous and annoying for the person writing the code to constantly be saying duck type,

• 13:43Speaker 02

  duck type, duck type, duck type, duck type. That's gonna be annoying. So again, seems like adult design to me. So, so I'm thumbs up on everything you showed so far.

• 13:51Speaker 03

  Can I ask a quick question? This is just a general question. Is there a specific difference? In my head, the duck typing versus structural typing. And structural typing is about the properties and the available functions, whereas duck typing is only about the functions? Is there like a difference? I'm not, I'm not actually sure if there's actually a difference, or is duck typing like the, the local or the colloquial version of structural typing?

• 14:15Speaker 02

  I don't think I know the term structural typing, but duck typing literally just comes from the phrase, if it looks like a duck and quacks like a duck, then it's a duck. So literally, it's just like, if this thing can do what I need, whether that's member functions, or having particular data items, or whatever it is, then I consider it to be the type I needed for all intents and purposes. And I'm not gonna inquire further to see whether it actually is a exact copy of that type. I'm just gonna say, does it have similar things to that type that will work? Right? I don't know. What is structural type? Sorry, I don't know that term.

• 14:49Speaker 01

  So structural type, I just think about Legos, right? So if they have the same shape, they're probably the same thing, right? So like in this case...

• 14:55Speaker 00

  They're the same, basically. Like, structural subtyping, I think, is the functional programmer way to say duck typing.

• 15:01Speaker 03

  Okay, that's what I, that's where I was having this impedance mismatch, is I knew they, in my head, they're the same thing, but I'm like, what's the difference? There has to be a difference, but okay.

• 15:08Speaker 02

  Well, if it comes from functional programming, they're definitely not the same thing. And somebody will be in the comments going, "I can't believe they called structural typing duck typing!" And then 20 paragraphs later, there will be this minor, tiny little difference that no one cares about. But, yes, they probably are the same then.

• 15:26Speaker 00

  So we'll get them, we'll get you guys in the next episode. We'll have the answer solved. I'm not gonna look it up myself. I will just read through the comments after this video. Thanks, guys.

• 15:34Speaker 03

  All right, trash, go on.

• 15:35Speaker 01

  All right, so 20 minutes later, we got past the first, first section. So, we'll see how far we get of this. This is actually, okay. Let's keep going. Okay, enum's. I'm assuming everyone else is enum's them. Okay, this is an interesting example. I wouldn't say it's the most interesting one, but I, I think it's pretty, pretty cool. So, let's look at enum's, colors. They just have string values, so green, orange, red. Nothing particularly interesting here. But we want to use this enum in a function. So we'll just have some placeholder function is the best color. It's parameter is going to be of type colors. That makes sense.

• 16:07Speaker 00

  Right. Oh, sorry. I thought you were asking.

• 16:11Speaker 03

  Green is the best color.

• 16:12Speaker 01

  How did you know? So if we call it like this colors dot green, this makes sense, right? It shouldn't look any, it shouldn't look surprising to anybody that's used TypeScript or just coding in general, I feel like. But if you call it as its actual value, it's going to break. So if you see here, we're calling it with the string value green. But if I console log colors dot green, it fails even though the values match, right? And this isn't the biggest deal. The, the biggest annoyance I think I experienced personally and other developers is when I call this function, I now have to import this enum just so I can call it. I, even though I, if I know the values, I can't just call it with green, orange, red. So with auto importing, not the biggest deal. But where this is interesting is going to be in my next example. So right now, any questions like this all? This is like, does all make sense?

• 16:57Speaker 00

  Good so far.

• 16:58Speaker 01

  Okay.

• 16:58Speaker 00

  Good so far, Trash.

• 17:00Speaker 01

  Alright, so let's talk about enum's with number values. So we're gonna have like pending decline approved, zero, one, two. We're gonna call it again, just like we did in the previous example. Stats dot decline, you know, makes sense, makes perfect sense. But if I call it with this corresponding value, we don't get that type error. So it looks like-

• 17:19Speaker 03

  I love C.

• 17:22Speaker 01

  So yeah, i- i- it works here, but it doesn't work in the string, in the string case.

• 17:26Speaker 02

  What happens if you passed three?

• 17:29Speaker 01

  I don't actually know.

• 17:30Speaker 03

  I'll type it up right now.

• 17:32Speaker 01

  I'm pretty, I'm pretty sure it's gonna work because there's gonna be a type number, but I can type it out real quick.

• 17:38Speaker 03

  I'm doing it right now.

• 17:39Speaker 01

  Do it real quick.

• 17:41Speaker 03

  Oh, boy.

• 17:42Speaker 01

  I almost-

• 17:43Speaker 03

  Uh, right now it says, uh, argument of type three is not assigned to parameter type status. Yeah, it, it doesn't allow three. So it does actually look for the numbers. So it's, it's like half C.

• 17:57Speaker 01

  Have seen, exactly. So this one's like interesting, like it's not something I don't think anyone's gonna actually encounter like day to day. But it was like an interesting case on like its behavior, so I included it.

• 18:09Speaker 02

  That feels like it must be a bug unless they couldn't have intended that.

• 18:12Speaker 01

  There's reasons here that I don't remember.

• 18:15Speaker 02

  Oh.

• 18:16Speaker 01

  I don't remember, but there are, there are reasons, but reasons that you don't ever probably care about. But now I'm gonna look, I gotta remember, like when I was making this talk, I was like, I learned why it's doing it and I completely just purged it from my memory.

• 18:27Speaker 02

  Interesting. Yeah, I'd be interested to know why they did that.

• 18:29Speaker 03

  Someone is trying to say that it's the difference between references versus direct values, but they don't understand that uh V8 at least operates on heaps or uh smes, small uh small numbers. And so that means if you have a number below 2 to the 32, it's actually inlined inside the uh reference. So it looks like a heap item, but it actually has a tag to say, hey, this is actually an inline number. So I wonder if this works with numbers above 2 to the, or yeah, 2 to the 32. Does that break the whole reference because then it becomes a box value and it's no longer a small number?

• 18:58Speaker 01

  Potentially. I know there's actually a limitation on like what numbers you can use as well as values.

• 19:02Speaker 02

  But TypeScript is compiled, so it wouldn't care, it doesn't matter what the runtime engine uses, right?

• 19:09Speaker 01

  I think there's stuff, there's also stuff built in into the compiler that will like.

• 19:12Speaker 02

  Right? No, I'm, I'm serious, right? Like this is a, this is a compiled, this is a compile time error, right? Like we're, this is not a runtime error, it's a compile time error, right?

• 19:21Speaker 01

  Yeah, yeah, yeah.

• 19:22Speaker 02

  So it doesn't matter, like what V8 does is irrelevant. It, this is clearly something that the compiler must know. Because it knows that the definition of validate status uses type status, which means it must be visible. So it knows that you're passing 1, which is a constant, a numerical constant, to something that requires status. So somebody, like somebody in the compiler said that was okay. They must have had a reason for that, I think, because that would be a pretty straightforward bug to fix if it was accidental. So I, I really would like to know what the rationale was because those two things are known to the compiler and it's choosing to let you do that and not let you do the green case. Why?

• 20:02Speaker 01

  Yeah, I'm pretty sure there's like an explicit, from when I'm trying to recall what I remember, but I think there's like an explicit decision here.

• 20:08Speaker 02

  Yeah.

• 20:09Speaker 01

  We'll find out, we'll find out though. It's easy to figure, it's easy to find out, for sure.

• 20:13Speaker 02

  Yeah.

• 20:13Speaker 00

  Alright, that's point number two in the YouTube comments we'll be looking for.

• 20:16Speaker 02

  Yeah.

• 20:17Speaker 00

  We'll read it.

• 20:17Speaker 01

  Yeah, can someone leave a YouTube comment and let us know why?

• 20:20Speaker 02

  Yeah, hook a Casey up with that.

• 20:21Speaker 03

  Also, I do, I do want to say that TypeScript doesn't know what is or is not a reference. In the sense that it would actually have to do type checking of the thing to be like, "You're a string, you're definitely a reference. Oh, you're a number? How big is the number to see if it's a reference or not?" Right? You don't actually get that access, it's not surfaced to you in JavaScript. So, it can't be based on that. It's based on someone made the intentional design decision that numbers can be raw dogged and strings cannot.

• 20:43Speaker 02

  Yeah. And they are checking, like, they, they, like, 3 didn't work. So, it's not like, it's just like, "I don't know, we're just gonna push numbers." Like, no, in the compiler, it knows. So, if this was intentional, and I'd love to know why. Yeah, I'd be interested to know. There might be, there might be a very good reason, like, "Oh yeah, because of blah." Like I said, I, I wanna say, I, I want to say that I remember the dude who made the TypeScript compiler in the first place, or one of the main dudes. I wanna say that he was a friend of Dave Stafford's, and I had lunch with him way back in the day, and this dude is Baller. He wrote, like, I think he's the guy who wrote the original Microsoft Java, like, before V8, before Chrome, before any of these things, the original JavaScript, uh, like, uh, runtime

• 21:27Speaker 02

  engine for, like, IE when it first got that. And it was pretty, it was better than everyone else, it was like, way better than, like, Netscapes or whatever, right? So, I, I'm, I'm not coming into this with a mentality that this was just like, a bunch of toddlers in diapers running around going like, "Woo-hoo!", right? I think, like, I'm gonna give them the benefit of the doubt for quite some time, but I feel like there's an explanation here, I'd love to know what it was. Anyway.

• 21:48Speaker 00

  I'll, I'm gonna stake out my guess, and then I'll, well, that's also the best way to get a YouTube comment, because they'll say, "Hmm, actually TJ's an idiot, um, here's what it is." So, here's my guess. Um, and I actually think it has something possibly to do with what you're saying, Prime, is I do wonder if there's a few comparisons or operations that would work for numbers to check equality that don't work for strings? Where, if you're not holding a reference to the original string, right? Like, where you do green? If there's like some comparison that checks like the string green versus another string green, are there some operations that get you different results? That's my guess.

• 22:27Speaker 03

  Maps would be the only ones.

• 22:28Speaker 00

  It won't happen.

• 22:29Speaker 03

  Yeah, true. I think you can use map instead of actually use references potentially. I'd actually have to double check that to see, does it use references to string green? Or is it actually just literally string green? That's, that's, I don't know, but I don't think that anywhere that you can do that with enum. So I'd be very, it would be a surprise to me to know that you can do reference based in, um, anything in JavaScript other than potentially maps.

• 22:52Speaker 00

  That's my guess.

• 22:53Speaker 03

  That's a good guess. It's a really good guess.

• 22:56Speaker 01

  So let me show you the alternative to enum's that people started doing instead. Oh, oh no.

• 23:01Speaker 02

  Are we going off script here? Are we going off script?

• 23:03Speaker 01

  No, can you see my screen?

• 23:04Speaker 02

  Yes, I can.

• 23:05Speaker 00

  Oh, he's on script. Holy cow. Nice, Trash.

• 23:07Speaker 01

  Well, I didn't do this during my talk, but I'm gonna do it here.

• 23:10Speaker 00

  Yeah, I love this.

• 23:11Speaker 01

  So, so people stopped doing enum's and they favor this stuff right here. So this is actually like you actually defining, this is JavaScript at this point, but then you add this as const here, which is like, kind of like object dot freeze, kind of freezing the object, but at the type level. So instead of doing enum's, people actually do this, convert that into a type. And then, this is kind of getting into the weeds, like you're probably just gonna be like, what the hell is happening? But the experience now is, I don't have to import an enum. I get like this, I can now see all the values that are valid, right? So this is what people like to do because at the end of the day, the enum's actually turned into runtime code,

• 23:51Speaker 01

  which is actually one of the things that like, I believe the TypeScript team kind of regrets is using enum's. Like, there's actually like a rule in TypeScript now, if you're, if you're doing TypeScript in Node to actually not allow you to use enum's because they're not strictly at the type level. They actually have runtime implications. Um, so people actually started doing this instead of doing enum's. I'm not gonna explain it, but I just kind of wanted to show you like, this is an alternative.

• 24:13Speaker 00

  Explain it, Trash. Explain it.

• 24:16Speaker 03

  This is your chance.

• 24:16Speaker 01

  So again, I know, I know. So here, we're basically, this is where we intersect. Okay, let me back up. So TypeScript, which people always like mess this up, is strictly at the type level. And JavaScript is at the runtime level. Like, they don't intersect. The place where they can actually kind of intersect is this line right here, is where you do type of foo, where this is actually referencing some runtime code, right? This is actually, like, if you log this in your browser, it would give you these things. But now, you're converting this to a type via type of, and now you're officially in the type world, right? So we've officially turned this into bar. And now, we can see the type here, like, it's read-only failed.

• 24:58Speaker 01

  And we see it's read-only because this ask cons, because it behaves of like freezing something at the type level. So what we do now is, we can get all the keys. It's an object, right? So if we get the keys, we now see the keys.

• 25:09Speaker 00

  Dude, that's my dog's favorite type.

• 25:12Speaker 01

  What?

• 25:12Speaker 00

  Barkies.

• 25:13Speaker 01

  Oh my gosh, stop.

• 25:17Speaker 01

  You are the worst. Wait, is that an actual brand?

• 25:21Speaker 03

  No, Barkies.

• 25:25Speaker 01

  Oh, I thought it was like a brand like Chewy or something. Okay, okay, okay.

• 25:29Speaker 02

  The intersection of dad jokes and programming is TJ.

• 25:34Speaker 00

  Trish, I only wanted you to go line by line through this, because I had that joke as soon as I saw you bring this out. And I was like, I am not gonna let this joke pass. I am gonna get a chance to drop this joke right now.

• 25:48Speaker 01

  Let me fast forward through this, because you just wasted my time.

• 25:51Speaker 03

  Hold on, I got a question for you. I got a question for you. You can't use this approach with like type of in Kiev on an object that you don't know the shape of, right? So like, if you read something from a file, you can't just be like, type of thing? You have to first give it the shape, and then you can type of it.

• 26:05Speaker 01

  There's also another word called infer. And that's typically what you would use to do. So say you're using a third-party library, and they didn't export types. You would have to use the infer keyword to turn like someone.

• 26:17Speaker 03

  Okay, and that does some sort of like forward-looking or something to determine all the keys used on it, and then says it's this thing?

• 26:21Speaker 01

  Yeah, so like, yeah, so that would be how you would do that. It won't work like in every case. There's like quirks around that. But that's how you would like kind of do that. But anyways, like, this is, the most interesting part here is like, this is how you intersect the worlds of runtime code and then TypeScript code. It's via this typo, because now, after this line, we're strictly... Can you guys hear the vacuum?

• 26:46Speaker 02

  Yes.

• 26:46Speaker 00

  Oh yeah, but it's...

• 26:47Speaker 01

  Oh no!

• 26:48Speaker 02

  Is Dax at your house? Did you have Dax over?

• 26:51Speaker 01

  I got Dax's people over right now. Oh no, if I keep talking, does it go away? Like, if I just keep saying, "Hey..."

• 26:57Speaker 03

  No, but just keep talking and pretend like it's not there.

• 27:00Speaker 01

  Okay, anyways, well, I just want to show you this real quick. So, again, here's the keys of that structure, that object-like structure at the top. Fail and success. If we want the values, we would just do it like this. It looks like JavaScript, to be honest, right? Like, this is kind of like how you access objects with their keys, right? And you get their values. So now, if we did bar keys, based on Tej's joke, alright? We now see we get the autocomplete of this, fail and success. And if we do bar values, we can now see we get the autocomplete. So this is like, an alternative way to enum's, which people actually like doing instead. Like I said, the other quirk is like, with now Node, they have like, this new, like, strip... I forget the name of it, but basically, they don't want you using enum's in Node, in TypeScript. So...

• 27:43Speaker 02

  I feel like I missed something here, just so that we make sure that we get through a maximum of two slides per hour. So, I see what you're doing here, or whatever this... I understand the example that you showed here. But what I must have missed somewhere in between those is why? So, what was wrong with the enum version? And also, so like, for, at least for me, what I would have wanted as a programmer, when I was initially creating an enum, is I wanted to see...

• 28:19Speaker 02

  This is probably because I'm coming from a background of like, programming languages with enum's that maybe work a little differently. But what I wanted to see was x parentheses "success", no quotes around it. Because to me, as a programmer, that lets me know, "Oh, this isn't a string, it's an enumerate." So, this actually looks more confusing to the user, to me. So this looks worse than the enum case to me, and yet you're saying people go out of their way to do it this way. Why? What was wrong with the enum version that makes them want to do this?

• 28:48Speaker 01

  I think this is more up for... I think it's kind of subjective, in my opinion. So I'll tell you why I've seen people use it, and why sometimes I use it. One, because it's no mystery on what's actually being... Being compiled to so like if you did an enum you don't even know what that looks like at runtime right because it's all compiled down so at least here I can actually see what the Java's output is gonna be so it's like one reason so I can see the runtime code next to my types it's not hidden behind the compiler

• 29:15Speaker 02

  Oh like they don't want to see 0123 is what you're saying they want to see Okay

• 29:20Speaker 01

  Exactly and then also the other thing where you have to actually import like if this was a enum foo I would have to do something like I'll do vim mode broke in the playground oh my goodness let me refresh it I can't do this oh man this thing sucks okay anyways so what you would normally do you would do like foo dot failed right and you have to and you would have to like import that here you could you would actually since you are familiar with the values you could just do something like this and get everything right here so it's like that's more of a DX thing I don't think it's like the biggest gain well but I personally think people do it because of this and then someone someone in the comments can tell you otherwise okay but I think this is like the biggest win is actually seeing what the runtime code is

• 30:03Speaker 02

  I'm starting to understand I I see

• 30:07Speaker 03

  I think Casey and you are talking about two different things too right because Casey's used to see style where they're actually

• 30:12Speaker 02

  That answered my question

• 30:12Speaker 03

  They're like identifiers enumerations become identifiers for you to know about whereas in in this world you're actually having it's not that it's like these ethereal things that you actually reference with strings

• 30:24Speaker 01

  Yeah let me show you another big foot guy

• 30:26Speaker 03

  Can TJ has a thingy

• 30:28Speaker 01

  Oh yeah go ahead go ahead

• 30:29Speaker 00

  Yeah so yeah he can't see me so that's okay trash I do think the CM Griffin shout out CM Griffin in the chat and I think this is the other main reason is if you have to import like you gotta remember as well Casey right like people are not just shipping one blob of stuff sometimes sometimes this makes for like they are shipping one blob they're shipping it to the front end so this could mean like oh you have an enum you want to use it in your code okay now I import this package and now all of a sudden I like I'm gonna balloon the size of my JS bundle normally people like that kind of thing happening but like in the web world it's kind of a net negative to balloon your bundle so they're trying not to have that happen so if you You can just do a string directly, you can avoid like that scenario.

• 31:13Speaker 02

  If I, I'm sorry, I was gonna say, if my, like if I had to summarize my understanding of it now, just having only seen this much. I guess I would say, the problem is that JavaScript, the runtime layer, is basically forcing you to do one of two things. Either, you can use some kind of constant that already exists in JavaScript, which is either gonna have to be a string or a number, right? And if you choose number, then anyone who's calling this, who's not using TypeScript, is just gonna see like 3 as the parameter, which is not what you want. You wanted something that they could actually read. Yes. So you have to pick string, because it's your only other option for a constant,

• 31:56Speaker 02

  unless you were going to literally import an object whose references you could compare, or which is what you don't want to do. Is that a fairly reasonable summary for like why it's like, okay? Because otherwise, it would just all be numbers in the code, and people don't want that, because it can't be read in JavaScript. So it doesn't allow you to do like pound defines or anything, right?

• 32:16Speaker 01

  So here, here's one more interesting thing is like, so enum's are automatically assigned number values to them? So like, red and green is your own one?

• 32:24Speaker 02

  Yeah.

• 32:25Speaker 01

  So if you define your enum's like that, and then in your runtime code, you're depending on that order, you could easily break all your code by rearranging your, uh, the order of your, of your values. Does that make sense?

• 32:36Speaker 02

  Yeah, well, that's, I guess, kind of normal for enum's, is what, in general, right?

• 32:39Speaker 01

  Yeah, so that's like a fuckin' that people don't understand. So people like, if you actually need to depend on values, you need to explicitly define them.

• 32:46Speaker 02

  Got it.

• 32:47Speaker 01

  Otherwise, they get implicit values, and if you're depending on those implicit values, you can easily just like mess up the logic.

• 32:51Speaker 02

  Like, they save something to disk and reread it, and they think that because it's named the same thing, it will still be equivalent, but it's not because we changed the order.

• 32:59Speaker 01

  Yeah, because green would be 0, but it was 1 before, you know what I mean? So that could like, nothing I've seen like too much in practice, like on my end professionally, but I can definitely see someone like.

• 33:09Speaker 02

  Got it.

• 33:11Speaker 00

  Especially since a bunch of the functions for numbers will accept just a raw number, right? We saw that earlier.

• 33:18Speaker 02

  We saw that happen, yeah.

• 33:20Speaker 00

  So it's like that won't give you an error. That that does seem like a recipe for disaster.

• 33:25Speaker 01

  Right.

• 33:25Speaker 02

  Love it. Learned, learning a lot today. Loved Galactus.

• 33:29Speaker 01

  Right, so here, here's another quirk that I think is very popular in the ecosystem that people like experience day to day. So like if we use like a filter function of Boolean, that's just like a fancy way of just filtering out falsy values. So like in this array, we have one undefined three, the falsy value is going to be undefined here. So at runtime, if we log this, we get one and three. So by looking at that output, we would expect, since it behaves this at runtime, that it would give us a type of like a number array, right? But what actually happens is we get number or undefined because it's not able to narrow that. So like the implication here is like there are workarounds with like things like flat map and like type guards. But even though you know for a fact that runtime, you're never going to get undefined, you know, have to like program defensively

• 34:12Speaker 01

  against this case because TypeScript will give you like those like red squigglies because it's like there could be an undefined here. So that's the annoying part. And this, this next thing, this, this one hit hard during the live, the live thing. So I had like this thing here, this is Matt Pocock. He's like a big, uh, he's like a big, a big person in the TypeScript community. Dude, everyone laughed so hard, I was like, I was so happy. I was like, man, I'm really, before I hit the button, I was like, please let everyone laugh. But anyways, this is Matt Pocock, he built a library called TS Reset. And it will basically reset like these weird quirks that kind of go against your mental model. So if you use this library, it's kind of like a CSS reset, but at the type level or TypeScript. So it would actually give you number array versus number undefined. And there's a bunch of other cases this library accounts for.

• 34:54Speaker 01

  But like, like looking at this though, like this is kind of annoying and it's like a common thing people work around in their, in their code bases. So I don't know if there's any comments here. Not like, again, like, nothing too, too crazy, but it is like, really, really annoying.

• 35:08Speaker 02

  It makes perfect sense. I mean, you know, because it's like, unless you special case filter, and you basically say, alright, instead of, instead of treating filter as just a function that operates on an array, I now have to treat it as a special case where I know that it happens to remove things of a certain type from this array. Therefore, I should mutate the actual type of the array that it returns to be different from the type of the array that it takes, which would be a very unusual thing for a compiler to do. So it makes perfect sense why they did it this way. I can also understand why people get confused when they do it.

• 35:46Speaker 01

  Yeah, I think the corso, like, the workarounds, like, it just gets verbose, like, having to do like a typeguard, or...

• 35:52Speaker 03

  There's some oddities to this.

• 35:53Speaker 01

  It just kind of goes against your mental model.

• 35:54Speaker 03

  Right, so, so the big thing is you can actually throw a, you can throw a generic on filter, but, Boolean is a constructor, so it doesn't really understand that Boolean is also a function, you can treat Boolean as a function, and so it kind of blows up, and Boolean just returns, you know, it returns the positive case, so it has a really, it has this hard time mapping through things, and so it looks like it's, it just, it can't do it, so you can't use generics and the Boolean thing, because the constructor returns not that, and so filter kind of explodes.

• 36:26Speaker 02

  Well, you could imagine something even more ridiculous, right? Like, if, just to illustrate how odd this kind of case is, right? Is like, let's suppose that you imagine something where you're like, we have a typed array, and you're like, what type of stuff does this have in it? It's like, oh, you know, like, imagine you distinguish between integers and floating point values. So numbers like 1, 2, 3, 4, 5 versus 3.2135, right? And you can create one of these, and it has a mixed set, so it's got 1 and 1.5 in it, right? And then you have some mathematical function, or something like this, that goes through and rounds all the values. Like, you wouldn't intuitively expect the compiler

• 37:09Speaker 02

  to now change the type of the thing that you were... Right, because it's just something that happened to end up being true after some operations occurred on this thing. And that's sort of what's happening here. And, you know, when we're in C or C++ or something like that, it's very rigidly typed. And like, everything has a specific storage type as well, as opposed to sort of this generic storage type like JavaScript uses. Then it's very hard to get these kind of corner cases, because, look, if you had storage for a double, then you're always going to think of that as a double, no matter what value it takes, right? And so you don't expect it to be able to handle anything like this, because there's nothing like this that can happen. But when you're in a very flexible language, where the type of things can kind of mutate all the time,

• 37:54Speaker 02

  I feel like that creates real difficulties for the compiler vendor who wants to try and make it appear as if these things are more rigidly typed. So this, to me, makes perfect sense. And like, I can totally see why people are confused, but like, yeah, that's, that's exactly what I would expect it to do too, is the weird behavior, because that's just like, yeah, what else do you do? Except special case, or like, that dude did make libraries to try and like, special case all the things that might trip you up, and try to fix them like ad hoc, basically, you know? So this seems fine. I'm down. I understand that.

• 38:26Speaker 03

  Casey, something that might blow your mind is if you redo this, you put a generic on filter with number. So it's like, hey, I'll return a type number, and then pass in a function that checks for it to not be undefined, because the thing that got passed in was of type number and undefined, or like, or undefined, as an array of one of those two possibilities, and your filter function filters out specifically undefineds. It's able then to infer that the thing coming out is only numbers.

• 38:52Speaker 02

  Okay, so it was trying a little bit.

• 38:54Speaker 03

  It's like shocking, very advanced kind of type checking in there.

• 38:56Speaker 02

  Yeah. So, you know, I mean, this is like I said, I just, I can totally see this, just like, look, there's probably a bunch of cases like that. They caught some of them, they didn't catch others, you know, and so, yeah, so, good on them for catching any, honestly, I think. Yeah.

• 39:10Speaker 01

  All right. Ready for more. Hold on, let me see. Yeah. We're moving so slow that I'm gonna, I'm gonna have to like pick another one. Um, okay, this one's interesting. Alright, so at the type level, we're gonna have empty braces versus object versus lowercase object. And honestly, this literally trips up everybody. Um, I don't think it's like as much of a common case anymore because people just like explicitly type with like a name or something. But like, when you look at this, you kind of expect all three of those to be very similar, right? At least that's like how I react when I see something like this. So if we look at how types can respond, so we'll just have two variables here. We have foo

• 39:52Speaker 01

  and one with lowercase object, one with the empty braces, right? So if we do the one on the left, this one is going to, this one actually aligns with most people's mental models. It's gonna have an object and an array, right? Those are both objects. But any primitive value will not, uh, will not be accepted. It's, you know, booleans, undefined, strings. So this makes sense. But what's interesting, like if people are familiar with JavaScript, empty braces represent an object, right? You, I think like most people with Py think it would behave the same way. But the interesting part is, is that it accepts literally everything but null or undefined. And that's not very intuitive when you kind of look at this. I actually see a lot of code bases where

• 40:37Speaker 01

  people just say like something extends empty object when they actually mean they just want something to be like of an object like structure. But what's happening is you're literally doing numbers, booleans and objects, right? So you end up allowing way more than you want. So this is something that like, this is actually a huge problem I've seen pretty much in every company I've ever been in. Doing this kind of syntax. So that's the interesting part like.

• 41:02Speaker 03

  Why isn't it just only, why isn't foo just like only an empty object? Is there some sort of like writing about why it like, because if you did squirrely brace, but you put one key in it, then it's structurally that one key, but once you remove it, it becomes everything. Why isn't it just like it only allows for empty objects?

• 41:20Speaker 01

  I don't know, you're asking the wrong, we have to look at the compiler code on that one. I don't know, I just know like what the like result is. Um, but yeah, this is, this is kinda weird. And I always found that to be a foot gun because like at face value, these all kinda look the same. But yeah, I don't, I don't know. I would have to look at the compiler code and see like exactly why, or maybe someone in the YouTube comments can explain, uh, who's on the TypeScript team could like explain that to us. This is, this is like a perfect epis- episode to be mansplained in the comments.

• 41:46Speaker 02

  Right, right. What's weird about it to me is more that it does, that it doesn't accept null and undefined. Cause otherwise I'd be like, oh, well, maybe they just decided that, uh, open, open brace, closed brace is the shorthand for, I don't know what this thing is yet. Like, it's just like, I'm not, I, I'm just like telling you that this variable will exist, but I'm not gonna say what it is yet. Which, you know, we do in other languages, for sure. Uh, and so, but the fact that you can't make it be null or undefined, makes it seem like it's like, okay, well, we do wanna say something about it, but we just don't wanna say that much. And it's like, what is the use case for that exactly? Like, why do we need that? So I would be interested to hear, you know.

• 42:30Speaker 01

  So we have a type for like the case you mentioned, it's called type unknown. It's a built-in type and that's like if you literally don't know what it is.

• 42:36Speaker 02

  Yeah.

• 42:36Speaker 01

  And then you basically have to like validate our runtime.

• 42:39Speaker 02

  Yeah.

• 42:40Speaker 01

  What it is, because we just don't know. We don't want you to just be like accessing an object if it's not an object or something.

• 42:45Speaker 02

  And this is definitely not that, because you can't make it be null. Like, you can't decide that it's, oh, it's just not anything, right? You know, so, so I don't really know, this is pretty interesting. I'll be interested to see the YouTube comment on that.

• 42:54Speaker 00

  I, we did get one comment in chat, which it does seem at least plausible. Thanks, uh, Speon669. Uh, null and undefined throw when you attempt property access. So that's what I was wondering, cause I think you could, you can do like 42 dot length, right? Or, or not length probably, but like 42 dot two string, right?

• 43:13Speaker 02

  Right.

• 43:14Speaker 00

  Or something like that?

• 43:15Speaker 03

  Oh, constructionally it's an object still. Oh, its prototype is still an object at the tippity top.

• 43:20Speaker 01

  Yeah, okay.

• 43:21Speaker 00

  Right, is that it?

• 43:22Speaker 01

  I can buy that.

• 43:22Speaker 03

  Oh, I don't know if that is.

• 43:23Speaker 01

  I can buy that, I don't know if that's right, but I can buy it.

• 43:26Speaker 03

  I don't buy it, I, now I'm getting, I'm confused.

• 43:28Speaker 00

  Well, it's only worth what you'll pay for it, trash.

• 43:31Speaker 01

  It seems plausible. Let me ask my man Claude. Let's see if he agrees. Cause I would have said.

• 43:35Speaker 02

  Of squirrely grace would be true. So far, this one is the first one that really does seem to earn a WTF legit. Like no, like, I don't know, man, like WTF.

• 43:47Speaker 01

  If you see this in code, like, probably just be like, don't do this.

• 43:49Speaker 02

  Okay, yeah.

• 43:50Speaker 01

  Have like a good reasoning.

• 43:51Speaker 02

  Alright.

• 43:51Speaker 01

  I don't know. Okay, hold on, let me see where we have. I know we're getting short on time here. I want to.

• 43:57Speaker 00

  We're never short on time for you, brother. Like, take as much time as you want.

• 44:00Speaker 01

  It's true. This is one thing I wanted to show Casey. So this isn't actually like weird type stuff, but this is a Doom in TypeScript that my friend Dimitri did.

• 44:09Speaker 02

  Okay.

• 44:10Speaker 01

  So this is what it took for him. You're gonna see what, I mean, I'm not sure. Are you familiar with this or no?

• 44:16Speaker 00

  He doesn't know. He doesn't know.

• 44:17Speaker 01

  You know, okay, this is perfect.

• 44:19Speaker 02

  Trillion lines?

• 44:20Speaker 01

  So with three and a half trillion lines of code, which is about 177 terabytes, with 12 days of running said code through a type checker and just being like mentally ill, this is what you're gonna get in TypeScript. You're gonna get the first frame of Doom rendered in TypeScript.

• 44:39Speaker 02

  So this is someone doing.

• 44:40Speaker 00

  Types.

• 44:41Speaker 02

  Types. So this is, okay. I see. So this is someone who basically said, look, is TypeScript's compiler Turing complete? And the answer was yes.

• 44:49Speaker 01

  Exactly. Literally. Yeah, exactly.

• 44:50Speaker 02

  And they were like.

• 44:51Speaker 01

  Funny thing is, at render, someone was doing TypeScript is Turing complete like a couple hours before mine? And we both referenced this. I was like, dah! Like, fell to my knees. I'm just kidding. But I was just like, oh, man. Oh, I'm a fraud. I'm a fraud.

• 45:08Speaker 01

  The last thing, last thing, I kind of want to show you something else after this is you can do math in TypeScript. Right? So if we see like type foo, sum, we pass in 13, 21, we get 34 because math, right? What I really wanted to show like the audience was like, what does the resulting type look like? And this is how you accomplish this. So this is one of the cleaner implementations. Shout out Team Chong. I think he's like very popular in the open source community. So this is like, and it's gonna scroll. So you go like this. And this is what you get if you want to submit. Some in TypeScript. Ideally, no one does this, like it's more just like pushing the limits of TypeScript, seeing what is possible. Like people have done like bubble saw and all this stuff. Yep.

• 45:52Speaker 01

  But it's just like crazy what you can do in the type system. So like I got really addicted to type challenges, which is like basically lead code for types. So like I absolutely just like, I got tired of like, I never was like a big lead code person. But I did do it because like if I was interviewing. But when I found out about like type challenges where you can basically do type challenges like this, I got like addicted for like a year. And I just like went through like almost like, not like all of them, because they get like pretty big brain. But I've I did like a hundred plus and I just got, this is like what kind of unlocked TypeScript for me. I was very much of like a.

• 46:25Speaker 01

  I would say just a normal application developer using TypeScript, you know, just doing type like basic type declarations. But then once I do it, started doing these like challenges, like I just completely unlocked like a different like avenue in my brain. I was able to just do like gnarly stuff at the type level. And it was very helpful because I was helping with like libraries at work. I write libraries and doing this allows me to like, give the quote unquote best, best deliver, the best developer experience to like my consumers, right? Um, you don't have to do stuff like exactly at this level, but you do like pretty insane stuff that looks like spaghetti code and you can't read. So, um, there's one thing that I think Casey's gonna appreciate, which I glossed over in this, and this is TypeScript performance.

• 47:10Speaker 01

  So sure, you see all this code.

• 47:14Speaker 01

  But let's, this is a very real scenario that I'm experience experiencing now as we speak. Let's say, let's imagine we have a huge monorepo that has tons of, tons of contributors. You have potentially some code gen, you have a lot of like user generated types. But now, when you're doing your, when you're working on codebase, right? So this is me working in my codebase, let's imagine. This auto suggestion taking like 10 seconds to appear.

• 47:45Speaker 02

  Oh.

• 47:45Speaker 01

  Right? Or let's imagine your build taking 10s of like, you know, like 15 plus minutes to just compile types, right? And that's like a very real scenario and it's a good, it's a scale not many people hit depending on like, I don't know, the work they're doing. So being able to fix these performance bottlenecks is actually like black magic. I think there's maybe, I'm just gonna, this is just my general observation, but I think there's maybe like, I can count on my hands how many people actually know that are probably not on like actual core team that could actually help you debug your like,

• 48:23Speaker 01

  your performance and try to kind of help like build this. So what they give you is with like not really much documentation, you get something like, you get like a tracer and you get these graphs, which I'm sure you're familiar with.

• 48:33Speaker 02

  Yep.

• 48:33Speaker 01

  So what I do is I run this and then I try my best to like figure out where the bottlenecks are. But then even when I find out what they are, it's hard to tell why it's behaving this way. Because when you're looking at types, you need to understand really in depth like, you know, which types do lazy evaluation? Can I make this lazy? How does the caching work at the type level? Like if I do this kind of type, is it gonna cache? To where, you know, I can reuse that and things are performant. So you have to like really dig super deep into these like really obscure things and they're not documented. There's literally nothing really on the internet that can help you get through this.

• 49:13Speaker 01

  So this is like my biggest WTF right now because I asked for help on Twitter because I was like literally like at like my rope's end. And luckily some people like reached out to me, but even then it's just like, I don't know, maybe it's like kind of like guessing at its best. So I'm hoping like eventually like with TS go, we're gonna use that and that's gonna hopefully speed up things. Because with Go's gonna be significantly, I think it's like a 10 times performance gain potentially depending on how your code is written, I guess, or how your codebase looks. So this is like one of the big things I thought you would appreciate is just like.

• 49:48Speaker 01

  I don't know how it's like debugging performance in some of your ecosystems where it's kind of just black magic and you're kind of just like, you just kind of F around and find out because that's basically what I'm doing now.

• 49:56Speaker 02

  Yeah.

• 49:57Speaker 01

  It's like, well, this type looks gnarly. Let me just like, try different things and then run it again and see if it just got better by like, 50 milliseconds. And that's basically my life right now.

• 50:07Speaker 02

  Well, a lot of times what we'll do in those kinds of circumstances when we have like, it's like black box performance operations optimization, right? Where you're like, okay, I need this thing to go faster, but I have either no or very limited ability to, get diagnostics from inside the box, right? Like, so you know, you've got a flame graph here, but I'm imagining, so I kind of implicit in what you were saying, or at least I assumed based on what you're saying. If I were to hover over the parts of this flame graph, it's going to tell me like what function the TypeScript compiler was in, but it's not going to tell me like on behalf of whom. So it's not going to say like, it's because I was compiling this type or because I was compiling this dispatch, I'm assuming.

• 50:48Speaker 01

  So what is going to happen is it's gonna, this one's not showing you exactly, but it's going to give you some line numbers. So you're actually going to have to look at the AST version of your TypeScript code to map like the, the position to like your actual code.

• 51:02Speaker 02

  That's kind of handy though.

• 51:04Speaker 01

  Yeah, yeah. So like, so you have to basically come, look at the ASTs. Even then, it doesn't even map one to one usually from my experience.

• 51:11Speaker 02

  Of course, yeah. It couldn't, right?

• 51:13Speaker 01

  Exactly. But even then, once you kind of figure out where it is, you have a whole nother can of worms on like, now you have to understand at the compiler level, how these types are handled and like, why is this being slow versus like potentially another avenue? And those things are like, not really said at all that I realize doing now that I'm like in this world. So, so this is like, it's not something that many people can relate to until you have to do it, if that makes sense.

• 51:39Speaker 02

  Isn't this, and what size are we talking about here in terms of like? I mean, I'm because I'm guessing there is basically an interplay here. There's the size of the code base, but then there's also like the level of complexity of type things you're doing. So I'm imagining like that thing you showed before that was using like a number of parameters cracker at the bottom. I've seen those, they're used in C and C++ as well to make macros that take different numbers of arguments, for example.

• 52:07Speaker 02

  So I'm guessing that also it depends on how much of that kind of stuff you're doing. Like if the compiler is having to churn through lots of transformations that you've told it to do, like using that kind of type meta programming, basically, I'll call it for now. So is it basically like an interplay of those two things? Like, how much type meta programming do you have? Plus, how big is the code base? So like, how much are we asking it to do?

• 52:30Speaker 01

  Right.

• 52:31Speaker 02

  There's like some weird fuzzy function of like, if you hit too much of both of those, then you're in no man's land, or?

• 52:37Speaker 01

  Exactly. So like in my experience, what I've learned so far is our problem is kind of unique. It's just literally the sheer number of explicit types because we use code gen to generate some stuff.

• 52:48Speaker 02

  Okay.

• 52:49Speaker 01

  But also, it's also like you said, like inference, like if we're having TypeScript try to figure it out.

• 52:56Speaker 01

  When you do that, it really bogs down TypeScript. So what you typically have to do is be very explicit with your types and just be like, this is what it outputs. You don't need to figure it on your, figure it out on your own. Let me explicitly type the return type of this function. And TypeScript will be like, okay, now I don't have to go in and analyze everything. Oh, this is going to output like an object with like these objects.

• 53:16Speaker 02

  Ah, okay.

• 53:17Speaker 01

  Let me just give you an explicit type. And you have to kind of like cast, you do like as and stuff, and that kind of helps as well. But it's kind of just like, yeah, there's like a lot of different quirks you can do.

• 53:27Speaker 02

  So TypeScript has the functional programming, the classic functional programming compiler problem, where there's, it's like a bad exponential if, because you're, since you don't ever have to say what the types are of functions, it's just implied based on what the function does. Then if a function calls another function, calls another function, calls another function, so on, you end up with this permutation of it having to like solve the whole chain and see like, what would it actually be? TypeScript has this as well?

• 53:55Speaker 01

  So, yeah.

• 53:56Speaker 02

  Okay.

• 53:57Speaker 01

  But so check this out, here's like another thing, even outside of this. So let's just assume I have a type file that's like 60 megs big. Like, that's huge, right? Of just TypeScript types.

• 54:05Speaker 02

  Yeah.

• 54:07Speaker 01

  What you now need to do is you now need to slice and dice this file.

• 54:12Speaker 01

  And have it only pertain to like the specific pieces of the code base that. Actually care about it. So right now, especially most people in chat, probably they probably have just like. One big like file or they have some files and they kind of just build their whole project at one time. But when you hit this certain kind of scale, you kind of have to slice and dice your project to only. Care about specific things. So you're not, so you can like. You basically have like a bunch of different processes that take like. Five seconds versus one process that takes like. 10 minutes or something, if that makes sense. So like in the thing with TypeScript, it basically like will. Statically just crawl your imports and look at every file. So like if you had one file that was importing like 10 files, TypeScript, the compiler will go and.

• 54:57Speaker 01

  Go spin out to those 10 files and then those 10 files are most definitely importing something.

• 55:02Speaker 02

  Right.

• 55:02Speaker 01

  So then you just end up with this huge problem. So you have to be very like. Surgical with like how you're splitting everything up because you don't want that to like leak in places as a need to. So like in my, so right now I'm kind of in hell because we have such a big code base. I have to figure out. Where all these little spider webs kind of span out to and kind of try to keep them in their lane.

• 55:23Speaker 02

  Yep.

• 55:23Speaker 01

  Um, so we're kind of hoping like TSGO is going to save us in some aspects, but at the same time, like.

• 55:29Speaker 01

  What happens is when you hit this scale, you have to be very intentional with how you. Format your code base because most people are just like, ah, glob the whole thing. Let's go build takes five seconds because my code base is like.

• 55:40Speaker 02

  Yep.

• 55:40Speaker 01

  Maybe 50 files, but yeah, not the case for me and I'm like feeling that pain so hard.

• 55:45Speaker 02

  You guys reinvented, the, the TypeScript world has reinvented the bad C, C++ compilation situation where you end up having to build all these modules. Oh my God, this is, this is crazy.

• 55:57Speaker 03

  I mean, very few projects get this big. So like to be fair, I mean Netflix is one of the very few companies that are operating on this level. Uh, do, do the, uh, do the LSP still crash pretty regularly? Uh, because I could like, I couldn't get TSG server to work for like a year straight. And I was just like, forget this.

• 56:14Speaker 01

  Slide, uh, I skipped over a slide, but it was like, uh, is this a TypeScript error or is my server dead?

• 56:22Speaker 01

  Let's just restart, let's just restart, just to be sure. Like, I'm at the point where like, I'm just like, eh, is that a hair? Let's just, uh, let's give that boy a restart and see what happens. And that's like the classic TypeScript experience, to be honest. Uh, especially like when you like get into bigger code bases, but man, it is rough.

• 56:39Speaker 03

  Question, is there like a practical kind of set of tools you can give developers to help this problem not scale as fast? Like, I hate ES Lint, generally speaking. Can you throw in some TS Lint that's like, hey, you didn't explicitly type your return function? You must return.

• 56:54Speaker 01

  Yeah, so there's TypeScript ES Lint.

• 56:57Speaker 03

  Has there been a change?

• 56:58Speaker 01

  There's a lot of TypeScript rules.

• 56:59Speaker 03

  Where people are actually doing that at Netflix, or is it still kind of like, you don't have to do that?

• 57:04Speaker 01

  I don't think you do it until it's a problem. I think that's kind of.

• 57:07Speaker 03

  Yeah, but.

• 57:08Speaker 01

  I think, I mean, that's not really unique to us. That's like, everybody, right? It's not a problem until it is. You ignore it and then, and then once it's a thing, you're like, oh, man. I done messed up, but I've definitely like. That's a very human experience, yes. Yeah, yeah, exactly. So like, I'm kind of like slowly trying to tell people what we're experiencing. Like, be like, you know, just be careful, be careful out there. But yeah, it sucks because like, like you said, like Netflix has such a unique scale. We now have to just care about things that no one cares about. It's like, ugh. But you know, that's, that's how, that's how it goes sometimes. But yeah. That's all I got. That's all I got. Thanks, Trash.

• 57:51Speaker 01

  I mean, we weren't like on the script as my talk, but dude, so just to like backtrack to my talk. Like, this was my first big conference talk. And it was at the end of the conference. So it was like three day conference. I was at the last day, almost at the very end. And I was like terrified no one was gonna come, but turned out, dude, I had like a packed out room. People were laughing at my jokes. I felt like so relieved, but beforehand, I was like doing stretches on stage, just trying to calm down. And like, I tried to like meditate. I like just sat there, took like 10 deep breaths. I was like.

• 58:22Speaker 03

  Did you, did you go to the bathroom stall and stand really big? Increased testosterone, do all the like, power stances?

• 58:30Speaker 01

  I drank like 50 bottles of water on stage before my talk and I had to pee so bad. Oh, no.

• 58:36Speaker 03

  Classic talk mistake.

• 58:38Speaker 01

  One thing I'll say is like. I used to like, this was probably like my first conference that was like multi-day. Like I've been to React Miami that I don't think that's as big as like the one I went to. But like the, I don't know, like the support, I never felt like the support from like speaking at a conference before. Cause usually I did like virtual ones because of COVID. And man, it was like pretty eye-opening, like, you know, some of the people you see online, you know, very super nice in person, like I just changed my perspective on the whole thing of just like the community, like of like conference speakers and people that tend to go to conferences regularly. Kind of just like changed my mind, like not, not really about those people specifically, but more of like the community around it. So it was pretty nice. I don't know if I'll ever do it again.

• 59:21Speaker 01

  Cause it was very stressful. Like this was actually pretty stressful for me to do on this podcast, but uh.

• 59:26Speaker 00

  You crushed it, Trash.

• 59:28Speaker 01

  Well, it was nice because there was a lot of back and forth banter. So I made it like all worth it.

• 59:33Speaker 00

  It made it all worth it. I love that.

• 59:36Speaker 03

  I actually think this was, I actually think this was really awesome. Uh, cause I, you know, this is one of those things where unless if you used it, you just don't know about any of them. And I think a lot of people are actually pretty surprised about what's done. I actually, I am going to say you didn't bring up my most hated feature of them all, which is.

• 59:54Speaker 00

  Oh, not this one again, dude. It's literally, just go back and watch the stream, Vaz. If you randomly go inside of it, you'll probably run into him complaining about this.

• 1:00:01Speaker 03

  You can have, you, so you know how you, you did kind of briefly kind of get close to it? You know how you had number and or, or undefined?

• 1:00:08Speaker 01

  Yeah, let me switch my camera. So you can go like a river.

• 1:00:11Speaker 03

  You're on full mode right now. You're full screened. We're not changing it.

• 1:00:13Speaker 00

  Oh, big trash.

• 1:00:14Speaker 03

  Big trash. You know how you can have like a number or undefined, or you can do number or string that's an array?

• 1:00:20Speaker 01

  Oh, I've seen, I've seen you talk about this before.

• 1:00:22Speaker 03

  Into a function that only accepts string arrays.

• 1:00:25Speaker 01

  Yeah, yeah. I saw you, I saw you talk about that.

• 1:00:28Speaker 00

  Trash, pull it up on the TypeScript playground thing and we'll show Casey.

• 1:00:31Speaker 03

  Yeah, pull it up here. I can send you a code example if you need me to. This just blows.

• 1:00:35Speaker 01

  Just give me a, give me some pasta.

• 1:00:36Speaker 03

  Yeah, yeah, yeah. Here. I find this to be such a funny thing.

• 1:00:41Speaker 02

  Prime's cooking the pasta. He's, he's boiling the water.

• 1:00:44Speaker 00

  Boys.

• 1:00:45Speaker 02

  He's in the kitchen. He's cooking up some tasty pasta.

• 1:00:48Speaker 00

  Salt the taste right now.

• 1:00:49Speaker 01

  Why are you sharing your screen?

• 1:00:50Speaker 03

  Uh, just because I don't have it set up and so we're not gonna do it. Alright.

• 1:00:55Speaker 00

  Trash, this is your presentation, even if it's Prime's example, okay?

• 1:01:00Speaker 01

  I don't remember the example exactly, but I remember watching a stream where he was like, what is this? And I feel like he's brought it up like 10 times.

• 1:01:06Speaker 03

  Just cuz I.

• 1:01:06Speaker 00

  That's what I'm saying. That's exactly what I'm saying. I've heard it a hundred times.

• 1:01:11Speaker 01

  If he's trying to get TypeScript, he brings it up, literally.

• 1:01:13Speaker 00

  Yeah, he's like, "Oh, are we talking things I hate about TypeScript? Oh, I've got one in the back pocket." If they fix this in the compiler, Prime is done for.

• 1:01:23Speaker 02

  Right, that's the end of his streaming career. That's it. It's like, there's no go-to anymore. There's no go-to.

• 1:01:28Speaker 03

  Yeah, they can't, they can't fix this because it's not, it's not a thing. Right?

• 1:01:33Speaker 00

  Oh, that's what you think.

• 1:01:34Speaker 03

  It's a, I ran into this with logging. So when I was doing a bunch of logging, this is what got me. Was during a logging day, working through a bunch of logging and then, um, it just, I just got, I just got really sad, you know? Um, here you go, Trash. I'm not sure how to send this to you. So I'm gonna send it to you via Twitter DMs.

• 1:01:55Speaker 02

  Whoa.

• 1:01:56Speaker 00

  Wow.

• 1:01:56Speaker 03

  I don't know, are we friends? Oh, we are friends. We are friends.

• 1:02:00Speaker 00

  Make a gift.

• 1:02:01Speaker 03

  I know, but then I have to go to gisting and then I have.

• 1:02:02Speaker 00

  Places where we're talking with them.

• 1:02:04Speaker 01

  You can, you can also just post in the.

• 1:02:05Speaker 03

  Yeah, I'll, I'll post it in the stand-up. Uh, there you go.

• 1:02:08Speaker 01

  My Discord is updating. It's gonna take forever.

• 1:02:11Speaker 03

  They, they're compiling types.

• 1:02:13Speaker 01

  Also remind me, also remind me to close Discord before I share my screen.

• 1:02:17Speaker 00

  Smart.

• 1:02:17Speaker 01

  I am notorious for leaking everything in.

• 1:02:19Speaker 03

  I am too.

• 1:02:20Speaker 00

  Discord probably was watching this. They probably just updated all their TypeScript to fix the problems you were saying, so they had to just update.

• 1:02:26Speaker 01

  They're like, "We're on it. They're watching it right now, just like really angry."

• 1:02:28Speaker 00

  Yeah, that's what I'm saying. They're like, "Oh my goodness, he's so right about enum's. Get those out of here."

• 1:02:32Speaker 03

  Dude, they've been around for so long, enum's. And the worst part is that when you do, when you, when you first start off on TypeScript, your first thought is, "Enums are the right choice because this is what I want." And it takes you forever to discover you've been using them wrong. I feel like that is by far one of the biggest WTFs of all time.

• 1:02:50Speaker 01

  Alright, what are we looking at here? Actually, don't remember.

• 1:02:52Speaker 03

  Okay, just look at it. What is food?

• 1:02:54Speaker 01

  Now I'm looking at it.

• 1:02:56Speaker 03

  Okay, what is bar taken?

• 1:03:01Speaker 01

  Oh, an array that has number or string.

• 1:03:02Speaker 03

  Yeah, and what do you pass into bar? A string array. And what does bar do to the array? Pushes a number.

• 1:03:09Speaker 01

  Oh, that's right. I see, yes, yes, yes.

• 1:03:11Speaker 03

  It could screw you!

• 1:03:13Speaker 00

  Trash, give, Trash, show us the type of bar afterwards.

• 1:03:16Speaker 03

  Yeah, what's the, what's the type, yeah, what's the type of, or what's the type of foo afterwards?

• 1:03:19Speaker 00

  I mean, the result of bar foo, you know?

• 1:03:23Speaker 03

  Well, you don't assign anything.

• 1:03:26Speaker 01

  Oh, shoot.

• 1:03:26Speaker 00

  Right, so it's still just string array the whole time?

• 1:03:28Speaker 03

  Yeah, it's just string array. And that...

• 1:03:32Speaker 03

  Yeah, well, foo does, it doesn't return anything.

• 1:03:35Speaker 01

  Oh, sorry.

• 1:03:35Speaker 03

  Yeah, yeah, you can just look at foo, though. Like, what is foo? Foo should be a set of strings, because then you afterwards could have a function that, say, calls contains, or includes, or whatever it is, on the array. And the array now has something that doesn't contain that function, and will explode, and will fly under the radar.

• 1:03:53Speaker 01

  So this has happened to you, like, in your life?

• 1:03:54Speaker 03

  Yeah, it happened to me on Netflix when doing the gaming stuff, for logging. Because we have, like, we, we, we have such a crazy logging thing, that if you look on my GitHub, there's a project called undefined, where I take a, I take, like, 1 million query results from Mongo, this is back when we had Mongo running all gaming. It took a million query results from Mongo, converted all of those into types, and then figured out all the unions to reduce all the types. We had so many different types, that some of the types were kind of goofy, so you had to, like, you knew you were gonna be these collection of various unions, and so I'd do something to the union, or have functions that take in subsets of the unions, not realizing it was actually even a stricter subset, and then would, you know, it was just very, very difficult. And obviously, this was a problem of my own making.

• 1:04:37Speaker 01

  So what did you do here? Are you just, are you just, did you end up just programming defensively?

• 1:04:40Speaker 03

  Everything, yeah, yeah, you just have to, you just had to be...

• 1:04:42Speaker 02

  Can I ask a remedial question here?

• 1:04:45Speaker 03

  Yeah.

• 1:04:47Speaker 02

  What is const doing there? Because you're pushing something onto it, so it's obviously not const.

• 1:04:53Speaker 03

  Casey, you just hit the funniest argument of all time in JavaScript.

• 1:04:58Speaker 01

  Welcome to JavaScript, buddy.

• 1:04:59Speaker 03

  Yeah.

• 1:05:00Speaker 02

  Yeah, that, that's why I said remedial, because I'm like, I'm sure this is something that's, that's come up before, but like, what, so what's the deal?

• 1:05:06Speaker 01

  You just can't change, like, it's reference, but you can change, you can mutate it directly, right?

• 1:05:12Speaker 02

  So is there any way, is there any actual, like saying that the contents are const? Or can you only const just the reference?

• 1:05:22Speaker 03

  At the JavaScript level.

• 1:05:23Speaker 01

  JavaScript, if you want it to be like purely frozen, you can do object freeze. And if you want to do it at the type level, you can do like as cons.

• 1:05:28Speaker 03

  Can you do object freeze on an array?

• 1:05:32Speaker 01

  Pretty sure. I don't, I haven't used object freeze in like forever.

• 1:05:37Speaker 02

  And, and that would mean that now it would be an error. If anyone tries to push, it'll just be like, you can't.

• 1:05:42Speaker 01

  There you go. Yeah.

• 1:05:45Speaker 03

  But you can still, but you can still push a frozen array into a function that mutates it.

• 1:05:50Speaker 01

  Well, I guess not. So wait, does this return something? I haven't used freeze in a while. Does this actually return something?

• 1:05:57Speaker 02

  It returns a new item.

• 1:05:58Speaker 03

  It turns a read only one. There you go.

• 1:06:02Speaker 02

  Okay, so a is the thing we can't push.

• 1:06:04Speaker 01

  There you go.

• 1:06:05Speaker 03

  Yeah, can you pass a into bar?

• 1:06:06Speaker 02

  And like, what's the error? What does the error say? Just so I can see.

• 1:06:11Speaker 01

  Does not exist on read only string.

• 1:06:13Speaker 03

  Can you push a into bar or can you put a into bar? I can't remember if that's a thing you can do.

• 1:06:19Speaker 01

  Can I put?

• 1:06:20Speaker 03

  Can you call bar with a? I can't, no, just call a or call bar with a. Okay, nice, nice. Okay, so the read only does go that direction. Perfect.

• 1:06:30Speaker 02

  Okay, so you can, you can cons, it's just, it's not that particular, it's not that particular syntax, but.

• 1:06:36Speaker 01

  That works.

• 1:06:37Speaker 02

  There is a.

• 1:06:41Speaker 03

  WDF, that works, I don't know.

• 1:06:44Speaker 01

  I actually didn't think that was gonna work, but.

• 1:06:47Speaker 03

  Well, hold on, Trash, was the LSP broken or was it an actual error?

• 1:06:54Speaker 03

  Write it back, write it back.

• 1:06:55Speaker 01

  I know, exactly. Let me refresh the browser. I don't actually know. Oh dude, we just lost it. Okay, it's gone forever. I'm not typing that again.

• 1:07:03Speaker 02

  So, can I ask another question here? So I'm assuming that this is not really, like, I'm assuming that this example is.

• 1:07:12Speaker 03

  It's rare.

• 1:07:14Speaker 02

  Well, I was gonna say, it doesn't even need to have as many moving parts, right? Cause like, maybe it does. So before you had a way of typing things, like, so can you put number or string up in the original definition? So it's const foo, colon, number or string, and then the thing?

• 1:07:33Speaker 02

  As well?

• 1:07:35Speaker 01

  So you want me to do this, right?

• 1:07:37Speaker 02

  No, I was just curious. So we can say whichever types we want. So, okay, so my question is... No, sorry, you don't have to... No, you don't have to do that.

• 1:07:43Speaker 01

  Oh, okay.

• 1:07:44Speaker 02

  So, would the push work even before you pass it to a thing? So if you said const foo string and you pushed 3, just with it in full sight of the fact that it was only supposed to be strings, what would happen?

• 1:08:00Speaker 01

  So you're saying, can I do foo push 1?

• 1:08:02Speaker 02

  Yeah.

• 1:08:03Speaker 01

  Oh, that should definitely work. That should definitely break.

• 1:08:06Speaker 02

  Yeah.

• 1:08:09Speaker 02

  Very interesting. Very interesting.

• 1:08:14Speaker 02

  Alright.

• 1:08:14Speaker 01

  Yeah, the problem is, it just can't narrow it down.

• 1:08:17Speaker 02

  Yeah.

• 1:08:18Speaker 01

  You're passing something down.

• 1:08:18Speaker 03

  It's like rectangles and squares, right? Foo's a square, number... Bar takes in a rectangle.

• 1:08:26Speaker 02

  This, to me, seems like a legit compiler bug.

• 1:08:29Speaker 03

  It's not.

• 1:08:30Speaker 02

  To me, because... But it does seem like one, because in this case, if what we're basically saying... Because in order for this to make any sense logically, right? What we're saying here is that the or is not a type definition, meaning it's not saying that I only accept number or string types, which is, A, probably what it should have been, based on how it's compiling. So, it's compiling this as if what you said was, "I will take only things that support number and string", not either or, but, you know, it can support both. But then what it's doing is it's actually accepting either. So it's compiling as if it's and, and accepting as if it's or. That just seems like a straight-up bug.

• 1:09:15Speaker 02

  So I'd love to see someone justify that, because I don't buy that. There's two ways you could have made this work. One is the first way, which is you say, "That's an actual requirement." So if you tried to pass the string one, it would just error and say, "No, I only accept number or string types." And then the other one would be, when you actually make the call, if it's do... If it actually was supposed to be more like a template where it says, "I'll accept either or of these", then it should have done a compilation error check on that function as if it had just said "type of string", which it definitely didn't do, because it would have given you an error on the push. Right? So, I'm saying, I'm calling this a bug. This, this is a bug.

• 1:09:58Speaker 02

  Youtube comments, "I will fight you next time on this." This is a, this is a bug. You should, you should have picked one of, one or the other to do. And if you did neither, then it's a bug.

• 1:10:07Speaker 03

  Hey, guess what TJ? I told you it was a good piece of content. TJ's over there being all upset at me for bringing up my favorite thing. Being like, "Oh, here's Prime bringing up his classic thing." This is great, because I knew Casey would be like, "What? I don't get this. What the heck's happening here?"

• 1:10:21Speaker 02

  I'm right there, I'm right there with you. There, because there, there were two ways you could have done this correctly, and they chose neither. So like, I want, like, I would be impressed if someone in the Youtube comments can convince me that this is not, like, just a bad design. That this is not just a bug in the way you've defined the, like, this is just a bug.

• 1:10:40Speaker 00

  Here's why they can't fix it, is because it, uh, it would make JavaScripts, that it would just break everything that they've already done in JavaScript world. That's the main reason.

• 1:10:51Speaker 03

  That's a good answer, by the way.

• 1:10:52Speaker 00

  It's that they had to make TypeScript incrementally adaptable for JavaScript, and that's, I think that's why.

• 1:10:58Speaker 02

  I don't see, I don't see why, I don't see that explanation being valid here.

• 1:11:02Speaker 00

  It doesn't look so, so in this case, the main problem is that there's no way to say whether something is going, there's no mutability access in the type system for TypeScript, right? So there's no way to say, like, for, well, there is, but like, not when you're writing it this way. There's no way to tell you, "Actually, I'm going to mutate the array that I'm passing." So like, in a normal case, what you're saying is if this function takes numbers or string arrays, that's fine. It, it does successfully handle that case. That function does not break any promises of its function signature or its return type. The problem is there's a separate access, access of, it has mutated that array

• 1:11:43Speaker 00

  to now basically, um, upgrade, or like, mutate the type itself. It now took something that was, you know, possibly a number array or a string array, and turned it into either a number array or, number or string array. But that's not tracked in the type system at all. I don't know why, Crash. Hold on, I'm coming back.

• 1:12:01Speaker 03

  I know, don't worry. I've switched to grid, so at least we don't have that as a full thing. But this is good, this is great.

• 1:12:06Speaker 02

  No, but like, I went through the different cases and I had, and trash typed them in. We saw, literally, that the compiler can go, "Oh, if I have something that's declared as only a string, as only an array of strings, and I try to push one, it will error," right? Now, what that says to me is that it actually was, it has the logic for looking at push and saying, "If it's a string, I can't do it." So when you called, when someone called that function, and you said you passed a string, what it should have done is do the type checking on that function at that time. At the dispatch point, right, this is how template compiling works in C.

• 1:12:48Speaker 02

  At the dispatch point, to go, "Could I actually have this function evaluate with this type?" And the answer is clearly no, even if they run the code they already have in the compiler, because we saw it error on the push code. So this is a bug in the compiler. It should have done that type checking and it should have done, like, again, this is my first time seeing TypeScript, so maybe I'm missing something, but like, no, from what I saw, this is a bug. This is a bug that should have been fixed. Because you should have done at the dispatch point, and you should have gone, "I'm instantiating one of string, I'm effectively instantiating a version of this function call that would be used for string." And I don't have to actually instantiate a new version of the function, I just have to do the type checking for that function, and it didn't do that. It should have done that.

• 1:13:32Speaker 02

  So, so fight me, fight me, YouTube.

• 1:13:35Speaker 00

  I would love nothing more than this bug getting fixed and never have to hear Prime talk about this on another podcast or stream or video again. So you're preaching to the choir big time. If there's a way that this can get fixed, I will be so happy. I will stand TypeScript for months. I will say it's a great programming language, I will say...

• 1:13:54Speaker 03

  TJ's positivity arc already ended. It's already gone.

• 1:13:58Speaker 02

  Well, let me, let me just illustrate, like, just to be clear, like, what I'm talking about. So I'm trying to make a mental model of the compiler in my head, right?

• 1:14:04Speaker 00

  Yep.

• 1:14:05Speaker 02

  So, when I define a function, right, I'm gonna have a function, and 99% of the time, that function is gonna have an explicit type, let's say. So it's gonna say like, "I take," like he had before, "I take person, I take type person," right?

• 1:14:19Speaker 00

  Yep.

• 1:14:19Speaker 02

  And so in that case, you can just type check the function at the time when you're actually just looking at the function. In other words, there's only one type check that only has to happen for this, and that is the type check for the type that it said it took. But as soon as you have an or in there, then what the compiler should have done is it should have said, "Okay, I don't know how this will be called yet," right? Because now, one option is we could type check all permutations: string, number, and string or a number. But the problem is, as you add more of those, you could get into a thing where it's like, "Okay, we're in factorial land," and then your compile time blows up, so you wouldn't do that. All you would do is say, "Okay, I'm gonna defer type checking of this function. I'm gonna defer it until it's called," right? That's what you would do.

• 1:15:04Speaker 02

  You could still run a type check on it if you just wanna run a type check to see if it ever could do it, right? Meaning, you could do the inclusive type check of like, all possible things if you want to. You could do that if you want to, I don't care. But point being, we should put it aside and say, "Okay, here's the," like, effectively like it's a template, "here's all the things that could have been called as, we're just gonna remember those," right? Then, as it goes through call points, what the compiler should do is look at the call point, it should go, "Okay, do I have a cached type check for this type signature that I'm about to dispatch?" right? If the answer is yes, then I don't need to do anything, because I've already outputted the errors, or not any errors if it was correct. If I don't have a cached version of that type combination that I'm passing in, I need to do the type check now.

• 1:15:48Speaker 02

  I do that type check, and if it's an error, I put the error on the dispatch point, right? And I say, "In vocation of this would have created an error at this line in the function." Meaning, the push would fail, because it's pushing an integer, and I only had a string array, right? That is what the compiler should have done. You would then put that in the cache, so you'd never do it again, so it's not a performance penalty to do this, right? But that's how you would do it. And so if they're not doing that, I would argue that's a bug. And someone would have to explain to me why that compilation process I just described somehow creates some unworkable situation that simply won't allow us to create JavaScript anymore. Like, like you were saying, like, if there's a... I'm totally willing to believe there's something I don't know that's that. But of the things I've been shown, there's no reason that compilation model wouldn't work.

• 1:16:33Speaker 02

  So I would consider it a bug till someone explains to me what the secret thing is that makes this not possible. Does that make sense?

• 1:16:40Speaker 00

  Well, the code still runs. It's that TypeScript now lies about its types. Right now would be the thing. So I'm, I'm okay with saying it's a bug in the sense like the TypeScript compiler, right?

• 1:16:55Speaker 02

  Yeah.

• 1:16:55Speaker 00

  It needs to either update its type or say, hey, this type is actually like, becomes expanded afterwards.

• 1:17:02Speaker 02

  No, it doesn't need to do that at all. It just needs to output the error.

• 1:17:06Speaker 00

  Yeah, it would be fine in, in the case where we're explicitly typing it with saying string like array at the beginning. But like I'm saying, TypeScript's design is not like, has to have been from the start. And maybe like they could release TypeScript 6.0 and change their mind about it because now it's a very different situation. Was like code that runs in JavaScript, like they want it to still kind of be able to run in TypeScript land, right? Like you can still in array.

• 1:17:33Speaker 02

  But it will. Everything I just said, like literally nothing happens to the TypeScript compiler at all. Except that if you pass something that wasn't a type that could make this function compile normally, then it, then it will produce the error, right? So it's literally just asking for that error to be produced when you use a dispatch that would have been illegal. It's not asking to mutate any types.

• 1:17:58Speaker 00

  Yeah, but it's not. I think like dispatch is probably, I don't know. I, I think like, I don't know, maybe like in this case, they could solve this one. But I don't think, uh, like exhaustively, they can, they can solve this like problem. Because sometimes this works, like it's, if they didn't, if they didn't, they would have to then, okay, sorry. I, there's nothing in the type. Like for the function, there's nothing in the type for the function that says it mutates this. So i- if you're like, it needs to get expanded out like a template and then they could check everything if it works. That would like, Trash is saying TypeScript compiler doesn't scale for them.

• 1:18:41Speaker 00

  Like, I promise you, it is doing a lot of things to avoid getting to like anywhere close to the situation where you're talking about right now. It is not a tenable option for them to like make it look or act like a template. Like if it's, if it says it takes these things in as the type, then like that's what it has. I don't, I don't know if that makes sense or not.

• 1:19:04Speaker 02

  I mean, it, it kinda does, but I mean, I'm just saying that the,

• 1:19:09Speaker 02

  in the, in the worst case scenario, then really all you're going to get is a few more compiles of this. I, I mean, okay, so I guess what I would say is, it sounds to me like TypeScript already is not providing a, some kind of guarantee on compile time.

• 1:19:27Speaker 03

  There's not generic, the thing you're thinking of is you have this like generic picture in your head that doesn't exist. There's only one function that ever exists. And so it doesn't actually have a string version of the string number or a number version of the string number. It just.

• 1:19:40Speaker 02

  But it's not, I'm, I'm not asking it for it to change the code. I'm just saying it could just run it to type check. It just has to run the type.

• 1:19:47Speaker 00

  I see what you're saying, Casey. Like, I get what you're saying. Cause you're saying like, if this was, if we imagined this more like how templates work, in the sense that like it's duck typing, I wanna see, does this work for a number array? Does this work for a string array or does this work for a number or string array? Like, I get what you're saying there and you're saying, hey, if you passed in a pure string array, this should error because we're now gonna push a number into it. And now you're lying about the type.

• 1:20:11Speaker 03

  Yeah, the type expanded effectively internally.

• 1:20:15Speaker 02

  Yes. Well, I'm not really saying that explicitly. All I'm trying to say is, the existing compiler that they have already does this error checking. So, another way to say this would be, let's suppose that what you were saying was a legitimate defense of this behavior. If that was the case, then the .push1 that Trash put in should have worked. Because your argument here, right, is that, "Well, I don't want to handle expanding types. I just want to go like, okay, if it was in JavaScript, it should work. So, the push1 should have worked everywhere." But the fact that the push1 didn't work on something that it knew was a string is misleading to the programmer, because now it's telling the programmer

• 1:21:00Speaker 02

  that what this thing does is it type checks the type you have against the functions that you're calling on that type. And then when a programmer goes and passes a string type to this function, they very clearly would expect that function to run the type check, which would have .push1 fail. Because there isn't any additional analysis that it needs to do. It's the exact same analysis it was already doing on the push1 before. So what I'm saying is, literally, they don't even have to do any new work. They don't have to check any different types, nothing. All they have to do is, when they have their or operator for types, they just have to remember, "Okay, I should store the fact that I haven't type checked this function completely yet."

• 1:21:45Speaker 02

  That's it. So I'll do one type check on it, which is the one I'm already doing. The compiler stays the same currently. But I record a little thing into my table of... Because, you know, it's got a table of functions and their types. That's the only way it can do any of the rest of the type checking it's about to do. So I have a table of functions and types. Every time I see someone call one, what I should do is rerun the type checker. Now, if you're worried about compile time, you could have a flag to turn this off. If you're like, "Don't check my dispatches," right? You could do that if that's what you want. But presumably, the only reason people are adding all of the compile time overhead of TypeScript in the first place is because they wanted the type checking. So what you should at least do is have a thing that every time you have a dispatch, you go and look, "Have I type checked this version of the dispatch?" And if you haven't, you just call the type checker.

• 1:22:31Speaker 02

  It will literally just work. Like, that's all you need to do is just have a little cache of what type combinations have you type checked? That's it. There's no Nor code generation, nothing. Like, it's the exact same compiler otherwise. It just calls the type checker on more permutations. That's it.

• 1:22:47Speaker 03

  No, I think, I understand what you're saying. Uh, but unfortunately, we are actually out of time for this episode. We got, we, we have to shut this down.

• 1:22:56Speaker 01

  This was a long one.

• 1:22:58Speaker 03

  Thanks, Trash.

• 1:22:59Speaker 00

  I'll come back, Casey, with, uh, with a research.

• 1:23:02Speaker 01

  I was enjoying the banter. I was just admiring the discussion.

• 1:23:05Speaker 02

  I'm going hard on this one, cuz I want, I want an actual explanation from somebody who could, who could tell me why we can't do this. Like, let's go do this in the compiler tomorrow. That's the stream. We add this type checker.

• 1:23:16Speaker 00

  Oh, I love that. There we go.

• 1:23:18Speaker 02

  Right?

• 1:23:18Speaker 00

  I would love to get it fixed. That would make me happy.

• 1:23:20Speaker 02

  This is doable, people. This is doable.

• 1:23:22Speaker 00

  Yeah.

• 1:23:22Speaker 02

  This is doable out there. Let's do it.

• 1:23:25Speaker 03

  Yeah, I mean, I, yeah.

• 1:23:26Speaker 00

  I love this.

• 1:23:27Speaker 03

  We can't add anymore. I love you, Casey. Love you, Trash. Love you, TJ. Well, like you, TJ. You're always insulting everybody over here. Uh, insulting me on my type script tag.

• 1:23:37Speaker 00

  Happy things today. What?

• 1:23:38Speaker 03

  Though, hey, Trash, appreciate the talk. Thanks for taking the time.

• 1:23:43Speaker 00

  Thanks, Trash.

• 1:23:43Speaker 03

  That was awesome. By the way, this is actually pretty fun. We should do this again, cuz the idea of having a presentation where we can stop and interrupt is actually pretty cool.

• 1:23:52Speaker 00

  You did awesome.

• 1:23:53Speaker 01

  I really appreciate that you all stopped and we started having discussions, cuz it'd been really awkward if I was just talking.

• 1:24:00Speaker 01

  Cuz I can't see anything. I'm like, was that good? Was that funny? Did you like it? I don't know.

• 1:24:05Speaker 02

  Let's go fix the TypeScript compiler.

• 1:24:06Speaker 03

  Let's not fix the TypeScript compiler. It will be a lot harder than you realize it will be.

• 1:24:13Speaker 02

  Yeah, I'm sure. I don't necessarily wanna look at the code, but... But we can do this. This is doable. This is doable.

• 1:24:20Speaker 01

  I believe in you, Casey.

• 1:24:22Speaker 03

  Uh, yeah. Casey, you got this, Casey. All you.

• 1:24:26Speaker 02

  All right. I'll go download it.

• 1:24:28Speaker 01

  That was fun, though. That was fun.

• 1:24:30Speaker 02

  Love the presentation, Trash.

• 1:24:31Speaker 01

  Thank you, thank you. It was fun. It was fun. I enjoyed it.

• 1:24:34Speaker 03

  All right. I am raiding out right now. I'm going to... Why do we have to end? Because I have a meeting that I have to go to now.

• 1:24:42Speaker 03

  So.

• 1:24:43Speaker 00

  Big boy thing.

• 1:24:43Speaker 03

  Bye bye everybody. Bye bye bye bye bye bye bye bye.

• 1:24:47Speaker 00

  Thanks, thanks for asking everybody.

• 1:24:48Speaker 05

  Boot up the day. Vibe code. Errors on my screen. Terminal coffee. And hair. Living the dream.