EPISODE 1956

[INTRODUCTION]

[0:00:00] ANNOUNCER: 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. 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 ESLint, 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 technologies, and a Co-Founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on BlueSky, Fosstodon, and .com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:53] JG: With me today is Daniel Rosenwasser, principal product manager of TypeScript at Microsoft. Daniel, welcome to Software Engineering Daily.

[0:01:59] DR: Thank you so much for having me. Great to talk to you today, Josh.

[0:02:02] JG: 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. Before we dive into that wonderful world, Daniel, how did you get into tech?

[0:02:13] DR: How I got into tech. I feel like this is a very common one for a lot of people, 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." 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 earliness of the Internet and then just meeting random people on forums and probably being a little bit too young to be on a video game forum at the time, right? 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 were 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? How?"

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, there's this thing called HTML and then you can use a site like GeoCities, or this, or that to experiment with all of that. A lot of my early stuff was 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 creating these things and realizing like, wow, there's so much power in even this basic HTML stuff. Then you're able to run little pranks on your friends by throwing a thousand alerts onto a page. This was back in Internet Explorer 6 days, right? You couldn't just say like, "No more pop-ups," right? You just have to suffer through them.

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 that's me. I learned QBasic through that, which is a lot of fun. It was a bit of an outdated environment at the time, right? This was around early 2000s. QBasic was, I don't know, late 80s, early 90s, but it came with your Windows 98 CD, right? Then from there, I was also exploring other things, like, I actually wanted to learn how to set up a website, right? I learned PHP and I set up an Apache server and I did the whole WAMP stack. Then there's like, "Oh, the LAMP stack," 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? Going through high school AP classes for computer science and then the typical college to industry pipeline there.

[0:04:59] JG: 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.

[0:05:06] DR: Well, I think that there was always just a natural curiosity about how every part of the computer that I was using worked, right? I was always really fascinated by every part of it. How does the operating system work? How does all of this stuff work? I don't know if part of your question is like, oh, here's a guy who was starting to dive into the very Linux-y OSS-y stuff, but I think that I was always just really excited by all the different technologies that were out there. I tried C Sharp and Visual Studio and give things like that, try. I was just really curious about tinkering. I was particularly interested in a lot of the lower-level stuff, because it was just - there's always like, "Okay, but how does that work?" You can keep stripping a layer of abstraction away and learning about the internals there.

It's like, yes, your computer can track time, but how does that work, for example? I mean, maybe that's more recent for me in some ways. It's just like, okay, but how is that all that tracked? But a lot of the different abstractions, like how does your CPE actually function? Then how does system calls work and etc., etc., etc. Also, programming languages were really fascinating to me, too. I was experimenting with different languages over time. There was definitely this group within my university where we were all experimenting with functional programming for a bit. That entire crowd was ended up also taking so much to classes, like the compiler construction class and the programming language theory classes.

There was this intersection of my interest where I definitely thought that I really wanted to work on developer tools. To me, there's only a handful of developer tool companies out there. Microsoft was one of the ones that really stuck out to me. 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 of any of the things that I had learned about in college, I think networking was the weakest one. My professor was practically falling asleep during his own lectures. It was a little bit of a weird experience. I was really not confident that I knew anything there. I remember my hiring manager as an intern, he told me like, "Whoa. Just because you're not going to be working on developer tools for this summer, doesn't mean that's not a possibility in the future."

Basically, the best way to work at some other part of Microsoft is to work at Microsoft in the first place. I had really annoyed my intern coordinator, just saying like, "I really want to work on developer tools." Honestly, I don't think they had a lot of people clamoring to them to work on developer tools. I'm always shocked at this. There's definitely a very certain group of personalities who are really into this stuff. Then I'm always surprised when people are not. But that's because I'm in that first group.

[0:08:14] JG: Well, it's interesting, right? You have developers who day-to-day use these tools. The better you are with those tools, the more you understand them, the more effective you are at the things you create with them. Tell us, what is that mindset that you and the rest of the TypeScript team and all the people working around you and dev tools have that you're trying to identify here?

[0:08:33] DR: 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 drives the decision making. 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 colorize things as quickly as possible and then fill in the more complete colors after the fact in ways that were really hard to spot out, right? There was an older version of Visual Studio 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 one earlier version of Visual Studio just to get better syntax highlighting, right? Because 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.

I think a big part of this 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 have started working with on the TypeScript team just really had a good mindset about a lot of these things. They really had our empathy. They had this drive for excellence. Keep in mind that I had - I don't know if this is jumping too much around in the history, but I actually started out as a developer on the team and it was my first true full-time job out of college. TypeScript had just released at 1.0, maybe three to four weeks prior. I was coming in there and the big question was like, what are we doing next? I really didn't know what the goal was.

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 program language for JavaScript that was open source. This was really not where the company was at at the time.

[0:11:10] JG: You're talking about Microsoft's stance and policy with open source.

[0:11:13] DR: Yeah, in several ways. I think that there were a lot of different things at the time where there was uncertainty about where the company wanted to go with open source. There were a couple of different really cool projects that were released with open source-ish licenses, but there was always like a, "Oh, but I'm not really familiar with that license. I don't know if I can really use it." A lot of those often came from the research wings. That was my perception, right? I joined right after Roslyn had been open sourced, TypeScript had hit 1.0, and VS Code was basically maybe a year, year and a half away from being actually released publicly as a product. It was early days.

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

[0:12:40] JG: We had an episode of Software Engineering Daily with one of your beloved co-workers, Jake Bailey, great individual. Jake talked us through a lot of the technical details of TypeScript. The stuff you were working on back then, the compiler, what is an AST? How does that work? If anyone's curious about those details, I'd highly recommend they check it out. For you as a different avenue, I'd like to continue talking about the empathy here. You've talked about the 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 technical and a situational level.

Also, the technical problem of TypeScript was not yet solved at that time. What was the relationship between TypeScript and JavaScript? 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? Why was that such a difficult thing to figure out around 1.0?

[0:13:36] DR: You'll have to take a little bit of what I say with a grain of salt, because, as I said, I had joined only a few weeks after TypeScript hit 1.0. Maybe 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 at the same time, really not fully aware of all of the nitty-gritty of what was happening. Not necessarily realizing the significance of some of the emails I was getting and things like that. I'm like, "Oh, does that concern me? I don't know. I'm probably just going to try to focus on implementing template strings, or whatever." I think that this must be common for others. But if not, hey, you can make fun of me.

Anyways, to answer your question, so TypeScript is a language that builds on JavaScript. What it does is it brings these different additions to a language in the form of what's called types. These things are ways of saying, here are the sorts of shapes of objects that I'm going to have going around my program. These are objects that have these specific properties and one of them is a number and one of them is a string. 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.

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 name, or something like that. Not only are we able to validate, we're also able to power the authoring experience. We're able to help with exploration. In a sense, TypeScript is JavaScript with syntax for types and really strong tooling. One of the challenges with building a language on top of another language is that the inner language has its own track, basically, of development. It has either a language development team, a committee that wants to add their own features to the language. JavaScript wants to add specific constructs. TypeScript needs to basically make sure that it doesn't cause any divergences issues there.

Back 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 was fair game. A lot of the early development in TypeScript was based on interactions with TC39, early ideas of what classes we're going to look like.

[0:16:29] JG: Just to confirm TC39, the technical committee for JavaScript that you are now on.

[0:16:34] DR: Right. 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 basically made its way into the name of this program language for the specification itself.

TC39 meets, I don't know, maybe, I think six times a year. Representatives from different companies and organizations come together and they propose additions, or amendments to the language to try to help either improve it, disambiguate it for implementers. These are typically your engines in the browser. They'll run in Node.js, or Deno, or Bun. 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. 

TypeScript also has representation 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. Type checking is that process of running through your type to JavaScript and telling you where the errors are. Also, we can provide feedback on how proposals could improve to avoid certain foot guns and gotchas and things like that. With early days of TypeScript, TypeScript was developed before class syntax 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.

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 successive versions of TypeScript, so that they could be compiled down to JavaScript.

[0:18:47] JG: Do you regret decorators?

[0:18:49] DR: I don't know if I would exactly say that. I think that when we look back at decorators -

[0:18:58] JG: Also, could you explain why what I just asked is an annoying question, too?

[0:19:01] DR: Yeah. Why are we talking about a third reel issue. I thought there would be no gotchas. No, I'm joking. Decorators are a proposed feature in ECMAScript, or JavaScript. The key thing that they enable you to do is some level of what's called 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 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. 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 the class.

In the early days of TypeScript, think around roughly the same time, there are a couple of things that were happening. This was probably late 2014. We were doing a 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 coming onto the scene. This was a type checker from Facebook, and this was a type checker from JavaScript as well. Not just a random type checker. There was this effort announced by the Angular team called AtScript. Our slogan at the time, or one of the things that we described TypeScript as at the time was, TypeScript was a superset of JavaScript. AtScript was this proposed idea of a language that was a superset of TypeScript. The idea was it's JavaScript with types, but also we're adding this thing called annotations.

The idea with this was that they wanted to use annotations in the next version of Angular, so that they could have this build tool and that leverage it in certain ways, could optimize it. A few different people were involved in that effort. Ron Buckton from our team, Sophia Turner and others on our team were all really involved in a lot of the stuff, too. And Yehuda Katz as well, who was thinking about this from the emperor, JS perspective, another JavaScript framework. There was this question of, well, could there be this runtime version of this thing that's not just something that a special compiler could understand?

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 a runtime implementation there too. Don't worry too much about it as an Angular user. That's not really something we want you to ever worry about." But it still was a JavaScript language proposal. That was something that TypeScript implemented at some point.

The basic thing was once we hit - I'm jumping ahead a little bit. My apologies for that. I didn't know we're going to be talking about decorators today. When AtScript was announced, Sophia and her 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. I think this draws back to that framing at the time that I told you about. Like, people did not really trust Microsoft that much in the developer tooling ecosystem, in the JavaScript ecosystem. The idea that this team from Google, who was running an open-source JavaScript framework, was going to say, "Hey, could we work something out here?"

It was a little bit, I don't know. Maybe they didn't trust us. Once we actually all met with them, I think that they saw that we're just well meeting people who wanted to provide a really good developer tooling. I think a lot of the maybe perceived walls came down and everybody was really excited to collaborate and work together. Then that's when Yehuda and others, working on decorators became more involved in some of the process there. We brought it to TC that are not as proportional. There was a lot of back and forth on decorators, right? Like, oh, shit, the symbol less actually be the @ sign. Should we use that for something else? Oh, shit, can we change the runtime semantics of this?

This was one of the problems with TypeScript in their early days, not really knowing how far ahead it could actually go to implement new JavaScript features before they had reached a certain stage. Looking back on it, you asked, oh, is there a regret around decorators? I think you have to look at how many people cap - they became more productive as a result of having something there. We grew both the types of Angular communities a lot more. Then other frameworks as well were able to use this thing.

I think where we are now is a challenging point, right? There's some ambiguity around where the direction is for decorators. They got redeveloped along the way. They got new semantics, new APIs. Understanding where the committee is thinking about this, it's a bit of a challenge. 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? 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 it with this for years. We implement features as soon as they hit what's called stage three in JavaScript in the ECMAScript standardization process.

In this process, when something hits stage four, it's officially part of the upcoming specification. Stage three is what they call a signal to implement for implementers. That's usually good enough for us. That's when we implement things. Beyond that, when we want to add new features for types, for things that actually help 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 file. 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 strip away all the special types of syntax and be left with equivalent readable JavaScript. That's where we are today. It has simplified so much of how we collaborate with the JavaScript standardization committee. 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 NTC39. An example of that was optional chaining and nullish coalescing. These are sometimes called the Elvis operator, because one of these things is a question dot. And so, the question 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're in other languages. I did not originally propose the features, but I became active in championing the features in NTC39. There's a lot of, oh, that seems really challenging to actually champion through the committee. There's a lot of push back on certain things. 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. I tried to understand people motivations. We're really diligent about driving it. it wasn't on me. We had other people on the champion group as well, helping out with the testing, helping out with feedback on the specification. Really, really great folks.

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

[0:27:41] JG: 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, nullish coalescing and optional chaining. Those are good things. Thank you for that.

Okay. You've painted a picture about how TypeScript came from within Microsoft, became very open source and has these ties into JavaScript, the community and JavaScript/ECMAScript, the language. 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? How is this Go port going?

[0:28:21] DR: Well, we have just shipped TypeScript 7. We shipped TypeScript 7 a few weeks ago. For those who are not familiar, this version is extremely special, because it's completely different, well, with a caveat. It's a different code base. It's been rewritten in native Go code, which has provided us with what is often a 10X speed up on many code bases. The way that we've achieved that is through a combination of port, of moving from a compiler written in TypeScript to a compiler written in Go and getting a native speed up through Go code, but also being able to leverage shared memory, parallelism and concurrency.

Being able to actually use the most of all the cores and all the threading features that you have to actually maximize throughput 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. As we've been able to scale things up, we often have programs that don't capitalize on all those cores. We now have a new compiler that is able to parse all your files and saturate your cores as much as possible and actually get a build that is almost instantaneous for many people.

This was a really big undertaking. We've worked on it for, I guess, what you described 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 engineer, 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 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. We've been trying to keep everything one to one as much as possible, right?

It's been a lot of fun. It's been a lot of fun finding ways of actually making it more than 10X, even faster, finding other optimizations that we can do. The release has been really well received. I think a lot of us really wanted to make sure that because this was not an easy call for us to make when we first embarked on this effort. Everyone on the team was really trying to pull through and make sure that it happened well. 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 things like that. We know that a big portion of the TypeScript and JavaScript ecosystems are still waiting on the next step in TypeScript 7, so that they can actually get TypeScript support and view files and Angular files and things like that. We've been able to make a lot of people happy with this release. Like I mentioned, it's a 10X speed up, but also, this depends on your computer and your processor and whatever. We have teams at Microsoft with massive code bases. They have experienced a lot of frustration running on older versions of TypeScript, because the TypeScript 6.0 and prior, this was a JavaScript code base.

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. Basically, we had a compiler bit written in TypeScript. It was extremely fast for being a TypeScript application, right? Something that runs on a JavaScript engine. It was ultimately limited to one thread. People would often hit out of memory issues on really large code bases. They'd often be waiting minutes for really large projects to actually load in their editor before they could do anything.

[0:32:25] JG: 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 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? What makes this a difficult problem? What are you doing to work with the community around it?

[0:32:49] DR: One of the ways that we developed the API in the original versions of TypeScript was it was this organic growth. It was the typical thing that you do if you're writing a JavaScript library. You have a bunch of functions and methods. They are ideally well-founded in terms of shape. They have some coherency. Then you say, "Well, this is something 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 data, or some internal data to do that. You have to come up with some abstractions. It's so hard to do that in a disciplined way. There's basically this API that grew very organically.

When we move to Go, there's a couple of big challenges on a technical side, namely that, well, you're written in Go, how the heck do you get all of these JavaScript libraries to continue using any of the information, right? Then, what if you want these other applications to be able to use your data, right? I mean, the default in the node ecosystem is that, hey, I'm going to provide a JS API, but also, alongside with us, there was this native tooling renaissance for a lot of people. People are maybe going to want to write stuff in Rust that also consumes the same data.

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 who owns memory and how and why and where. We had to come up with something that was relatively disciplined, that we would feel at ease exposing to both JavaScript and other consumers in some way. Basically, we ended up with something where we are providing an IPC boundary, an Integer Process Communication boundary between our API. It's not just that 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 in how you ask for certain information across the wire, so that you're not just using all the memory in your address space 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. If we had picked any other language, we didn't want our choice of language to be this implementation detail that was exposed to how you get data from the TypeScript compiler. We came up with something that would have been good, regardless of the language that we chose, right? We've been developing a solution that has first-class support for TypeScript and JavaScript consumers, but could be used in any language ultimately. We are seeing other consumers of that.

We're seeing some people not use the API in the meantime, right? They're building their own linters and whatnot. 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. 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 a quarter, or a third of our users. But definitely a big segment of people use things like embedded languages. These templating languages that embed TypeScript and JavaScript, they really are looking forward to having good TypeScript support. Linters and other tools, obviously you're very familiar with this domain and I'm sure you're keeping a close eye on this as well. We need to really be able to provide a solid experience there.

[0:36:42] JG: For reference, one of the most amusing parts of the Linter, or JavaScript tooling ecosystem right now is that there is a third language in play, Rust. The up and coming very fast, very integrated Linter, OXlint, is built on Rust, but its TypeScript integration is this thing called tsgolint, 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. Also, there are custom rules written in TypeScript. Do you do you see this ecosystem normalizing, or standardizing, getting a little less wacky over the next version or two?

[0:37:21] DR: 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 API was to try to minimize the amount of duplication. We have this notion of being able to have multiple clients for a shared, what you'd call session - a project, right? You basically say, "I have multiple things trying to use the API. They all have the same view." Maybe they're able to actually plug into the same view of what you have in your editor. That way, they're not all loading up the same stuff all over again in their processes. That's the ideal. Maybe it's not the worst thing for some projects to have their own copy, or something like that.

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, that's totally fair game. We are definitely designing with this - we're designing with a lot of the stuff we wish we could have done in mind in the TypeScript 6.0 days. 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, and it's prohibitive without redoing a whole bunch of different stuff internally and not having the language server designed specifically with that stuff in mind. 

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

[0:39:05] JG: What a rare treat to hear in this day and age of software.

[0:39:08] DR: 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. This is us always doubling down on reaching outward and getting a sense of where things are there.

[0:39:26] JG: You've 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, all these things are 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 is all been figured out?

[0:39:56] DR: Wow, that's a big question. I think that it's such a challenge to know exactly where we're going to land. 8.0 is generally two and a half years from 7.0. 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. Certainly, a big part is the changes in development practices. The elephant in the room is, in addition to all the excellent, powerful tooling that we have in your editor, now have models large, like language models that are able to generate incredibly correct on the first try code in a lot of these cases.

One of the thought experiments I always have is, well, what does that imply about the trade-off between the expressivity and verbosity maybe, or the sorts of rules that you can enforce? In programming languages, there's this trade-off of what's called soundness and completeness. I'm going to geek out a little bit here. Basically, you will often try to catch a certain class of bugs by being more sound. The trade-off is, in order to express that something is actually an okay operation, you're often trading off completeness, which is the ability to say, 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.

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 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. There's more things that are 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, you're lighting up and like, "Hey, wait. Those are lint rules, right?" Exactly.

There's definitely this question of are language models really well suited for creating new lint rules on the fly? Something that maybe someone on your team said, "Oh, it would be really cool to write a lint rule to do, blah. Blah, blah, blah, blah." That would be really cool. Yeah, you have other things that you have to do. Unless your teammate gets really pulled in by the idea, like they get nerd sniped, then it's just not going to happen. These things are now much more within reach, right? It could very well be that the API becomes even more important over time, so that we can support that ecosystem. Maybe there's more integrations within our tooling to unlock that.

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. Then there's often things that are really nice to have. It's like, 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 the contents of a string literal type in TypeScript." These are these are literal types that describe the contents of a string. That's how powerful our type system is.

Wouldn't 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 held off on, because for the last year and a half, we've been trying to make things as fast as possible. It was a risky trade off. But I think it's become more and more clearly promising.

[0:43:51] JG: I'm curious, are there types, or type features such as dependent types, negated types, etc., 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?

[0:44:04] DR: One obvious feature that we said no to for performance reasons was a stricter type for this on methods. When you define a method on a class, we had a strictness option to say, no, no, no, no, you can never orphan this method without rebinding it in some way.

[0:44:25] JG: You're going to have to define what orphaning a method means for the -

[0:44:27] DR: Yeah. Basically, you can basically grab a reference to a method on an object. If you do that, every method, or every function in - most functions in JavaScript, so many gotchas here, they implicitly have a value called THIS when you call them, like T-H-I-S. When you call a function on an object as a method, object.mymethod, and you call that. Basically, this gets bound as the thing on the left side of the dot as the as the receiver object is what they often call it. If you just grab a reference to the method and then try to call it directly - so then, you call it directly, there's nothing on there's no object on the left of the dot, there is no dot, you'll get undefined. Then if you try to access this in the method, if it ever does, you'll get an error message that says, undefined is not a valid object, or something like that.

We didn't do that for performance reasons. It was also painful as a user experience thing. We could potentially revisit that. I think negated types, it's come up again on the team actually, in the last week or two. We have some people experimenting with it. I think there was some performance characteristic there as well. A lot of the things that we start off saying no to is just because the user experience story is a little bit too complicated. You say, "I have not a number. I have not numbers." 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 constructive as logic, you now have to - there's a whole thing about being able to actually say like, "No, you really don't have -" This thing does not describe a number. 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 technically not a number, right?

If you say that you have something of type unknown, that encompasses every possible object in the type of type system. Can you assign an unknown to not number? No, because technically, a number is a known, so you have to reject that, right? Okay. Maybe with these specific types, it's fine. But you just say, these are not valid. Then it gets really hairy when you start talking about object types. 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 to - 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 a type system perspective, it's really hard to reason about it. But if we work on it a little bit more, we could find something that is still useful for people while being a little complicated for certain examples. I don't know. 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.

[0:47:54] JG: 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 one should add these things to TypeScript. It sounds like, even if you were performing, it's just all heck 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 deeper LLM agent integrations, performance overall, just making it more palatable for people and tools.

[0:48:20] JG: Right. Yeah. I definitely think if you if you look back at the - there's an essay, or a blog post from many years ago. Used to be hosted on the Microsoft blogs. But it was something like, every feature starts at negative 1,000, or negative 1,000 points, right? It's still true today. 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 very rare that you can say, "Oh, we have this language feature." Yeah, but it's more pay to play. Don't worry about it. It'll come up for people. 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 there.

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. Complexity, familiarity, like trying to balance between those different assets.

[0:49:25] JG: For our last technical question in 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?

[0:49:39] DR: I think that if you're already using TypeScript 6.0 and as long as you're not using any editor integration, or language server plugins, or things like that, 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. 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. You should just give it a shot today.

Even if you're using your API and whatnot, like you're using TypeScript VSLint to still integrate with TypeScript 6, you can have these things side-by-side. We have explicit documentation on how to do that on our blog post, and you should 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. We're working with all these different library and framework teams to try to make sure that what's there is going to be a solid solution for TypeScript 7.1. They often have some prototypes of, let's say, build an editor integration that they're already working. We have a whole bunch of really cool stuff there.

I think Johnny Reilly, who's worked on TS loader, recently got TypeScript 7 working with Webpack, which is really cool, right? 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. Those require nightly versions of TypeScript, but I think it's really promising. I guess, my plug is, yeah, go try out the new compiler, right? It's so much faster, and it's more ready than you think it is. We've heard from so many teams that this thing is like a lifesaver for their day-to-day productivity. Worked with people at Slack, people at Vanta, many, many companies, entire companies who are already on TypeScript 7. Yeah, give it a shot.

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

[0:51:58] DR: Oh, absolutely. Our pet cat, Pablo, he is a foster fail, which is when you basically have decided like, "I want to adopt the cat that I'm fostering." Many years ago, I was watching my sister's cat whenever she was going out of town for stuff. Every time I had to give her pet back, I was sad. My fiancé actually suggested, "What if we started fostering?" We started off with these three kittens. It sounds really heartbreaking. Like, oh, you basically have these small animals and then you have to 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.

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

[0:53:17] JG: 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 great.

[0:53:26] DR: Incredibly adorable.

[0:53:28] JG: 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, to 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?

[0:53:44] DR: On the socials, I guess. Generally, I hang out most with Bluesky. I'm on Twitter. 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 the search of plans of TypeScript going forward, development, PRs as well. I code still, even as a product manager. Yeah, catch me at all those places, where it's either, I guess, DanR, DRosenwasser, or Daniel Rosenwasser as my handles. I'm really great at consistency as you can tell.

[0:54:21] JG: There's a joke somewhere in there about programming languages and soundness, or some such. 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.

[0:54:33] DR: Thank you.

[END]
SED 1956		Transcript

	(c) 2026 Software Engineering Daily	1