TypeScript 7 and What Comes Next

26:48But, 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, 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. So in this process, once something hits stage four, it's officially part of the upcoming specification.

27:28Sage 3 is what they call 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 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 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.

28:17That's sort of where we are today. It has simplified so much of how we collaborate with the JavaScript 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 NTC39. An example of that was optional chaining and knowledge coalescing. 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 would i did not originally propose the features but i became active in championing the features in TC39.

29:12And 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 try to get feedback. We try 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 champion group as well, you know, helping out with the testing, helping out with feedback on the specification. Really, really great folks.

29:50And 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. 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.

30:19But 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 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? Well, we have just shipped TypeScript 7. We shipped TypeScript 7 a few weeks ago. And for those who are not familiar, this version is extremely special because it's completely different.

30:59Well, 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 beat up on many code bases. And 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. So 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.

31:44Maybe 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 of those cores. And so we now have a new compiler that is able to like parse all your files and saturate your cores as much as possible and actually get a build that is almost instantaneous for many people. So this was a really big undertaking and we've worked on it for, I guess, what you described as over a year and a half, at least at this point.

32:24It 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 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. So it's been a lot of fun. And 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.

33:02But 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 happened well, like 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 things like that. And so we know that a big portion of the TypeScript and JavaScript ecosystems are still waiting on the next step in TypeScript 7, right?

33:42So 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 I mentioned, this is, it's a 10X speed up, but also this depends on your computer and your processor and whatever. But like we have teams at Microsoft with massive codebases 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:22But basically, we had a compiler 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 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. 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.

35:05What is it about the API that needed to be pushed to 7.1? Like what makes this a difficult problem and what are you doing to work with the community around it? You know, one of the ways that we developed an 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 type 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 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 internal data to do that, right?

35:50And so you have to come up with some abstractions, but it's still hard to do that in a disciplined way. And so 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 Go, oh, 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 the Node ecosystem is that, hey, I'm going to provide a JS API, but also alongside with us, there was this sort of native tooling renaissance for a lot of people, right?

36:36People are maybe going to want to write stuff in Rust that also consumes the same data. 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. So basically we ended up with something where we are providing an IPC boundary, an inter-process communication boundary between our API. It's not just that you're seeing all the same data that we are in our process.

37:21You 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. But, you know, if we had picked any other language, right, like 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. So we came up with something that would have been good regardless of the language that we chose, right?

37:57And so we've been developing a solution 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 consumers of that. And so we're seeing some people not use the API in the meantime, right? And they're building their own linters and whatnot. And 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 segment of people use things like embedded languages, like these sort of templating languages that sort of embed TypeScript and JavaScript.

38:50They really are looking forward to having good TypeScript support. linters and other tools, right? Like obviously you're very familiar with this domain and I'm sure 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 amusing 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, OXLint, is built on Rust, but it's typescript integration is this thing called ts golint which is this i've 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 in typescript so do you do you see this ecosystem kind of normalizing or standardizing getting a little less wacky over the next version or two?

39:45It'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 with 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, a 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:27That'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 if they are able to find that hey for some people that there's 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 in the type of 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.

41:02It'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. 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. What a rare treat to hear in this day and age of software. 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.

41:41It was us, like, this is us always sort of doubling down on reaching outward and getting a sense of where things are there. 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. 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 has all been figured it out?

42:20Oh, wow. That'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 generate incredibly correct on the first try code in a lot of these cases.

43:09So one of the thought experiments I always have is, well, what does that imply about the trade-off between expressivity and verbosity maybe, or the sorts of rules that you can enforce, right? So in programmer languages, there's this trade-off of what's called 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, 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?

43:56So 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 code base, which I'm sure in your mind, 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?

44:46Like 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, 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 so that we can support that ecosystem. And maybe there's more integrations within our tooling to sort of unlock that.

45:21But 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 other runtimes that we have to implement. And then there's often things that are really nice to have. It's like, you know, people have asked, people have all these weird things in TypeScript for doing metaprogramming 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:57And 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 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. I'm curious. Are there types or type features such as 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? One obvious feature that we said no to for performance reasons was a stricter type for this on methods.

46:36so 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 rebinding it in some way unless you explicitly you're going to have to define what orphaning a method means for the yeah so basically you can basically grab a reference to a method on an object and if you do that every method in or every function in job most functions in javascript So many gotchas here. They implicitly have a value called this when you call them, like T-H-I-S. 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?

47:27As 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. 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 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.

48:02I 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 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, like, there's a whole thing about being able to actually say, no, you really don't have, like, this thing does not describe a number.

48:49Like what doesn't describe a number? Well, strings certainly, like they're a disjoined set. They're truly a disjoined set. But there's a lot of stuff that is like technically not a number, right? Like if you say that you have, if you have something of type unknown, that encompasses every possible object in the type of type system, right? So can you assign an unknown to not number? No, because technically a number is unknown. So you have to sort of reject that, right? Okay. So maybe with these specific types, it's kind of fine. But like you just say, these are not valid. But then it gets really hairy when you start talking about object types, right?

49:36So I love a lot of the type system. I don't know, like the algebra of it all. But it also makes it 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 it. a lot of sense from a mathematical perspective, but also from like 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. So 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.

50:18I 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 of 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 you know deeper llm agent integrations performance overall just like making it more palatable for people and tools 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, used to be hosted on the Microsoft blogs, but it was something like every feature starts at like negative 1000 or negative 1000 points, right?

51:02It'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 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. 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?

51:43Complexity, familiarity, right? Like trying to balance between those different assets. Yeah. 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? So 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.

52:25You 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 DSLint to still 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 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.

53:11They 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, who's worked on TS Loader, recently got TypeScript 7 working with Webpack, which is really cool, right? 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 try out the new compiler, right? It's so much faster and it's more ready than you think it is.

53:47And 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 Vanta, you know, many, many companies, like entire companies who are already on TypeScript 7. So yeah, give it a shot. Yeah, that's a great call to action. I have one last question for you, Daniel. I like to end each interview with sort of a palate cleanser, something to talk about that's not work related. What is your situation with fostering cats? And I guess as a sub question, would you recommend fostering cats to people? 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.

54:32So many years ago, 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 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. Some of them, you know, they come in like twins or triplets as kittens, which is always fun as well.

55:10Some of them will eat at your plants and destroy them if you're not careful or leave little like indentations in the screen of your windows. But we don't regret it at all. I mean, it's a lot of fun. And we, you know, the only thing is like when you travel, it's kind of a pain, but like, 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. So it's, yeah, I don't know. There's a theme here. 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.

55:49It's great. Incredibly adorable. 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? On the socials, I guess. Generally, I hang out most in 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.

56:20We try to keep people up to date with the sorts of plans of TypeScript going forward, development, PRs as well. I code still, even as a product manager. And yeah, catch me 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. 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:57Thank you.