Matt, the clock starts Now When a newcomer says TypeScript sounds like a lot of extra steps. Why should I bother? What do you say? If you want your integrated development environment to be more powerful, you should use TypeScript. If you don't want it to be as powerful, you should use JavaScript. Perfectly fine if you don't want a powerful IDE.

you should use JavaScript. Perfectly fine if you don't want a powerful IDE. But now with AI agents, now with everyone rushing to make their ideas powerful as possible, TypeScript is just like a no brainer. Makes sense. So you've talked TypeScript to thousands of developers, including many live workshops. What's a typical aha moment that you see it click for? Learning people, learning TypeScript? Honestly, it's the error flow.

Learning people, learning TypeScript? Honestly, it's the error flow. It's literally the feedback you get from TypeScript that goes, okay, there was a runtime error and actually we trace the runtime error. We see okay, it's erroring in the browser and we go all the way through and ah, there's literally a red squiggly line under the line of code that caused the error in the browser. Why didn't I pick that up?

of code that caused the error in the browser. Why didn't I pick that up? And dozens, I mean, thousands of companies now are thinking exactly the same way that TypeScript is just preventing runtime errors. That's what it's for and that's what it's doing all over the world. What's the most common misconception about TypeScript? I think the most common misconception is that it's type safe.

I think the most common misconception is that it's type safe. You know, like I'm not sure TypeScript is as type safe as people think it is. And really it's not supposed to be putting just types in the language just for the fun of it. It's really supposed to just give you a better IDE experience. Without TypeScript you wouldn't have things like

to just give you a better IDE experience. Without TypeScript you wouldn't have things like auto complete, renamed symbol, and go to definition inside your IDE. Your IDE would be much less powerful. So think of TypeScript as enabling your IDE to get more powerful instead of making the language more type safe. Right on. Uh, what is one power up TypeScript feature that more people should learn

Right on. Uh, what is one power up TypeScript features that more people should learn sooner in their learning journey? I think people should be aware of generics earlier in their journey. Okay, now if you are building like an application or you're migrating from JavaScript, then generics is actually gonna give you a really like healthy experience working on the utility functions. 'cause if your utility functions, the things

healthy experience working on the utility functions. 'cause if your utility functions, the things that reused across your app aren't up to shape, then the rest of your application is not gonna be as type safe and you're gonna have to do more work. So if you learn generics a little bit earlier in your development process, you'll have a much better time building applications. That's a great tip. I'm gonna brush up my generics knowledge.

That's a great tip. I'm gonna brush up my generics knowledge. Do you personally use TypeScript on personal projects? I use TypeScript every single possible place I can. Do you write types first when you build something as in sort of like a TDD or schema driven development approach? Great question. So I always pretty much write my types first and often I end up creating what are called typed holes in my system.

first and often I end up creating what are called typed holes in my system where you basically just create a function, you give it a um, parameter types and the return types and then you implement it later. This means you can think at high level first think about what the shapes of the data are going to be and then especially with an AI that's just able to sort of like spool through and add the implementation, it makes things a lot easier.

of like spool through and add the implementation, it makes things a lot easier. So types first, runtime second is often how I approach it. That's great. I love what you said about ai, it makes total sense to embrace that. Where is your personal limit on where it needs to be? Type safe type safe. CSS. Yeah, so like type safe tailwind CSS for instance. You know, like type safe on every single class name. You basically don't need it.

You know, like type safe on every single class name. You basically don't need it. I think like as long as you have the VS Code extension where you have the nice auto complete, which is kind of what types enable the powerful IDE features. Then I don't really think in terms of, oh this needs to be mega, mega, mega type safe. It needs to be correct. It needs to give me the right hints at the right times, give me the right warnings at the right times.

to give me the right hints at the right times, give me the right warnings at the right times. But I don't want every single string in my application to be type safe. That's, that seems a little bit overkill. For instance, people love making or experimenting with type safe hex codes in their application, which is just insane. I've seen them type safe route types, safe, all sorts, unless it's gonna cause a real bug if it's wrong, I like to

I've seen them type safe route types, safe, all sorts, unless it's gonna cause a real bug if it's wrong, I like to just keep it relatively loose. That's A great answer. Alright, we got 45 seconds left. Have you ever regretted using TypeScript? Never ever, ever once have I regretted using TypeScript. Love that. And final question, if you could magically add one feature to TypeScript tomorrow, what would it be?

if you could magically add one feature to TypeScript tomorrow, what would it be? The TypeScript is, uh, TypeScript is rewriting in a uh, in Go. So it's actually like getting 10 times faster. So I would like that. Uh, tomorrow please. That would be really nice. Instead of, I think towards the end of the year. Other than that, there are some nerdy things that I would add.

Other than that, there are some nerdy things that I would add. Like, um, I would love to see TypeScript get better at narrowing generic functions and making sure that the generic types match up to what's actually happening at runtime. And generally narrowing stuff in TypeScript as well could always be improved. And we out of time. Thank you so much Matt. That was awesome.

And we out of time. Thank you so much Matt. That was awesome. Thanks Simon. I'm gonna get better at that.