TypeScript 7 and What Comes Next

TypeScript is a programming language that builds on JavaScript by adding a system of types. Those types let developers describe the shape of their data and catch mistakes before code ever runs, while also powering the autocompletion and editor tooling that many developers now rely on every day. It was first released in 2012, and has since become one of the most widely used tools in web development. TypeScript recently underwent one of the most significant changes in its history with the release of version 7. Daniel Rosenwasser https://x.com/drosenwasser is the Principal Product Manager of TypeScript at Microsoft https://www.microsoft.com/, where he began as an engineer on the team just weeks after the TypeScript 1.0 release. In this episode, Daniel joins Josh Goldberg to talk about the features of TypeScript 7. They discuss the TypeScript team’s approach to tooling, TypeScript’s relationship with the TC39 standards process behind JavaScript, the new API and IPC boundary, how LLMs could reshape type checking and linting, and more. Sponsorship inquiries: [email protected] mailto:[email protected] The post TypeScript 7 and What Comes Next https://softwareengineeringdaily.com/podcasts/typescript-7-and-what-comes-next/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  TypeScript is a programming language that builds on JavaScript by adding a system of types. Those types let developers describe the shape of their data and catch mistakes before code ever runs, while also powering the auto-completion and editor tooling that many developers now rely on every day. It was first released in 2012 and has since become one of the most widely used tools in web development. TypeScript recently underwent one of the most significant changes in its history with the release of version 7. Daniel Rosenwasser is the principal product manager of TypeScript at Microsoft, where he began as an engineer on the team just weeks after the TypeScript 1.0 release.

• 0:44Speaker 00

  In this episode, Daniel joins Josh Goldberg to talk about the features of TypeScript 7. They discuss the TypeScript team's approach to tooling, TypeScript's relationship with the TC39 standards process behind JavaScript, the new API and IPC boundary, how LLMs could reshape type checking and linting, and more. This episode is hosted by Josh Goldberg, an independent, full-time, open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Lint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer

• 1:28Speaker 00

  technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Blue Sky, Thostodon, and dot com as Joshua K. Goldberg.

• 1:52Speaker 01

  With me today is Daniel Rosenwasser, Principal Product Manager of TypeScript at Microsoft. Daniel, welcome to Software Engineering Daily.

• 1:59Speaker 02

  Thank you so much for having me. Great to talk to you today, Josh.

• 2:02Speaker 01

  Yeah, we're really excited to have you. I've been looking forward to this. There's a lot of cool stuff happening in TypeScript, both with the recent releases and then upcoming work. But before we dive into that wonderful world, Daniel, how did you get into tech?

• 2:12Speaker 02

  How did I get into tech? I feel like this is a very common one for a lot of people, you know, video games, things like that, and then getting a little bit more and more and more curious about all the sorts of things and how they work and thinking, oh, maybe I could do this or that. But I think the funny thing was, for me with, I mean, maybe programming specifically, the way I got into a lot of that was through just maybe the earlyness of the internet and then just meeting random people on forums and probably being a little bit too young to be on like a video game forum at the time, right? Like, I don't know, maybe 10, 11 years old or something like that. But meeting these random people from around the world and then finding out that they

• 2:57Speaker 02

  were, you know, 15, 16, 17 years old and running a forum themselves and realizing like, hold on a second, you're all a bunch of teenagers running a website? And that's possible? Like, how? And so naturally, my curiosity got the better of me, and I asked them, like, how would I even start with a lot of this stuff? Oh, well, you know, there's this thing called HTML, and then you can use like a site like GeoCities or this or that to sort of experiment with all of that. And so a lot of my early stuff was, you know, just always hacking around with a family computer and ruining it in various ways, as I'm sure a lot of us have. But then just kind of creating these things and realizing like, wow, there's so much

• 3:42Speaker 02

  power in even this basic HTML stuff. And then you're able to kind of like run little pranks on your friends by throwing a thousand alerts onto a page. And this was back in Internet Explorer 6 days, right? So like, you couldn't just say like, no more pop-ups, right? You just have to kind of suffer through them. And gradually, I got more curious about other programming languages and I ended up, I actually even have the book behind me, it's Beginning Programming for Dummies, because, you know, that's me. So I learned QBasic through that, which is a lot of fun. It was a little, you know, it was a bit of an outdated environment at the time, right? You know, this was around like early 2000s. QBasic was like, I don't know, late 80s, early 90s. But it came with your Windows 98 CD, right?

• 4:26Speaker 02

  And then from there, I was also exploring other things, like, I actually wanted to learn how to set up a website, right? So I learned PHP and I set up an Apache server and, you know, I did like the whole Lamp stack and then I, you know, then there's like, oh, the Lamp stack, like learning Linux. Learned C++ from there, too, because I didn't know that that was going to be more over my head than I realized. And it became more typical, right? You know, going through, you know, high school AP classes for computer science and then, you know, this, the typical college to industry pipeline there.

• 4:58Speaker 01

  Now, how did you get from tinkering around with Lamp and then Lamp stacks over to Microsoft? It seems like a bit of a jump.

• 5:05Speaker 02

  Well, I think that there was always just a natural curiosity about how every part of the computer that I was using worked, right? So I was always really fascinated by every part of it. Like, how does the operating system work? How does all of this stuff work? And I don't know if, you know, part of your question is, right, like, oh, here's a guy who was like starting to dive into like the very Linuxy, like OSS-y stuff. But I think that I was always just really excited by all the different technologies that were out there, right? So I was, I was really, I tried C# and Visual Studio and give things like that a try. And I was just really curious about tinkering.

• 5:49Speaker 02

  I was particularly interested in a lot of the lower-level stuff because it was just so, there's always like, okay, but how does that work, right? Like, you can keep stripping a layer of abstraction away and learning about like the internals there. It's like, yes, your computer can track time, but how does that work, for example? Like, that's, I mean, maybe that's, that's more recent for me in some ways. It's just like, okay, but like, how is all that tracked? But, but a lot of the different abstractions, like, how does your CPU actually function? And then how do system calls work and et cetera, et cetera, et cetera. But like, also, programming languages were really fascinating to me, too. So I was experimenting with different languages over time. There was definitely like this, this sort of group within my university where we were

• 6:31Speaker 02

  all experimenting with like functional programming for a bit. And then those say, like, that's, that entire crowd was, ended up also kind of taking some extra classes, like the compiler construction class and the programming language theory classes. And, and there was this sort of intersection of my interests where I definitely thought that I really wanted to work on developer tools. And to me, one of the, probably, there's only a handful of developer tool companies out there. Microsoft was one of the ones that really stuck out to me, right? And so I applied through the internship program. I ended up at some part of Azure, which was a little bit scary for me at the time because

• 7:16Speaker 02

  of any of the things that I was, I had learned about in college, I think networking was the weakest one. My professor was like practically falling asleep during his own lectures. It was a little bit of a weird experience. So I was really not confident that I knew anything there. But I remember my hiring manager as an intern had told me like, well, you know, just because you're not going to be working on developer tools for the summer doesn't mean like, that's not a possibility in the future, right? Basically, the best way to work at some other part of Microsoft is to work at Microsoft in the first place, right? So I had really annoyed my intern coordinator, just saying like, I really want to work on developer tools, right? Honestly, I don't think they had a lot of people clamoring to them to work on developer

• 8:01Speaker 02

  tools. I'm always shocked at this. There's definitely a very, like, a certain group of personalities who are like really into this stuff. And then I'm always surprised when like people are not. But because, that's because I'm in that first group.

• 8:14Speaker 01

  Well, it's interesting, right? You have developers who day-to-day use these tools, and the better you are with those tools, the more you understand them, the more effective you are at the things you create with them. So tell us, what is that mindset that you and the rest of the TypeScript team and all the people working around you in DevTools have that you're, you're trying to identify here?

• 8:32Speaker 02

  I almost want to answer with something like, oh, it's about perfecting your craft or something like that. There is a little bit of that. There's a lot of empathy that kind of... Drives the decision making, right? Like you know what it is that you are seeking as a developer. You hit all of those rough edges. You understand what other people are trying to accomplish. That really drives you to make things better for yourself and for others, because you know how much of an improvement you can make in someone's day to day experience. Early on on the TypeScript team, there was something really, it was this feature for colorization. We had several layers of colorization so that we could, we could colorize things as quickly as possible

• 9:17Speaker 02

  and then sort of fill in the more complete colors after the fact in ways that were really hard to, hard to spot out, right? And there was like an older version of Visual Studio that, that only supported one mode of colorization, one of the layers or something like that. I really, really did my best to actually implement a version of that colorization just because I knew that our developers would be so much happier if they were on like one earlier version of Visual Studio just to get like better syntax highlighting, right? Cause I, I knew how much that would have been a bummer for people. I knew how frustrating that would have been for a lot of developers.

• 10:00Speaker 02

  So I think a big part of it is honestly empathy. I really feel like in so many ways, I really lucked out being on the team that I did because the people I, I've started working with on the TypeScript team just really had a good mindset about a lot of these things. They really had developer empathy. They had like this drive for excellence. You know, keep in mind that I had, I don't know if this is jumping too much around in, in the history, but I actually started out as a developer on the team and it was like my first true full-time job out of college. And TypeScript had just released at 1.0, maybe three to four weeks prior. And I was coming in there and the big question was like, what are we doing next?

• 10:43Speaker 02

  Like, I, I really didn't know what, what the, what the goal was. I, I had heard about TypeScript in college. I had a lot of skepticism. I thought it was a great idea, but I had a lot of skepticism at the time as an outsider, not working at Microsoft, seeing Microsoft trying to deliver a JavaScript program, a programming language for JavaScript that was open source. This was really not where the company was at at the time.

• 11:09Speaker 01

  You're talking about Microsoft's stance and policy with open source.

• 11:13Speaker 02

  Yeah, in several ways. I think that, you know, there were a lot of different things at the time where there was uncertainty about where the company sort of wanted to go with open source. Like there were a couple of different really cool projects that were released with open source-ish licenses, but there was always sort of like, oh, but you know, I'm not really familiar with that license. I don't know if I can really use it. So I think, and a lot of those often came from like the research wings. It, it, that was my perception, right? But I, I, I kind of joined right, right after Roslyn had been open sourced. TypeScript had hit 1.0 and VS Code was basically maybe

• 11:54Speaker 02

  a year, year and a half away from being actually released publicly as a product. So it was, it was early days. I think that the developer ecosystem was pretty drastically different, right? Whereas in the years after I joined, open source became the default for so many of the developer tools and, and products that we had, we developed at the company. And I don't know how familiar with people are with that, but there were a lot of times in the early days where people just had, even had a distrust from our team, right? And we sort of had to prove a lot of people wrong by just aggressively kind of like doubling down on our stances, doubling down on our principles and really pushing for what we thought was right.

• 12:39Speaker 01

  We had an episode of Software Engineering Daily with one of your beloved coworkers, Jake Bailey, great individual. And Jake talked us through a lot of the sort of technical details of TypeScript, the stuff you were working on back then, you know, the compiler. What is an AST? How does that work? And if anyone's curious about those details, I'd highly recommend they check it out. But for you as a sort of different avenue, I'd like to continue talking about the empathy here. So you've talked about the sort of positioning in the ecosystem empathy that at the time, Microsoft really needed to prove that yes, they can make an open source project that would actually be good for JavaScript developers on a, you know, a technical and a situational level. But also the technical problem of TypeScript was not yet solved at that time. What was the relationship between TypeScript and JavaScript?

• 13:23Speaker 01

  So for those who maybe don't work in that ecosystem or don't deeply understand TC39, which we can get into later, what is the relationship between TypeScript and JavaScript? And why was that such a difficult thing to figure out around 1.0?

• 13:36Speaker 02

  You'll have to take a little bit of what I say with a grain of salt because as I said, you know, I had joined only a few weeks after TypeScript hit 1.0 and maybe this is a, this is just me. Maybe this is a shared experience, but for a lot of, I feel like as a junior developer at the time, I was taking so much in and, and at the same time, really not fully aware of all of the nitty gritty of what was happening, right? Like not necessarily realizing like some of the significance of some of the emails I was getting and things like that. I'm like, oh, does that concern me? Like, I don't know. I, I'm probably just going to try to focus on implementing template strings or whatever. I think that this is, this is, this, this must be common for others,

• 14:21Speaker 02

  but if not, hey, you know, you can make fun of me. But anyways, to answer your question, so TypeScript is a language that builds on JavaScript. And what it does is it brings these different additions to the language in the form of what's called types. So these things are ways of saying, here are the, the sorts of shapes of objects that I'm going to have going around my program. You know, here's an ob, these are objects that have these specific properties and one of them's a number and one of them's a string. And they're all spelled a specific way. You can actually add these types around your project to make sure that some other program can run through them and tell you when you're using them incorrectly.

• 15:03Speaker 02

  And we can also provide really strong editor integration too, so that when you're actually authoring, we can anticipate that you're going to write a property of a specific, you know, name or something like that. So not only are we able to validate work, we're also able to power the authoring experience. We're able to help with exploration. And so in a sense, TypeScript is, TypeScript is JavaScript with syntax for types and really strong tooling. And one of the challenges with building a language on top of another language is that the, the inner language,

• 15:42Speaker 02

  the inner language has a, its own track basically of development, right? It, it wants to, it has, you know, either a language development team, a, a committee that wants to add its own, you know, their own features to the language, right? So JavaScript wants to add specific constructs and TypeScript needs to basically make sure that it doesn't cause any divergences, issues there. And back in the, in the early days, it wasn't clear to what extent TypeScript could develop new features, like what specific features it had to hold back from, what, what was fair game. A lot of the early development in TypeScript was based on interactions with TC39,

• 16:25Speaker 02

  early ideas of what classes were going to look like.

• 16:28Speaker 01

  Just to confirm TC39, the technical committee for JavaScript that you are now on.

• 16:33Speaker 02

  Right, so TC39, my apologies. TC39 is the standards committee for JavaScript, basically. If you look them up, it'll say that they're the standards committee for ECMAScript because there's a whole bunch of trademark issues with that. And so the body that basically manages the specification, ECMA, ECMA, basically made its way into the name of this, of this program language for the specification itself. So TC39 meets, I don't know, maybe I think six times a year. And representatives from different companies and organizations come together and they propose additions or amendments to the language to try to help either improve it,

• 17:17Speaker 02

  disambiguate it for implementers, right? So these, these are typically like your engines in the browser. They'll run in Node, JS or Dino or Bun. And basically the goal is to try to create improvements in the language that are all consistent across these different engines. That way your code can run anywhere in a consistent way. So TypeScript also has representation on, on TC39 as well. This allows us to have a good handle on where the language is going, provide feedback on whether or not we'll be able to provide a good type checking and editing experience. So type checking is that process of, you know, running through your typed JavaScript and telling you where the errors are.

• 18:01Speaker 02

  And, and also we can provide feedback on like how that, how proposals could improve to avoid certain, you know, footguns and gotchas and things like that. So with early days of, of TypeScript, right? Like TypeScript was developed before class syntax was, was actually standardized. It was developed before modules were standardized. A lot of different things were added and implemented in TypeScript before they were actually nailed down. And so TypeScript had to change its implementation several times so that people had to rewrite their code a few times to actually make it work in the, you know, in the successive versions of, of TypeScript so that they could be compiled down to JavaScript.

• 18:48Speaker 03

  Your customer lives in the real world and it's messy. Intermittent connections, mid-onboarding drop-offs, edge cases on devices you've never tested. Mobile apps reflect reality in a way no other surface does. Yet, from an engineering perspective, they're the hardest to understand. It's common for mobile engineers to see green backend dashboards, normal error rates, no crashes. But inevitably, somewhere, there's a frustrated user watching your app spin. After a few seconds, they'll lose patience, close the app, and turn their attention somewhere else. They may never come back. The worst part? Most observability tools never see any of it. BitDrift, on the other hand, captures 100% of mobile data, unsampled and in real time. So it's immediately queryable by engineers and AI agents. It's mobile observability built for the real world.

• 19:33Speaker 03

  Try BitDrift today, bitdrift.io/SignUp.

• 19:38Speaker 03

  You're building agents that can write code, summarize documents, and automate workflows. But they're missing one thing: awareness of the world around them. XWeather combines enterprise-grade weather intelligence with agent-ready APIs, natural language capabilities, and an MCP server built for tools like Claude, Codex, Copilot, and modern IDEs. So your agents can adapt workflows, automate responses, and make better decisions based on real-world conditions. Backed by Vaisala, whose instruments fly on NASA missions to Mars, XWeather delivers trusted data and unique insights that go beyond conditions to actual impact. From real-time lightning strikes to road surface forecasts. Start with 15,000 free API calls every month and pay only for what you use as you grow. Your full weather stack for developers by developers.

• 20:22Speaker 03

  Start building for free today at XWeather.com.

• 20:27Speaker 03

  If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger Data, creators of Timescale DB, takes a different approach. We extend Postgres with hybrid row and columnar storage, so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%. Continuous aggregates keep dashboards live without bash jobs. And it scales to petabytes without you re-architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo, and Flowco run production workloads on Tiger Data today. No stale data, no second system to operate, just Postgres. Managed for you, ready for the workload you're building toward. Try it free at tigerdata.com.

• 21:11Speaker 01

  Do you regret decorators?

• 21:14Speaker 02

  I don't know if I would exactly say that. I think that when we look back at decorators...

• 21:22Speaker 01

  Also, could you explain why what I just asked is an annoying question?

• 21:25Speaker 02

  Yeah.

• 21:27Speaker 02

  Why we're talking about a third real issue? I thought there would be no gotchas. No, I'm joking.

• 21:33Speaker 02

  So decorators are a proposed feature in ECMAScript or JavaScript. And the key thing that they enable you to do is some level of what we call meta-programming over classes and parts of classes. So that you're able to do things like, say, when you call this method, I actually want you to call this other method instead. And so you can sort of intercept the entry and exit of the method. You can replace certain members with other features. You can register members with some sort of framework so that certain things can be either tracked or dependency-injected. So there's a whole bunch of different things that you can do with decorators. You've probably seen them. They start off with an at sign and they're usually associated with a class.

• 22:17Speaker 02

  And so in the early days of TypeScript, I think around roughly the same time, there are a couple of things that were happening. This was probably like late 2014. We were doing our rewrite for TypeScript 1.1, actually. That was actually one of the first things I was involved in as an engineer on the team. A type checker called Flow was now kind of coming onto the scene. This was a type checker from Facebook. And this was a type checker for JavaScript as well, right? Not just like a random type checker. And there was this effort announced by the Angular team called AtScript. The thing that, you know, our slogan at the time, or like one of the things that we described TypeScript as at the time, was TypeScript was a superset of JavaScript.

• 22:59Speaker 02

  AtScript was this proposed idea of a language that was a superset of TypeScript. And the idea was it's JavaScript with types, but also we're adding this thing called annotations, right? And the idea with this was that they wanted to use annotations in the next version of Angular so that they could have this build tooling that leveraged it in certain ways, could optimize it. So a few different people were involved in that effort. Ron Buckden from our team, Sophia Turner and others on our team were all really involved in a lot of this stuff too. And Yehuda Katz as well, who was thinking about this from the Emperor JS perspective and other JavaScript framework.

• 23:42Speaker 02

  And so there was this question of, well, could there be this runtime version of this thing? That's not just, you know, something that a special compiler could understand, right? And so the idea was that there was this proposal for decorators. With the Angular team, their plan was actually just to say, well, yeah, there's a decorator, but we're going to just use this as a static annotation. We'll do something special with it. Maybe there's also runtime implementation there too. Don't worry too much about it as an Angular user. That's like not really something we want you to ever worry about. But it still was a JavaScript language proposal. Years... So that was something that TypeScript implemented at some point, right? Like, the basic thing was, once we hit... I'm kind of jumping ahead a little bit.

• 24:26Speaker 02

  So my apologies for that. I didn't know we were going to be talking about decorators today. So when AtScript was announced, Sophia and our team actually had reached out to the Angular team to see if there was some way that we could actually collaborate and see what the missing gaps were, right? And I think this kind of draws back to that framing at the time that I told you about, right? Like, people did not really trust Microsoft that much in the developer tooling ecosystem, in the JavaScript ecosystem. So the idea that this team from Google, who was running an open-source JavaScript framework, was going to like, say, hey, you know, could we work something out here? It was a little bit, I don't know, maybe they just, they didn't trust us. And once we actually all met with them,

• 25:10Speaker 02

  I think that they saw that we were just some... We're just well-meaning people who wanted to provide a really good developer tooling. And I think a lot of the maybe perceived walls came down and everybody was really excited to collaborate and work together. And then that's when we, you know, Yehuda and others worked on decorators, became more involved in some of the process there. And so we brought it to T C 39 as a proposal. But there was a lot of back and forth on decorators, right? Like, oh, should the symbol actually be the at sign? Should we use that for something else? Oh, should, can we, can we change the runtime semantics of this? So this was one of the, one of the problems with TypeScript in their early days,

• 25:54Speaker 02

  not really knowing like how far ahead it could actually go to implement new JavaScript features before they had reached a certain stage. So, so, you know, looking back on it, like, you asked, oh, is there a regret around decorators? And I think you have to look at how many people like have, you know, they became more productive as a result of having something there. We sort of, we sort of grew both the TypeScript and Angular communities a lot more. And then other frameworks as well were able to use this thing. I think where we are now is a challenging point, right? It is, there's some ambiguity around where the direction is for decorators.

• 26:38Speaker 02

  They kind of got redeveloped along the way. They got new semantics, new APIs. And so understanding where the committee is thinking about this, it's a bit of a challenge. But, you know, we're still involved. We have others at Microsoft who are trying to get feedback from internal frameworks and libraries to understand this stuff. It certainly did change where our framing was for TypeScript, right? So when it came to what features does TypeScript implement, our newer policy, or I mean, it's not new anymore, but we've been running with this for years. We implement features as soon as they hit what's called stage three in JavaScript, in the ECMAScript standardization process.

• 27:21Speaker 02

  So in this process, once something hits stage four, it's officially part of the upcoming specification. Stage three is what they call like a signal to implement for implementers. That's usually good enough for us. So that's when we implement things. But beyond that, when we want to add new, new features for types, for things that actually help on the, on the static analysis side, that is what we do and the tooling side, it's limited to what's called, what we'd call erasable syntax, right? Stuff that you basically can only compile roughly in isolation from any other, any other file.

• 28:02Speaker 02

  None of the, none of the generation of JavaScript is driven by the types at all. In theory, it should be the case that you should be able to just like, strip away all this special TypeScript syntax and be left with like equivalent readable JavaScript. That's sort of where we are today. It has simplified so much of how we collaborate with the JavaScript, you know, standardization committee. And it also gives us a clear line of what is and is not in our scope. When it's not in our scope and we strongly believe in it, we can champion a feature in T C 39. An example of that was optional chaining and nullish coalescing.

• 28:43Speaker 02

  These are, these are like, sometimes called the Elvis operator. Because like, you know, one of these things is like question dot. And so like the question sort of like makes it look like part of Elvis's hair and then the two dots. These are features that make it easier to deal with undefined and null. They are in other languages. I did not originally propose the features.

• 29:06Speaker 02

  But I became active in championing the features in TC39. And there's a lot of like, oh, that seems really challenging to actually like, champion through the committee. Like, there's a lot of like, pushback on certain things. But, but, you know, I think that was a case where we really explored the problem space. We really talked to everybody in the committee. We tried to get feedback. We tried to, I tried to understand people's motivations and we're really diligent about driving it. And, you know, it wasn't all me. Like, we had other people on the, on the, on the champion group as well, you know, helping out with the testing, helping out with feedback on specification.

• 29:49Speaker 02

  Really, really great folks. And it was just like a really cool thing to see that we could all come from different companies and create something where like JavaScript, not even TypeScript, JavaScript, the language got better as a result of all this, which also makes TypeScript better as well.

• 30:05Speaker 01

  I think a lot of listeners will be pleasantly surprised to learn that not only are we talking about TypeScript and we have things to credit you and your team for around TypeScript performance, which we'll talk about next, but also the Elvis operator, knowledge coalescing and optional chaining. Those are good things. Thank you for that. But, okay. So you've painted a picture about how TypeScript kind of came from within Microsoft, became very open source and has these ties into JavaScript, the community and JavaScript slash ECMAScript, the language. Let's, let's fast forward a bit. We did, again, have an episode about the Go port, but could you give us just a brief recap? How has the 26 to 27 years era worked for TypeScript? What have you been up to and how is this Go port going?

• 30:45Speaker 02

  Well, we have just shipped TypeScript 7. We shipped TypeScript 7 a few weeks ago. And for those who are not familiar, this, this version is extremely special because it's completely different, well, with a caveat, it's a different code base. It's, it's been rewritten in native Go code, which has provided us with what is often a 10x speedup on many code bases. And the way that we've achieved that is through a combination of port of, you know, moving from a compiler written in TypeScript to a compiler written in Go and getting a native speedup through Go code, but also being able to leverage shared memory, parallelism and concurrency.

• 31:30Speaker 02

  So being able to actually use the most of all the cores and all the, all the threading features that you have to actually maximize throughput and, and, and, and get things done as quickly as possible. Maybe many of you have noticed in the last, I don't know, at least two decades, where we've been seeing that the number of cores has been growing rather than the clock speed on processors for the most part. And so as we've been able to scale things up, we often have programs that don't capitalize on all those cores. And so now have a new compiler that is able to like, parse all your files and saturate your cores as much as possible

• 32:11Speaker 02

  and actually get a build that is almost instantaneous for many people. So this, this was a really big undertaking and we've worked on it for, I guess, what do you describe as over a year and a half, at least at this point. It has been exhilarating. It's one of the most fun things that we've worked on. I mentioned that as an, you know, when I started as an engineer, I got to be part of a rewrite as well. We've been describing this more as a port because we've been looking basically on the, you know, left side of the screen, right side of the screen. One side is TypeScript, the other side is the Go that we're converting to. And we've been trying to keep everything one to one as much as possible. Right? So it's been a lot of fun and it's been a lot of fun

• 32:55Speaker 02

  finding ways of actually, you know, making it more than 10x, you know, even faster, finding other optimizations that we can do. But the release has been really well received. I think a lot of us really wanted to make sure of that because this was not an easy call for us to make, you know, when we first embarked on this effort. So everyone on the team was really trying to pull through and make sure that it, that it happened well, like that, that this was a good release for people. We know that there is more to the story for TypeScript 7. We knew that there are certain things like providing an API and, and things like that. And, and so we know that a, a big portion of the TypeScript and JavaScript ecosystems

• 33:37Speaker 02

  are still waiting on the next step in TypeScript 7, right? So that they can actually get TypeScript support in Vue files and Angular files and things like that. But we've been able to make a lot of people happy with this release. Right? You know, like, like I mentioned, this is, it's a 10x speedup, but also this depends on your computer and your processor and whatever. But like, we have teams at Microsoft with massive code bases and they have experienced a lot of frustration running on older versions of TypeScript because, you know, the TypeScript 6.0 and prior, this was a JavaScript codebase. I don't know how much you want me to get into the history of how we made the decision to start doing TypeScript 7.

• 34:22Speaker 02

  But basically, we had a compiler but written in TypeScript and it was extremely fast for being a TypeScript application, right? Something that runs on a JavaScript engine. But it was ultimately limited to one, one, one thread. And people would often hit out of memory issues on really large code bases. And they'd often be waiting minutes for really large projects to actually load in their editor before they could do anything.

• 34:49Speaker 01

  I would direct our viewers to the Jake Bailey episode where we covered it. But that's a great overview. Thank you. I also want to dive in a little bit though, to the area you're discussing because as you've said in blog posts and other videos, 7.1 is, is the version where you're going to have a lot of API integrations for integrators. What is it about the API that needed to be pushed to 7.1? Like, what, what makes this a difficult problem and what are you doing to work with the community around it?

• 35:13Speaker 02

  You know, one of the ways that we developed API in the original versions of TypeScript was it was sort of this organic growth. And it was the typical thing that you do if you're writing a, a type, you know, JavaScript library, right? Like you have a bunch of functions and methods. They are ideally well-founded in terms of shape, right? Like they have some coherency and then you say, well, this is something I, I feel pretty ready to expose to other people because other people want to do the same things that my application internally wants to do, or they require the same sort of data or some, some internal data to do that. Right? And so you have to come up with some abstractions, but you know, it's so hard to do that in a disciplined way.

• 35:56Speaker 02

  And so there's, there's basically this API that grew very organically. Right? And so when we moved to Go, there was a couple of big challenges on a technical side, namely that, well, you're written in, in Go. How the heck do you get all of these JavaScript libraries to continue using any of the information? Right? And then what if you want these other applications to be able to use your data? Right? I mean, the default in, in the Node ecosystem is that, hey, I'm going to, I'm going to provide a JS API. But also like there's alongside with us, there was this sort of native tooling renaissance for a lot of people. Right? People are maybe going to want to write stuff in Rust that also consumes the same data.

• 36:41Speaker 02

  And it's particularly hard with our choice of language, Go in some ways, because there is a runtime with a certain set of expectations around like who owns memory and how and why and where. And so we had to come up with something that was relatively disciplined that we would feel at ease exposing on both, to both JavaScript and other consumers in some way. Right? So, so basically we ended up with something where we are providing an IPC boundary, an inter-process communication boundary between our API. Right? It's not just that you're, you're seeing all the same data that we are in our process. You actually have to transfer things over and be a little bit more disciplined

• 37:25Speaker 02

  in, in how you ask for certain information across the wire so that you're not just, you know, using all the memory in your, in your address space. Right? And mirroring it all over too. We picked Go because it made the port so much easier while also being able to provide a lot of the speed gains. But, you know, if we had picked any other language, right? Like, we didn't want our, our choice of language to be this implementation detail that was exposed to how you get data from the TypeScript compiler. So we, we came up with something that would have been good regardless of the language that we chose. Right? And so we've been developing a solution that, that, that has sort of first-class support for TypeScript and JavaScript consumers, but could be used in any language ultimately. And we are seeing other, you know, consumers of that.

• 38:09Speaker 02

  And so we're seeing, you know, we're seeing some people not use the API in the meantime. Right? And they're, they're building their own Linters and whatnot. And, you know, it's open source. You can't really stop people, but we're not necessarily discouraging it either because I think it's good to see where those things go. But it's incredibly promising to see where a lot of the tooling will go with this stuff. We're really committed to making sure that there's a good story because I don't know if I would necessarily be able to confidently say it's like a quarter or a third of our users, but definitely like a big sec, a big segment of people use things like embedded languages, like these sort of templating languages that, that sort of embed TypeScript in JavaScript. They really are, are looking forward to having good TypeScript support.

• 38:54Speaker 02

  Linters and other tools, right? Like, obviously you're very familiar with this domain and I'm sure you're, you're keeping a close eye on this as well. But we need to really be able to provide a solid experience there. For reference, one of the most

• 39:09Speaker 01

  I'm using parts of the Linter or JavaScript tooling ecosystem right now is that there is a third language in play Rust and the kind of up and coming, very fast, very integrated Linter, oh excellent, is built on Rust, but its TypeScript integration is this thing called TS Golang, which is this, I've seen some obscene words from its creators used to refer to how it reaches inside TypeScript. Also, words like beautiful and clever. Then also, there are custom rules written in TypeScript. So do you see this ecosystem kind of normalizing or standardizing, getting a little less wacky over the next version or two?

• 39:45Speaker 02

  It's really interesting. I don't know. I think that for some set of tools, it may not be out of the question to take that approach. One of the hopes was with the API was to try to minimize the amount of duplication. And so we have this notion of being able to have multiple clients for a shared, what you'd call, session of project, right? So you basically say, I have multiple things trying to use the API. They all have the same view. And maybe they're able to actually plug into the same view of what you have in your editor. So that way, they're not all loading up the same stuff all over again in their processes.

• 40:27Speaker 02

  That's sort of the ideal. Like, maybe it's not the worst thing for some projects to have their own copy or something like that, right? You know, if they are able to find that, hey, for some people, that there's this trade off of speed versus memory, and it's okay, you know, that's totally fair game. But we are definitely designing with this. We're designing with a lot of like the stuff we wish we could have done in mind, right? In the TypeScript 6.0 days, right? Oh, it would be really cool if we could have multiple clients. It would be really cool if we could do all this stuff. But it's prohibitive without threads. It's prohibitive without like redoing a whole bunch of different stuff internally and not having the language server designed specifically with that stuff in mind.

• 41:12Speaker 02

  We have a lot of architectural improvements on top of the old codebase that have made things so much simpler. And also even improved reliability in TypeScript 7, which is cool because we can say like, it's not only better, it's less crashy.

• 41:28Speaker 01

  What a rare treat to hear in this day and age of software.

• 41:32Speaker 02

  Right. We were really diligent about making sure that we got a lot of feedback from external partners and companies. It was not just us working with internal Microsoft teams. It was us, like, this is us always sort of doubling down on reaching outward and getting a sense of where things are there.

• 41:49Speaker 01

  You talked about TypeScript 7.1, which will have the upcoming API. And one can assume something around TypeScript 7.2 that adds to it. I want to talk a little bit in our last five to 10 minutes of technical discussion about 7.3, perhaps even 8.0 years down the road. Let's say that you've figured out the story for Linters, for embedded languages like Astro. Like, all these things are kind of standardized and normalized. What does that ecosystem look like to you? How does this feel as a person just trying to write some darn TypeScript, once this has all been figured out?

• 42:20Speaker 02

  Oh, wow. It's a big question. I think that it is. It's such a challenge to know exactly where we're going to land. 8.0 is generally like two and a half years from 7.0, right? So knowing exactly where we'll be, we typically don't have something like a two and a half year plan on that stuff. I can tell you some of the big question marks that we have around that, right? Certainly, a big part is the changes in development practices, right? I mean, the obvious, the elephant in the room is, in addition to all the excellent, like, powerful tooling that we have in your editor, now have models, like large language models that are able to

• 43:02Speaker 02

  generate incredibly correct on the first try code in a lot of these cases. So one of the thought experiments I always have is, well, what does that imply about the trade off between expressivity and verbocity, maybe? Or the sorts of rules that you can enforce, right? So in programming languages, there's this like trade off of what's called like soundness and completeness. So I'm going to geek out a little bit here. But basically, you will often try to catch a certain class of bugs by being like more sound. But the trade off is, you know, in order to express that something is actually like an okay operation, you're often trading off completeness, which is the ability to say like,

• 43:46Speaker 02

  or you need to provide expressivity to communicate that, which is often like, I need to find ways of telling a checker compiler that something's okay, right? So one thought was, do we find more ways of being more thorough in our type checking? Are there certain gaps that we have that we can kind of like close out? The other side of this is that that is good in some capacity, but there are often places where there are more ad hoc things that you want to actually check, right? There's more things that are like more specific to your company or team, or there's certain classes of bugs are special about your codebase, which I'm sure in your mind,

• 44:31Speaker 02

  you're lighting up at like, hey, wait, those are lint rules, right? Exactly. And so there's definitely this question of, are language models really well suited for creating new lint rules on the fly, right? Like, something that maybe someone on your team said, oh, it'd be really cool to write a lint rule to do blah, right? Blah, blah, blah. You know, that would be really cool. But yeah, you have other things that you kind of have to do. And unless your teammate gets really like pulled in by the idea, like they get nerd sniped, then it's just not going to happen. And these things are now much more within reach, right? So it could very well be that the API becomes even more important over time

• 45:13Speaker 02

  so that we can support that ecosystem. And maybe there's more integrations within our tooling to sort of unlock that. But there are also lots of other things that we always have on the horizon, right? There's always new JavaScript features. There's always new features that are added to Node.js and other runtimes that we have to implement. And then there's often things that are really nice to have, like, you know, people have asked, people have all these weird things in TypeScript for doing meta programming to say, hey, I want to be able to split the names or like the contents of a string literal type in TypeScript, right? These are literal types that describe the contents of a string. That's how powerful our type system is.

• 45:57Speaker 02

  And would it be cool if there was a less hacky way of splitting a string? There's a lot of quality of life things that we've sort of held off on because for the last year and a half, we've been trying to make things as fast as possible. And it was a risky trade off, but I think it's become more and more clearly promising.

• 46:15Speaker 01

  I'm curious, are there types or type features such as, you know, dependent types, negated types, et cetera, that you would want to define for the listener and then say may or may not be possible anew because of the performance improvements of TypeScript 7?

• 46:28Speaker 02

  One obvious feature that we said no to for performance reasons was a stricter type for this on methods. So when you define a method on a class, like we had a strictness option to say, no, no, no, you can never orphan this method without re-binding it in some way.

• 46:47Speaker 01

  You're going to have to define what orphaning a method means for the...

• 46:52Speaker 02

  Yeah. So basically, you can basically grab a reference to a method on an object. And if you do that, every method or every function in JavaScript, most functions in JavaScript, too many gotchas here, they implicitly have a value called this when you call them, like THIS. And when you call a function on an object, like as a method, like object dot my method, and you call that, basically, this gets bound as the thing on the left side of the dot, right? As the receiver object is what they often call it. And if you just like grab a reference to the method and then try to call it directly,

• 47:35Speaker 02

  and there's, so then you call it directly and there's nothing on, there's no object on the left of the dot, there is no dot. You'll get undefined. And then if you try to access this in the method, if it ever does, you're going to have an error message that says undefined is not a valid object or something like that, right? So we didn't do that for performance reasons. It was also kind of painful, right? As a user experience thing. So we could potentially revisit that. I think negated types, it's come up again on the team actually in the last week or two. So we have some people experimenting with it. And I think there was some performance characteristic there as well. But I think it really comes, a lot of the things that we start off saying no to is just because

• 48:19Speaker 02

  the user experience story is a little bit too complicated, right? You know, you say, I have not a number. I have not numbers, right? So that's what a negated type is. You say like, I accept anything that's not a number. Which is weird because if you really want to geek out and you look into something called constructivist logic, you now have to like, there's a whole thing about being able to actually, it's like, no, you really don't have, like, this thing does not describe a number. Like, what doesn't describe a number? Well, strings certainly, like, they're a disjoint set. They're truly a disjoint set. But there's a lot of stuff that is like technically not a number, right?

• 49:01Speaker 02

  Like, if you say that you have, if you have something of type unknown, that encompasses every possible object in the TypeScript type system, right? So can you assign an unknown to not a number? No, because technically, a number is an unknown. So you have to sort of reject that, right? Okay. So maybe with these specific types, it's kind of...

• 49:29Speaker 02

  Fine, but like you just say, these are not valid. But then it gets, it gets really hairy when you start talking about object types, right? So I, I love a lot of the type system. I don't know, like the algebra of it all, but it also makes it, it's a great way that, you know, if I had a whiteboard or something like that, we could talk about it. We could actually show like, this gets really gnarly in ways that both don't make a lot of sense from a mathematical perspective, but also from like a type system perspective. It's, it's really hard to reason about it. But if we work on it a little bit more, we could find something that is, that is still, you know, useful for people while being a little complicated for certain examples. So I, I don't, I don't know.

• 50:12Speaker 02

  I mean, that doesn't really answer your question about performance exactly, but those are some of the things that we've been talking about again.

• 50:19Speaker 01

  I think you answered the question correctly, which was to answer the correct question. It's really, I think oftentimes not a question of performance, whether you, one should add these things to types. But it sounds like even if you were performing, it's just all heck of levels of complex that maybe it's not even worth it for users to be able to represent these things. Maybe the better investment would be, you know, deeper LLM agent integrations, performance overall, just like making it more palatable for people and tools.

• 50:44Speaker 02

  Right? Yeah, I definitely think if you, if you look back at the, you know, there's like an essay or a blog post from many years ago, it used to be hosted on the Microsoft blogs, but it was something like every feature starts at like negative 1,000 or negative 1,000 points, right? It's still true today, right? You really have to justify something to be added to the language because now every person has to start thinking about this feature. It's, it's very rare that you can say, oh, we have this language feature. Yeah, but it's like more pay to play. Don't worry about it. It'll come up for people, right? They will have to think about it. They will have to know whether or not they have to know about it. It can be frustrating. Maybe it's better with large language models. I think we'll have to see it there.

• 51:29Speaker 02

  In every discussion that I've had with other programming language designers, it feels like all of the same concerns that we have about languages today apply equally as well to these models, right? Complexity, familiarity, right? Like trying to balance between those different assets. Yeah.

• 51:49Speaker 01

  So for our last technical question this interview, is there a single thing you want to plug that if a listener is involved with their TypeScript team at work or doing tooling stuff, what would you want them to try out from TypeScript today or TypeScript tomorrow?

• 52:02Speaker 02

  So I think that if you're already using TypeScript 6.0 and as long as you're not using any, you know, editor integration or like language server plugins or things like that, so like, but if you're not using Vue or Angular or some of those frameworks right now, it's very likely that you can just start running TypeScript 7 today, right? You can start off just by installing the TypeScript 7 extension, let's say in VS Code or looking up support in your favorite editor and you'll just have something that is so much faster at loading your projects. So you should just give it a shot today. And even if you're using your API and whatnot, like you're using TypeScript VS Lint to still

• 52:45Speaker 02

  integrate with TypeScript 6, you can have these things side by side. So we have explicit documentation on how to do that on our blog post and you should go, go check it out. In the meantime, I think keep an eye on some of the threads that we have on GitHub for API integrators. Uh, we're working with all these different library and framework teams to try to make sure that what's, uh, there is going to be a solid solution for TypeScript 7.1. They often have some prototypes of, let's say, build and editor integration that are already working. We have a whole bunch of really cool stuff there. I think Johnny Riley from, who's worked on TS Loader recently got TypeScript 7 working with, uh, Webpack, which is really cool, right?

• 53:29Speaker 02

  So you can start using your TypeScript 7, even if you're using Webpack, just through some of the early APIs that we're exposing right now. You know, those require nightly versions of TypeScript, but I think it's really promising. So I guess my plug is yeah, go, go try out the new compiler, right? It's so much faster and it's more ready than you think it is. And we've heard from so many teams that this thing is like a lifesaver for their day-to-day productivity, right? Worked with people at Slack, people at, uh, Vanta, uh, you know, many, many companies, like entire companies who are, are already on TypeScript 7. So yeah, give it a shot.

• 54:05Speaker 01

  That's a great call to action. I have one last question for you, Daniel. That's, I like to end each interview with sort of a palate cleanser, something to talk about that's not work related. What is, what is your situation with fostering cats? And I guess as a sub-question, would you recommend fostering cats to people?

• 54:22Speaker 02

  Oh, absolutely. Our pet cat, Pablo, uh, he is a foster fail, which is when you basically have decided like, I want to adopt the cat that I'm fostering. So many years ago, I was, I was watching my sister's cat whenever she was like going out of town for stuff and every time I had to give her pet back, I was like sad. So my fiance actually suggested, what if we start fostering? And so we start off with these three kittens and it sounds really heartbreaking, like, oh, you basically, you know, have these, these small animals and then you have to like let them go and someone else gets to have them for the rest of your life. But you start to see how happy they make other people. So we've actually fostered, I think over 12 cats now.

• 55:04Speaker 02

  Some of them that, you know, they come in like twins or triplets as kittens, which is always fun as well. Some of them will, uh, eat at your plants and destroy them if you're not careful or leave little like indentations in the, you know, in the screen of your windows. But we don't regret it at all. I mean, it's, it's a lot of fun. We, you know, the only thing is like, when you travel, it's kind of a pain, but like, hey, I think it's, it's, it's so great. I guess I'm a crazy cat guy, which is fine. My, my hobbies include coding, cooking, kayaking and cats. So it's, yeah, I don't know. There's a theme here.

• 55:41Speaker 01

  There's a definite theme. I have a kitten whose footprints are now immortalized in my bedroom from the repainting in the color of the walls on the floor. It's, it's great.

• 55:50Speaker 02

  Incredibly adorable.

• 55:52Speaker 01

  Yes. Well, Daniel, thank you so much for spending an hour with me. We talked about the history of TypeScript, how you came to the team, TypeScript 6 to TypeScript 7, TypeScript 7.1, very excited about those APIs. If people wanted to learn more about you and the work you're doing online, where would you direct them? What sorts of websites?

• 56:08Speaker 02

  On the socials, I guess. Generally I hang out most with Blue Sky, I'm on Twitter and maybe one of these, yeah, I guess those are the two places right now and GitHub, of course, right? Keep an eye on what I'm posting on GitHub. We try to keep people up to date with this sort of plans of TypeScript going forward, development, PRs as well, right? I, I code still even as a product manager and yeah, catch me on at all those places where it's either, I guess, Dan R, D Rosenwasser or Daniel Rosenwasser as my handles. I'm really great at consistency, as you can tell.

• 56:44Speaker 01

  There's a joke somewhere in there about programming languages and soundness or some such. But anyway, thank you so much again. This has been wonderful. For Software Engineering Daily, this has been Daniel Rosenwasser and Josh Goldberg. Thanks for listening, everyone. Have a great day.

• 56:57Speaker 02

  Thanks.