How are you feeling? Good. I've just been in the chat about TypeScript's comments. So it was kind of interesting already to then come into this Slido results, which are also very nuanced opinions. It's like not entirely black and white, whether it's brilliant for TypeScript and brilliant for JavaScript, but generally probably really good for the ecosystem. So it looks like everybody's sort of thinking about this right now, and it's not quite so binary. Strong agree. Yes, it's a nuanced topic. Out of curiosity, what did you vote on for the poll? I'm strong it's good for TypeScript. It was one of the last projects that I worked on when I was at TypeScript, the microsite that tries to describe the proposal in much simpler language than we would use when we're sort of talking between language implementers. Like there's a whole different way in which you talk differently when you're talking between like TC39 people and trying to describe it to everybody else. And so I tried to find ways to describe that same proposal, but in much simpler language. Well, I'm sure the entirety of the web appreciates your efforts there. Taking a bit of a step back, my first question for you is what is your favorite thing that the TypeScript team built in the last few years? It's interesting because like a good chunk of my favorite features in TypeScript came before I even joined. Like my biggest favorite is template, it's just literals actually, just the idea of having an exact string being something that you could have as a type. Like that just blew my mind when I first was introduced to TypeScript. And there was so many places where if I'd have been able to do that in other programming languages, I'd have done that everywhere. And it seems so apt for JavaScript. And it felt like such a natural fit for TypeScript that you can show someone that and they get excited. And then they get excited about the rest of TypeScript quite naturally from the idea of just being able to define a literal string. It was my entry point to really loving TypeScript, I think. Absolutely. That phrase, a natural fit, is great. I think it described a lot of language features such as that one where you might not have thought about it as a thing you might want, but once you have it, it's shocking and horrifying to think that you used to not. Yeah. Yeah, I think the template, the string template literals that sort of built on top of that also has a very similar feel. You don't really use them until you need to use them. So they're not the sort of code people write in client-side code. It's sort of something you would probably put in a library. But when you actually start writing code that is described via a template string literal, it feels so incredibly elegant in ways that is just a natural fit for trying to describe JavaScript. Absolutely. When you look at the history of some of the really core pivotal features in TypeScript, like conditional types, literals, template literals, maps types, is there any one particular feature you think has come out recently that really changed how TypeScript works for you and others? Yeah, but it's probably not the answer you're expecting. To me, one of the most interesting changes that happened to TypeScript was Babel support. And that was quite a long time ago now, but TypeScript had to add a flag called isolated modules that sort of says, hey, from this point on, you can transform the file in a way that doesn't require knowing all of the other files. And when people nowadays are talking about these really fast build infrastructures using like ES build or SWC, that's all feasible because of that change back for Babel a very long time ago. And that sort of allowed this entire ecosystem to flourish of absolutely incredibly fast builds, simply because TypeScript made a reasonable constraint on itself in order to allow for Babel to work, but then allowed everybody to be able to have really fast builds multiple years down the line. So, we're talking about TypeScript as a language, but I keep thinking about it as an ecosystem. So a lot of my favorite things are like the way in which TypeScript interacts with the rest of the ecosystem that has allowed all the people to do cool stuff. That's fantastic. I did not realize that change is what allows me to use SWC in my Jest test now. I love that. Thank you for that. You actually bring up a really interesting point that TypeScript doesn't always prioritize the things that users like me would immediately think of. I was thinking of tuples being fantastic. So how does the TypeScript team make decisions about these huge features? Like what to support, what to prioritize or de-emphasize? It's tricky, right? Because TypeScript is one of the most popular languages in the world, and the amount of user feedback we get is absolutely incredible. Yeah. And so a lot of it comes from interacting with standards bodies like TC39. Other parts of that comes from having interactions with sort of other people doing high level dev tooling. And also, being part of Microsoft gives TypeScript a lot of access to people who are doing very large projects, as well as very small projects that have quite strong opinions about how they should work. And so that gives TypeScript the ability to sort of talk to a lot of people about how they're building something and be able to make informed decisions based on interacting with a large amount of the community. A good chunk of my time when I was working on TypeScript was trying to help set up this Discord that would allow for a lot of people to talk about the problems that they're having with TypeScript and help each other. And so we also managed to learn a lot about what problems people were having in TypeScript and how can we make better error messages or provide better tooling to sort of say, hey, you don't understand what version of TypeScript you want for node version X. Well, once enough requests for that came through, then it was quite obvious that maybe not building it into TypeScript was an answer, but maybe building outside of TypeScript and making it easily documented for everybody else could be an answer. And so there's sort of like lots of different ways which as a team, there was ways to find input given the size of the community, but trying to prioritize and understand which ones are actually worth attacking at TypeScript level versus trying to make it easy for people outside of TypeScript to do. So that's just a feeling that you get over a long time period. And most of that team has been working on TypeScript for over five years, and they know what it's like to be working at this scale and how to make some of these trade-offs. It's a vibe, working on TypeScript is a vibe. I think that's a great segue to another part of questions talking about how folks in the community can get involved or how their opinions form. So let's say that I'm someone in the community who's maybe used TypeScript, but wants to get more involved. How can I contribute to or get more involved with TypeScript, the ecosystem or the language? So sometimes that's, you know, anybody that is making cool and interesting TypeScript projects is contributing to the ecosystem, in my perspective, as well as, you know, helping out other people that are trying to do the same thing. Like sometimes just contributing to other people's code is a huge advantage to helping TypeScript as an ecosystem. But like, as you get further down the line, you start to feel like you want a little bit more control in that ecosystem. And so, you know, TypeScript has thousands and thousands of GitHub issues on its repo. And there are a lot of them are actually, we need more opinions on this problem. And if you're willing to turn on the stream of turning watch on in the TypeScript repo, you will really understand a lot of the flaws in TypeScript, as well as a lot of like the arguments about why things are the way they are. And once you start to understand why things are the way they are, then you have a much better understanding of how to improve things. It's like one of my theories is never, you know, never remove something you don't fully understand. And then the other side of that is try not to make issues about something you don't fully understand yet. And if you. And so there's a lot of people who help out on the TypeScript issues by just replying to other people's issues quite regularly. From there, if you want to contribute code, there is a lot of ample places within TypeScript where, where like the TypeScript team don't necessarily prioritize their time, specifically in order to allow people to start contributing. Good cases for that are sort of, you know, refactors and editor tooling, like TypeScript ships all of these fixits in them. When, when it hits an error code, and that gives you the ability to sort of automatically make the change for you in the language. There's so many, like, issues that are, you can do this if you want to go and fix this particular, add this particular fixit. The hard bit from there is, you know, how do you understand the TypeScript compiler? It's a pretty big, complicated repo. But one of my last projects was to sort of document how the compiler works. To some extent, it's a big project and it's hard to do that. But there's a really great video that describes a lot of the key components inside the TypeScript repo that I think you might be able to then contribute to the actual codebase bomb, if you go and watch that video. I think I call it the, I think it was at the TypeScript conference last year, called diving into the compiler, maybe? That's a good place to start. I think that was the name. That was a great video. That was a good time. So your general summary is yell at people and be yelled at by people on the internet in the form of GitHub issues. Yeah. On that line, what do you think is the most common thing for devs in and out of the TypeScript community to get wrong about TypeScript? I think it's one that I still get wrong a lot of the time. It's being frustrated by the compiler errors from TypeScript. The team was genuinely always trying to improve the compiler errors. And it's very easy to say, oh, they don't know what they're doing, but they're constantly being improved. And every feedback the TypeScript team gets on what is a bad looking compiler error is usually good feedback to the team, because that's how you improve it. The TypeScript team doesn't have a copy of whatever app you're running and seeing the exact errors you're seeing. And sometimes they can just be edge cases that have not been fully covered yet. So if you think that you're seeing bad error messages, could be you are seeing bad error messages, and it would be nice to get a good copy of those so that we could improve them. And maybe you could improve them. Absolutely. I can vouch. I have reported issues and felt the joy of seeing someone fix them and fixed a couple and it's a fantastic feeling. Highly recommend. We do have one question to start with from the audience here from Andreas Roth. Hey Ordo, do you think we will ever see runtime access to types? No. No. I don't think it will happen. You know, even with the TC39 proposal for types as comments doesn't have that either. If anything, we might see good third party tools that try to provide that. But I think it's realistically too hard to provide that information at runtime from the compiler because the compiler doesn't know everything at the end of the day. It nearly always only knows a subset of what your code base actually is. And so that you can't trust that code. And that's that's one of the fundamental design decisions that TypeScript made to always be erasable so you know TypeScript is always JavaScript with types and you can remove the types and you always have JavaScript. But in the process of that, like it can't truly understand everything. And so it will always be a little bit leaky. And if you have code that 100% relies on it, then you may end up in a state where the code that's checking isn't actually what you know accurate to what you hope it would be. Absolutely. I think there's been a lot of discussion over the last few years about what needs to be implemented in the core land, whether that's like Node or Deno core or TypeScript core versus what should be implemented in user land, something that doesn't have one canonical best way known to do it in core. And this absolutely sounds like a user land concern. Yeah. I also want to note, remind people slide, slide Oh, number two 904 we are soon going to show the results of the poll what is your favorite feature from TypeScript 4.7. So, folks, please do answer that poll before time runs out. We don't have any more questions from the audience that we've filtered through so I'll ask you one of my own on Twitter, I saw earlier today someone posted a TS error better reporter thingy have you have you seen this what do you think of this. Yeah, what it is. He. So, this is a website that tries to re interpret TypeScript error code in order to provide you a plain English form of that error code, which is an absolutely cool idea. And I'd love to see. Honestly, it's one of those things where I'd love to see like GitHub co pilot, try to explore that space to where it tries to then give you like the error, the English error code in English. I think a lot of these things are really cool. This is a really cool user land answer. I just like I love love to be able to do user land compiler error messages myself too. I almost started a pull request to try and get that happening in TypeScript so that I could explore that space because I have some designs. I think it's really cool and I'd love to see more explorations in that space. Absolutely. Same I'd love to have that integrated into editors, and so on. Yeah. And I think the results they look like they've settled down for the poll so I think we can show now that this was my answer to ESM node support. It is so annoying to not have extra script module support in these random little edge cases and thank you TypeScript for for significantly improving that story. I'm also very good at a lot of that one. Yeah. I agree completely. That was mine. Well I'm glad our sample size of two is represented by the sample size of over 9000. Super. It's also like the easiest one to think about right the rest of them are like okay so control flow analysis and computed properties, huh. So, a computed properties on a union that doesn't thing in this bit and then the control flow analysis, it's much easier to just answer ESM node. Yeah. So I'm getting the, the sound in the ear note that we have to start finishing now so order, I'm going to thank you once more that was an excellent fireside chat it's always a pleasure speaking with you. I appreciate the danger. Tape in your background. Thanks for joining us and looking forward to hearing more from you on discord and the rest of the conference. Same, and I'm looking forward to seeing all the next talks to good luck everybody.