TypeScript Origins: The Documentary

I'm Steve Lucco. I work on software for developers and I started the TypeScript team. We were trying to make the JavaScript engine that was in Internet Explorer much faster. When we started we were like way up here, like off the charts on the main benchmark that measures how fast you are in JavaScript. By the end of 2010, we had caught up and actually passed Chrome. And then once it was fast, then the plan was, okay now people are going to write much larger pieces of software because they have the fast engines to run them. And

so the next thing was we were trying to invest in better tools. We were starting to build an editor which is the editor that eventually became VS Code. And I got to about 7000 lines of code and I got really mad, having times where I would take half a day to find a bug because I had typed a variable name wrong or used the wrong API in the JavaScript library or in say jQuery or something. It takes forever to track these things down because you have no type information that a tool like a compiler can

use to find these problems before you get to running the code. And so you're left with just sitting in the debugger. So I started thinking it was more important to go build a tool than it was to finish the editor. So that's when I started writing TypeScript. You were seeing just this enormous ascendancy of the web platform. Not just at Microsoft but across the entire industry. There were fast JavaScript engines which were just becoming the norm. V8 had released maybe a year and a half before this. Microsoft was working obviously on the Chakra engine. There

were fast engines coming from Mozilla and other players and so the web had just gotten 10 to 100x faster. One day my manager's manager came into my office and said "Luke, we would like you to go work in a different team inside the company." Which is never a thing you necessarily want your boss to say but in this case it was sort of an opportunity to go kind of work on programming languages and developer tooling for an area that was becoming increasingly important to Microsoft and really I think across the industry, which was working on

the JavaScript language and tools. One of the folks I talked to there was Steve Lucco and me and him talked about a bunch of things around what we could do with sort of increased investment in JavaScript. One of the things that he was really excited about, and I think both of us spent quite a lot of time talking about even before I joined the team, was the opportunities that existed to potentially bring much richer sort of tooling on top of the JavaScript language. And in particular what we would need to do to extend the JavaScript

language to support that. Steve had been talking to a lot of other engineering managers and VPs and things around the company who were all facing kind of a similar challenge, that they were moving a lot of their development from desktop applications built using C# or C++ and using all the tooling that we were building with Visual Studio, they were moving into writing them with JavaScript which just the tooling that was available to support that was not nearly as mature. Excel, Word, PowerPoint, you know the classics of kind of productivity software, all of that had been

developed in C++ and were absolutely huge codebases. But they were rich-client applications that ran on Windows and we needed to make them available in the context of the browser. So we were taking these legacy codebases that were millions of lines of code with thousands of developers internal to Microsoft working on them who had C++ experience and now basically telling them they needed to build an application that ran in the browser in JavaScript. JavaScript as it existed in that era and it's certainly evolved considerably since then really wasn't designed to be a programming language that supported

large codebases and many, many people collaborating on those large codebases. The question was really how? How do they accomplish that? We started giving talks around DevDiv, the developer division of Microsoft, and in one of those talks, Anders Hejlsberg was in the front row. After that Luke and I talked and we were like "oh you know, Anders may have enough time that he could really join us and help us." Luke and I had a lot of pieces of the puzzle, you know classes and object types and enums and stuff, but we knew Anders would really help

us put those puzzle pieces together in an excellent way. I think at first Anders was somewhat skeptical about TypeScript and what we were trying to do with the Strada project. He's actually very conservative about creating new programming languages and it wasn't until he got kind of deep into the problem space that he kind of looked at it and he was like "you know, actually, I do think that there's programming language design work that needs to be done here." And Anders is the guru of programming language design at Microsoft. I remember being intrigued by this. Languages

have always fascinated me and when something new comes along you know where you go "Oh that sounds like an interesting problem!" And this really sounded like an interesting problem. We were increasingly seeing teams inside Microsoft do strange things in order to write their JavaScript apps. And in particular we were asked whether we would productize a technology called Script# which was a transpiler that would transpile C# into JavaScript. And I was kind of curious as to why would you want to develop your JavaScript that way? And it turns out that that was the only way that

a large team, that at least they had found, that was the only way a large team could actually have grown up development processes and the tooling that they were accustomed to in languages like Java and C#, with statement completion and go to definition and safe refactorings and type checking before you run the code. And so they would write in C# with a fake runtime library and then they would transpile it to JavaScript and then run it in the browser. And I was sort of like kind of taken aback by that. I go "wow, that's crazy."

I mean you're willing to remove yourself that far from your target just in order to get a better experience. What if instead we thought about, what is it that's broken about JavaScript and is there a way we could fix that? To some extent I was hesitant about building something new, but in a lot of ways it isn't something new, it's an improvement to something that exists. And I was actually quite attracted to that because there's a baseline and you're not like trying to invent from scratch solutions to problems that everyone has already solved. There is

JavaScript. This is more about like how do we refine JavaScript how do we add a type system to it? That's a fascinating idea. And then of course you come to the realization that in order for a type system to work for JavaScript, it has to be structural. You can't get there with a nominal type system and it has to be generic. And it's so "oh my, this is kind of interesting." There aren't a lot of type systems like that out there. But in the beginning I was really just helping them with the design. Steve built

the first prototype compiler the 0.8 compiler. I had this JavaScript engine that was compatible with the whole web. So I took the parser of that thing which was written in C++ and I ported it to JavaScript. And that's why TypeScript was compatible with the whole web and like whatever JavaScript you threw at it from the beginning, because it was actually started from a fully compatible parser. And then once I had the fully compatible parser, I started adding optional type annotations to things like the parameters of functions so that I could check them. And then I

took the bugs that I had had that made me mad and I injected them into my code, and the compiler found them right away. And right about then, we got this great opportunity to hire the Eclipse team led by Erich Gamma, who's an amazing architect. He'd built some of the most impressive kind of IDE experiences that existed in the market at the time. I handed off the prototype of VS Code to Erich's team, but I made them agree to one thing which is, when we have enough TypeScript that you could actually use it, please try

to use it in building VS Code and give us feedback, because we desperately need feedback. As early as possible and every day. We started very small in this building here and our deliverable was this web based editor. I must say I was a little bit scared of the challenge initially. Web based developer tools they need JavaScript and of course my first concerns was how you build large scale JavaScript. And one thing a side note on that as I learned in brushing my JavaScript skills what also scared me was that JavaScript the definitive guide is kind

of heavy. JavaScript the good parts is kind of light right? So this didn't increase my confidence but still that's more anecdotal. I take my first trip to Redmond to meet the other peers, other leaders in Microsoft, and one of them was Steve Lucco. He told me then for the first time, I knew there was work on that, on this TypeScript initiative, which was Strada at that time. And I must say when I saw that and Steve even had that method completion running, right? When you type an object you make ".", then you get code suggests

you the methods, which is all TS tooling in place. This was almost love at first sight. It's very hard to build tooling like code completion or refactoring when you don't know the types. Because without types you have to guess and you have to speculate what could this type be? But once you have a type then of course you're happy from a tooling side because you can figure out for instance where is this object used because it has a type and which other ones are affected when I change the type, right? So things like find all

references or rename a symbol, that's what you can do once you have type information and you can trust what you find in the code. And this was very hard with JavaScript without any type information. Interestingly we had kind of two camps. We had written our own Java to JavaScript framework. That wasn't great but we didn't like JavaScript writing because of all the productivity loss, and then coming in here with the new job, first day is like "ooh we have this new programming language." I'm bad in remembering methods and spelling and all that stuff. So I

was pretty excited and pretty happy. I believed already in the power of static analysis, of statically typed languages at the time, and so I was in for the ride. At the beginning I was a skeptic. I just absolutely hated anything that would get in the way of getting this instant feedback. I think maybe six months into doing VS Code or so we wanted to refactor our code to make it more clean and make it obvious which file imports which other files and stuff like that. That is the point when I realized how important being able

to change the code is. After doing all of that I was like gosh like, doing JavaScript, it's kind of like carving code in rocks. Once you've written this awesome JavaScript code, you're never going to touch it again, because you don't remember yourself what you did six months ago. You can never refactor code you cannot find bugs. It's impossible. You have a property that's called ID and you want to rename that to modelID and you do find replace. Good luck. TypeScript has helped us in two distinct ways. It has helped us to build VS Code itself.

The second thing is what we basically end up shipping. Without TypeScript there would be no VS Code. It's impossible to pull this off. Code navigation, in the sense of find references, go to definition, find implementations, find definitions. Yeah, you need a language brain to reason about the code that you've wrote. And this is all TypeScript. I remember it was a bumpy road at the beginning. We were always hitting all kinds of compiler bugs, but Steve was awesome. So basically we would be like you know, overnight we were taking advantage of the time zone difference. Email

Steve overnight and overnight the next day he would send us an email with the zip "oh, there's a new compiler." And then we tried it and it was fixed. And then you look at it it's like "gosh, we were so good in three months." What have we done since then, right? What have we been doing? And every millisecond on this planet, somebody uses a VS Code feature, which is mind boggling. All my computer science friends use VS Code. Yeah. So I'm super privileged to be part of this. And when I look back right our code

base is now over twelve years old and it's still fit, we still evolve it, we still do dramatic refactoring. And this would all not have been possible if we just had JavaScript. And of course, TypeScript and JavaScript became our first languages that we supported in first class with the Intellisense with code completion refactoring, right? So it was really also for us kind of the first showcase of what VS Code can do with regard to language support. At the same time, right, I think we helped TypeScript. First of all we gave them feedback, right? As we

grew for instance, as we grew to over 100,000 lines of code, we knew we must have a strong module support, module system. It was a continuous feedback loop back to TypeScript what our pain points are and what we need and of course also bugs and so on. What was also very helpful I guess is when other teams in Microsoft saw us, that we actually do TypeScript, they looked at us and then they also migrated, right? So I knew at least three teams when they saw what we do they asked how we do it and how

we like it. So in a way we also helped evangelizing TypeScript based on just how much we like the product. And I think it was just a very mutually productive symbiosis. There's just a lot of symbiosis between our two teams. I think our development philosophies are very similar and we're still I mean like one of our key users of TypeScript is VS Code. And so it's the cockpit that we all live in day to day. So we dog food not just our own language, we also dog food our own development environment. I have untold amounts

of respect for the VS Code team and the job they've done. It's fantastic and I love that tool. There were a couple of key ideas when we started TypeScript. One was that we wanted to build excellent tooling enabled by a static type system because that's how you get all of these productivity features like statement completion and refactorings, go to definition, code navigation. We also knew that we wanted to build a transpiler such that you could get modern JavaScript constructs like classes and modules and transpile it into idiomatic JavaScript that at the time didn't have these

concepts. And of course we needed a transpiler to erase the types also. And then there was a third angle that we never really pursued much and that was the idea of maybe we can somehow encode the types in some form of runtime information that the VM can pick up on and do a better job on picking class layouts in memory. At first we were meeting actually three times a week, Monday, Wednesday, Friday, and hammering through all the basics of what we wanted to do. So structural typing was a really important principle, which is a technical

thing that just means, when you compare two objects, what matters is what their structure is, not what their names are. The other really important thing was to use a lot of type inference, which is where people don't have to write down a lot of annotations to get a lot of value. And we kind of took the fundamental approach that, no, JavaScript was going to succeed, that the open web was going to be the platform and that we couldn't and shouldn't try to compete with that platform. We should try and provide additional tools that helped people

on top of that and that we should build those tools in a way which was as compatible as possible with everything in everything else being built in that platform. So if there's libraries being built we want to make sure that types can be used with those libraries it shouldn't compete with those and have its own libraries. Looks like what you would write, starts with JavaScript, ends with JavaScript, strict superset of the standard, debuggable as JavaScript. So it was a lot about making it easy to adopt, easy to abandon. And we also knew that in order

to appeal to the JavaScript community, we had to be open source. I think Steve and I from the get go and Luke, were convinced that no one would ever give us the time of day if this was not open source. But Microsoft at the time did not know anything about open source, really. I mean we did not know how to do open source development, we did not know open source culture, we did not know open source repositories, workflows, anything. Remote teams. We barely had remote teams. It was like swimming upstream. In that era, you have

to remember that most of Microsoft's business was driven off of proprietary licensed software that ran on your hardware. The idea that we would make something not only open source but also free, it was kind of like this question of like, what is the business value of that? Why are you doing something... It was just confusing to a lot of people. They just didn't understand why we would invest in something like that if it didn't directly translate into licenses. And then I think the other dimension of it is it kind of raised this question of what

does that mean broadly for Microsoft's broader stance on licensed software? Are you saying that we don't think that people should be paying for proprietary closed software? So it was just a matter of really shifting a lot of folks' minds about how they thought about what our business was and how it needed to evolve. For us to be successful with any framework or any tool in the web community in that era, it had to be open source, and I had to go convince the muckety muck management that that was what needed to happen. And so there

were many different layers of management that actually needed to weigh in and agree. There was both the Developer Division management at the time that needed to support this, there was an internal open source team at Microsoft that had been working on kind of open source relations. And then there was also the Internet Explorer team and they were obviously a pretty big juggernaut in terms of Microsoft politics. And it took about six months of advocacy to help people understand why, what it would take, what did it look like to actually work on something in the open.

Should we do this only for the Visual Studio product? Or should we go to where web developers actually most of them write code which for many was Sublime Text at the time, or Notepad++ or Emacs. But once we got to that then well where do we put this open source? Well, we have an open source repository called Codeplex. Of course it has to go there. Well, but no one's there. They're all on GitHub. Well you can't put it on, no. And so there was just a lot to work through in terms of what it would

look like for us to have a successful launch. Generally everybody assumed that the cards were stacked against us and we really had no chance of winning over web developers. Hi, I'm Anders Hejlsberg, Technical Fellow at Microsoft and I'm here to talk about TypeScript, which is a project that we've been working on for the last two and a half years. The conference where we launched this was the GOTO Conference in Aarhus in Denmark in October of 2012, and I'd been invited to speak there. And this basically wonderfully coincided with the launch window for TypeScript. So we

decided to make that the official launch. If I remember correctly, we actually released TypeScript publicly the night before the conference. And then Anders had got a session in the agenda that we hadn't published the sort of actual details of but there was just Anders speaking. And then it turned out that was his opportunity to kind of launch this. We had the opportunity to go meet with Lars Bak. His team was the team that built the original V8, VM, that's now powering Chrome and anything that runs JavaScript. They had increasingly gotten frustrated, or Lars had gotten

frustrated, with JavaScript and was working on a new technology called Dart which was basically a new language to replace JavaScript. There was sort of this contrast between the two approaches. Do you replace JavaScript or do you try to fix it? And I was sort of in the let's fix it camp and Lars was in the let's replace it camp. There's an interview that I think is still on YouTube with Lars and I where we were talking about the two approaches. The question is not whether JavaScript is broken, you know in places, the question is whether

it is broken enough to merit being replaced by something else. To me it looks like CoffeeScript with optional typing. There was a lot of confidence in the Dart team. They were like "wow, we're way ahead of you, we're doing great." And I remember feeling "hmm, I really like our approach. I really think it's better for developers but wow they're way ahead." To this day I have a lot of respect for Lars. I mean he's a brilliant engineer. I was less of a believer in replacing because I think JavaScript isn't broken enough, and I didn't think

that Dart fixed it enough either. And I think time has probably proven us right with our approach in TypeScript that it is fixable. Never try to fight the web right? I mean the web always wins and it won in this case too. This is making us look like professionals whereas previously people were really starting to doubt our competence. TC39 was was together and functioning and people were working on a massive, like what was to be the biggest probably ever upgrade to the language which was ECMAScript 6. But the interesting thing there was, there was all

these new things that were going to land in the language, but people weren't going to be able to use them. Because people were running like Internet Explorer 6 and Internet Explorer 6 isn't going to have new versions of JavaScript. That's just like not going to happen. So what TypeScript did was transpolation. You could write new code and have it run in old browsers, and that was brilliant. You know I don't like JavaScript. I actually think JavaScript's a bit shit. You had Java with its applets, you had Microsoft with Silverlight, and then you had JavaScript, and

then Google had GWT which is a way for Java developers to build JavaScript applications without having to write any JavaScript. And we weren't sure which one was going to win. Then TypeScript gave JavaScript that extra edge. It allowed JavaScript to be this more strongly typed language and made it appeal more to classical developers. I think some people like to not use TypeScript because it makes their code more complicated. And developers get a kick out of solving problems, even though it's a self induced problem. But they still get this like, "yay, I'm doing something good, I'm

solving a problem", even though that problem wouldn't exist if you're using TypeScript. Some of my colleagues say that "oh, I found your answer on Stack Overflow." It sort of still it still feels very, very odd to me. I was a C# developer primarily at that time and I sort of shied away from JavaScript. I felt like it wasn't type safe enough. I didn't have the tools to make sure that my code was right I didn't have the tools to refactor it. And that made me sort of very doubtful of whether JavaScript was an actual language

that I would enjoy using. And when I saw TypeScript, it was like, yes, this is exactly what I need, this is exactly what I want. And it felt amazing using it. Hi, I'm Tudor Golubenco. I'm the CTO at Xata. JavaScript was a bit of a mess so to say. There was a slight book written about JavaScript, the good parts, and it wasn't really like a really thick book. TypeScript brought a more modern way of developing to JavaScript. Overall, I think people understand that the benefits of the type system overcome the effort of adding the types

everywhere. At the moment about 40% of Webstorm users are actively editing TypeScript files. JetBrains introduced support for TypeScript 0.8 just a month after it was released. So it was at the end of 2012. The support landed in all six IDEs that we had at that time, including Webstorm. There was generally a trend in new compile to JavaScript languages. There was definitely CoffeeScript and Dart from Google was introduced around that time. So when we saw TypeScript coming from Microsoft, I think we all had reasons to believe that it's going to be something many people would be

interested in. It allowed people to get all the benefits of static type checking, without putting too much effort into learning a new language. I actually thought "wow, this is a great idea, but I think Microsoft is going to fuck it all up." It was just such a different company at the time. We, or they at the time, just did not know how to do open source. They would sort of fumble the ball every single time. As an outsider, you would see an open source project from Microsoft and think to yourself, "if I look at this,

am I going to get sued or something like that?" For most of my career, Microsoft was always the bad guy. I liked Linux and installing my own systems, compiling the kernel and so on. And Microsoft was like the antithesis of that. Are you hungry? Because we have cookies. You want a cookie? Microsoft used to be very aggressive about its competition to the point where the phrase "embrace, extend, extinguish" was kind of the motto of, it would take over a tooling area or an area of something by first embracing the existing standards, then adding to them,

and then making the Microsoft way the only good way, which is very reasonably why a lot of people did not like TypeScript at first. They were worried that this was a literal example of Microsoft extending JavaScript and then taking over. Thank heavens that is not what ended up happening. And now Microsoft is one of the better players in open source amongst the very large companies. But internally under the Ballmer style of leadership, Microsoft was very hostile to open source. I remember hearing stories from my teammates on Sway, the app I worked on in Office, that

they had to get permission to use jQuery, the standard most popular JavaScript library. And then one engineer, a very smart individual named Andrew Smith, was not sure, they were not clear on whether they'd allow TypeScript. So he maintained a separate version of the codebase in TypeScript for a long time until they finally got approval. And that's mind blowing to think of because today Microsoft just uses open source and contributes and VS Code and TypeScript and all sorts of things are open sourced. It was a slow process of transitioning from Ballmer aggressiveness, "open source is a

cancer", to Satya Nadella "embrace the world be a good citizen." Microsoft's strategy if it saw a technology that was emerging would be to do a fast follow copy to outcompete, to win over users, and then to kill the project. That was kind of the era in the late 90s and early 2000s that had carried over and it was certainly the browser wars and what had happened there, especially for the web community, was still top of mind for many. The way that we operate the team today, and we've done this for the last ten years at

least, is we kind of live by the adage that you win trust in drops and lose it in buckets. And so we think about every interaction with every developer that we are trying to serve as a moment that you can decide am I earning trust or am I losing trust? I never will use the word embrace in the context of open source. I won't even use the word extend, right? I won't use the word leverage. There are certain things that are kind of like third rail issues in the community that I would never associate open

source or Microsoft with that. I think today our position is really, really different and part of that is because our business model has actually evolved. What has started to happen over the last decade and a half now, as we move towards the public cloud and services, is that the business model is not as much about the proprietary software that you run on your hardware, it's about the hardware that we run and operate on your behalf. And so it's a really different kind of model in terms of what the core of our business model is. And

I think that that has been an essential dimension of why our stance on open source has really evolved. It was never a bad match. Like fundamentally, open source and Microsoft make a ton of sense together, because the mission is about empowerment. And that's true of open source. It really empowers developers because we can share infrastructure, and it's what Microsoft is trying to be. TypeScript was kind of the tip of the spear. It was the first big project that went out open source, and Microsoft's fear subsided a lot when everyone saw that that was a net

positive, both for the community and for Microsoft. It was one of the things that helped Microsoft be less afraid of open source and be ready to embrace it and try again with VS Code and then also put all of .Net out in open source. It was this sort of trickle from like 2012, 2013, 2014. You started seeing more of these projects get this sort of, I don't know, permission to embrace the same sort of model, and people were really excited to do it as well. When we started working on the TypeScript project, there was really

no open source project at Microsoft at all. To now, we're actually the largest contributor to open source of any company. Initially the reception to TypeScript was passionate but small. There was going to be a huge impact for big teams, for the kind of teams we had inside Microsoft who were hundreds of engineers working on hundred thousand line, million line codebases. But one of the things you saw when you worked with these teams who were adopting it was for all their interfaces, with all the libraries they were working with, they had to go write down the

definitions of the types for those libraries, and we of course made that relatively easy. But it was just work that you'd have to do. It was activation energy for any team who wanted to adopt this. I was worried for a long time that the potential for TypeScript was going to be limited in a sense by that upfront work that someone would have to do. Probably the biggest surprise related to TypeScript for me was on the day we launched. I think it was the day or maybe the day after we launched, this DefinitelyTyped project popped up.

DefinitelyTyped is like a mega repo. I don't want to call it a monorepo, it's massive. I don't know what it is at the moment, but it's something like the seventh most active repository on GitHub last time I checked. And given that people keep on writing new JavaScript packages, it may well be higher up the list now. It's long past the point where it's manageable by any one human being. Boris Yankov was very interested in TypeScript and was thinking, well, I need a central place to put my type definitions. I need a central place where type

definitions can live. And so he created a repository called DefinitelyTyped, I don't know how he got the name, on GitHub. Boris just took the Microsoft-written TypeScript definition for jQuery and put it into DefinitelyTyped. And that's really significant because Microsoft at that point could have stepped in and said "no, you can't do that." So it was really, really good that that didn't happen. Microsoft just like let it be. People could see that there was this independent thing that lived alongside TypeScript but that wasn't built by the TypeScript team that was just like there and functioning and

allowing the wider world to start consuming TypeScript. Initially there was 5-10 of us clustered around it and people would come and go and... Burnouts became like real. I think the TypeScript team were aware at this point in time that they needed to probably assist in some way shape or form because the project DefinitelyTyped was beginning to struggle. And they started to also see this problem potentially between the contrast between DefinitelyTyped, and an alternative project called Typings. There was divergence in the community because of this and the question is, which way do we go and how

does it work? So the big deal, the massive game changer from a DefinitelyTyped perspective, was when the TypeScript compiler was changed to cater for DefinitelyTyped outputting type definitions to a dedicated repository scope on NPM called @types. And that's the mechanism these days that you use to consume type definitions for libraries that don't ship their own type definitions, which is still a lot. You had 40 typings within just a few weeks or a few months, and within a year there was hundreds. And there was hundreds of contributors to it. I underappreciated just how impactful in a

sense this open source movement around the web platform and around GitHub and things was. The fact that that was possible, the fact that the open source ecosystem enabled that, the fact that the DefinitelyTyped project happened so early, I think is one of the biggest enablers of why TypeScript has become something that has had success over the last ten years. That's an important lesson I learned from TypeScript. Even if the response at first is really quiet, there might be a gem out there like Boris, who is going to do something that makes more difference than anything

you're doing to how important the thing is to the world. The initial reaction was slow, but it built in this wave that just never quit. Like it just kept rolling, kept getting bigger. So we kind of knew that there was some fundamental momentum here, that this was going to have some meaningful success. And I think I left probably six months after the 1.0 and moved on to actually an opportunity that was also in developer division. One of the things I was most sort of proud of was actually helping somewhat to drive through a new decision

framework about how we would do open source projects generally across DevDiv, and ultimately it became the policy for the company, and really shifting it from a mandate that everything go to CodePlex by default to actually saying, no, GitHub is going to be the place where we do open source by default. And so getting to kind of take that learning from what we did with TypeScript, and apply it not just to TypeScript but to what Microsoft would do overall, was sort of a fun thing to get to do in that new role. After you left, I

really missed your input. For me it was 2.0. If the thing has gotten to a place where I think "gee, everybody on this is doing it way better than I would do it and they're a great team", that's a great time for me to move on. But it was really bittersweet with this one because it was a really special project that I just really loved that time of going from the impossible odds to maybe this is possible. And that feeling of that, it's truly incredible. And some of the, we had a bunch of folks who

were working with us on TypeScript even before 1.0, who are still working on it, with Daniel, with Ryan, with Anders, with so many other folks who have been working on this now for ten years, and kind of continuing to make it better. And I think as well as the language design that they've done, just the work they've done to build up the community and the ecosystem around it and the partnerships they've done, with Angular and with other frameworks, and bringing in all these different constituencies who in other contexts might be seen as competitive with Microsoft.

Just enormous amount of credit for kind of where TypeScript is today. Anders and the team are amazing. What we kind of learned from AngularJS is that AngularJS was great to kind of get you going quickly but as the teams get super large it became difficult because you don't have type systems. And so we knew we wanted to have some kind of a type system inside of Angular in the next version of Angular we were working on because we wanted to make sure that Angular would scale. There was really no type system available and the closest

thing that existed was Closure Compiler within Google. But it wasn't really popular externally. And so AtScript was our kind of an ad hoc solution to add both a type system to JavaScript but also to add annotations that we needed for Angular . Okay you just don't want the glass to appear and disappear. So we introduced AtScript to the JavaScript community at a conference, ngEurope, in Paris in 2014 . We are not building a language. Just to make this clear we are not building a language, and the thing we're not doing, that's called AtScript. The reactions

were mostly positive, which was surprising given the ambition and ridiculousness of our proposal. And one of the positive reactions was actually directly from the TypeScript team. And they looked at the presentation and they reached out to us saying you are trying to build something that we've been already building for quite some time. How about we join forces? AtScript really was born out of a need rather than a want, like nobody wanted to work on this thing, but we needed it. So when Microsoft team approached us and said "hey, you know we're working on something similar

called TypeScript that will probably fit the same exact needs", as long as our needs were set, we were glad not to kind of work on it. For the TypeScript team, that is their bread and butter to kind of make a better language. We didn't want to put all of our bets only onto TypeScript. There was a meeting that we called for, Brad Green I believe was the main organizer, and we invited the TypeScript team, we invited JS compiler team, and we invited Flow from Facebook, and I believe Dart was there as well. We spent one

day just discussing where JavaScript was, where all of us were heading, what we needed. Interestingly, out of everybody in that room, TypeScript team was the only one who was really willing to collaborate with us. Everybody else, I don't think they were convinced, or they were not bought into the idea of working together. The challenge was though getting to make sure that Microsoft would have the features that we wanted, because out of the box, TypeScript was close to what we wanted, but it was not necessarily exactly what we needed. And so we had to work with

Microsoft on annotations and making sure that the annotations that they added to the system would be something that Angular could use. The compromise was that the TypeScript team came up with decorators because they were working with other people in the ecosystem. Mainly I think Yehuda Katz. And it was kind of a compromise in the sense that it allowed us to do static analysis which we needed, but it also gave kind of the side effect the behavior of decorators that other folks wanted. Decorators were largely, yeah that was an Angular bargaining chip. We made a decision

to go for it. We started including and considering TypeScript in the Angular codebase as of January of 2015. And in March there was Ng-Conf in Salt Lake City, where we did a keynote, and we invited JT to come on stage to talk about TypeScript and what they were doing, and we then announced that AtScript and TypeScript were merging, and going forward it's just TypeScript. At some point I said "hey Anders, I'm very sorry. Back in 1993, I think, I pirated a copy of Turbo Pascal." And he said "well, it's okay, if you get Google to

use TypeScript, we're good." It became much more clear over time that Angular would be written in TypeScript and TypeScript would be the main language that Angular's written in or even the only one that you had to use TypeScript to use Angular. That's great. And we think it delivered a lot of value for our users. And Angular of course being mostly an open source framework, that's cool. However it turns out Google internally wants to use Angular as well. So Google is a huge user. Angular is very important for us and having a new programming language at

Google is a very high bar. So Google is very conservative in adopting programming languages because it turns out programming languages are extremely important but also extremely expensive to companies. If you bring in a new programming language, you need to have a compiler, you need to have a typechecker, you need to have all the libraries available in it, you have to train all your engineers and so forth. And so that's a high bar. And so this created an interesting situation where the Angular team said "yes, we're going to do TypeScript!" But also we need to convince

Google to actually do TypeScript. So we built a small team. Alex Eagle, Radoslav Kirov, were part of it. Just the three of us started initially and we added some more people over time to essentially go through both the technical challenges to implement TypeScript at Google, but also go through this approval process which was kind of funny because we were the first language as far as I know, to actually go through this process. They essentially set up this process as a polite way of saying "no, you can't have this." And so what we did is we

actually said "yes, we will try to go through this process." And they were essentially laying down track as we drove over it. So they were imagining or making up the process as we executed on it, which was a bit of a fun situation. And ultimately after some years of deliberation, not too many, we did say "yes okay, TypeScript it is." And we merged the JavaScript-TypeScript teams at Google and built a shared future. I think at this point, if you're using any web frontend at Google, so something written actually in JavaScript, you have a very low

chance of not using TypeScript. So TypeScript really is pervasively in this monorepository that we have, and used in more or less everything that we do these days. This might sound like "oh it wasn't very difficult" but the list that we had at Google was, never in the history of Google, extended by another language. So at some point somebody said this is the list of languages that people will use at Google to build applications and nobody ever tried to add a language to that list, or if they tried, they failed. But he did it. The community

reaction to announcing Angular 2, which was essentially a rewrite of AngularJS along with TypeScript, was actually kind of mixed. There are people who saw this and saw this as a future, and they were excited. But there were also a huge number of people who didn't understand why we were doing this and to them it looked like an unnecessary complication. And this resulted in two things. First, TypeScript got a big boost. I think that that was the first big one, where we start to take off. Everybody who wanted to use Angular, and there were lots of,

there were hundreds of thousands of developers in the early days of Angular 2 that wanted to use it, they were just forcefully onboarded onto TypeScript, whether they liked it or not. And it also meant that Angular alienated part of the community, because they didn't want TypeScript. They wanted JavaScript, because that was the only real language, and that was the only thing that they wanted to use. So that gave a boost to React, because React was becoming popular at the time, and React's story was very much, "this is JavaScript." You use functions. This is not another

framework or library. You're just using JavaScript. And we just added a little bit of syntax around it. I'm glad to see that over the years the community has changed and pretty much everybody believes that this was the right step in the right direction and TypeScript is essentially an asset at this point. I don't think anybody would argue that you should start a JavaScript project today and not use type information for it. Now, it's never perfect. You make these goals and then you implement them. There were times where we needed to course correct. One of the

reasons that we hesitated about using TypeScript was that TypeScript was not a strict superset of ES (EcmaScript), but we needed it to be. And it sounded like that's what the TypeScript team believed they wanted to do. But on the ground there were things where they were implementing the language, that were not perfectly implemented in this spirit, and we needed them to course correct in this direction. When we started, JavaScript was a very small language with some very big holes in it. There were no classes. There are no modules. There's no notion of type annotations or

whatever. And fine, the type annotations that's one thing. But classes? I mean it would be hard to program without classes or appeal to programmers who want a more grown up programming experience, particularly when there's an idiomatic way to compile that into constructor functions and whatever. And that's what we did in the early versions. And you could think of that as us extending the language, right, and therefore going against our own design philosophy. But at the time, that was the right thing to do. Certainly all the large holes have been filled, right? There are now classes,

there are modules, there are all sorts of other features that weren't there before, destructuring what have you. I mean like tons of stuff. At this point JavaScript is a much more mature language and it's just not meaningful for us to build language features that are not in the purview of TC39 because that's just swimming against the current. We'd much rather participate in TC39 and have assurance that whatever comes out of there is something that we will be able to build a good type checking experience for. And that's the perspective that I think is super valuable

that we bring to TC39 in the work that we do with the committee there. I'm Rob Palmer, I work at Bloomberg, and I'm also the co-chair of TC39, the committee that defines the JavaScript language. The TypeScript team itself participates directly in TC39 to help guide the direction of JavaScript. We have what's called the stages process, which is a four-stage process, by which we gain increasing confidence that a feature, a change to the language, will ultimately land and become part of the standard. So to begin with, we have stage one, which is an idea, a definition

of a problem. Stage two, we then have quite a clear idea of what the candidate's solution could be. And then with stage three, we believe we've got all the details nailed down, and it's ready to be implemented. And then finally, if that all goes well and we've got two implementations, that becomes stage four, which then is guaranteed to be part of the standard. TypeScript was ahead of JavaScript in many ways. For example, the rollout of classes came early, and obviously from an experimental side, even decorators came early as well. Where those kind of deviations have

arisen, the TypeScript team have put in extra effort to heal and to converge the language towards the standard definition of JavaScript. One of the earliest issues on the TypeScript repo was a request for what became optional chaining, which is a way of accessing object properties in a very safe way, something that would be natural for TypeScript. And they saw this demand. The number of upvotes on the repo issue was huge. They came to TC39 and they joined the champion group that was advancing that proposal, and ultimately led it to stage four and it becoming part

of the language. And so this was a really great success, because it means that JavaScript and TypeScript are coherent, and on a great path for convergence. These are all people who care enough to work directly on the JavaScript language. They have opinions typically. It's the most used language in the world, so that impact is kind of hard to come by. I've really felt rewarded from it. It's one of the few really meaningful language standardization processes that actually exist in the world today. C++ is another one. Those are languages that genuinely have multiple implementations built by

different groups that have to agree on a common spec. And it's definitely work that we totally fully support. The thing I personally love about TypeScript is that I could probably turn up to work drunk, and still code pretty good. A lot of front end frameworks out there have a kind of framework war thing going on. That's the kind of dialogue that's around frontend you know, like especially, Remix VS NextJS VS Astro VS whatever else. But TypeScript is a bit more sedate, a bit more chill. And why is that? Well it wasn't really the case two

or three years ago. TypeScript had a big competitor. And that competitor was Flow. And Flow was looking like, it was something that came out of Meta, out of Facebook, and it was the big thing in terms of a typed language or a typed version of JavaScript. So if you looked two or three years ago, there would be a lot of people on Twitter saying "TypeScript is crap! TypeScript just doesn't work. TypeScript is not as good as Flow." People were actually trusting between Facebook or Microsoft. One would expect that two different technologies inside a company would

work really good together. But actually with big companies it's very difficult that teams that are very different actually talk and make sure that they are working together on building new features. So even if you would like that React and Flow, two technologies built by Facebook or Meta, they would work together closely, it's actually not true. And the types that you would get with Flow were worse than the types that you would get from TypeScript. I think there's a lot of really cool collaborations in Open Source. They all work to collaborate in order to make a

better ecosystem, that rises the tide, so that all boats float higher. Flow as is its name, sort of implies that it will try and figure out every single type in your system for you by sort of flowing the types through your system based on where it was used. So if you treated something like a number, then it would act like a number all the way through your Type system. Whereas TypeScript sort of said "hey, we're going to force you to write Types in certain sets of places, and if you do that, then we'll give you

a Type system." And these two sort of approaches have different trade offs at different levels, and in the end both teams sort of ended up building both bits in different ways. But it sort of felt like TypeScript eventually hit a point in its popularity that the Flow team sort of realized that trying to do all of the additional public open source work necessary to sort of commit to competing with TypeScript was sort of making it harder for them to actually build Flow for its main goal which was to be the type checker for the entire

of the Facebook code base. Flow just decided that they were going to start playing a different game than TypeScript. Flow, they've never made a secret of this. Their primary focus is to be a technology for use inside Facebook, that they so happen to also lop over the fence into the open source community. But we've always sort of had a design philosophy of we're designing this product for the community, those are our customers, and hey internal teams of course get to use it too and we'll help them along, but it isn't specifically for Microsoft's internal processes.

So the fact that TypeScript as a community is so chill these days is because there's nothing really to fight about. TypeScript just won, really. It sort of overcame all of its competitors. It integrated with everything. TypeScript is the new default. And so we just agreed that TypeScript was good. And I don't think you're going to see that in many other tool chains, in any other situation, because TypeScript is on a different level from most other front end tools, because it just sits above everything or rather it sits below everything. It sits between your front end

framework and JavaScript itself and nothing else is on that level of the pyramid. For most projects really, TypeScript just beat Flow in all these different metrics. And the metrics were Angular, React, Vue, Svelte. They brought in first class TypeScript integration and TypeScript worked really hard to integrate with them and it just beat things like Flow, like CoffeeScript. Those things just never had as good an integration as TypeScript had. And it just meant that TypeScript became the default choice for all of those frameworks. To me it's like, is a hot dog a sandwich? I don't know.

You can eat it, you cannot eat it. It's up to you. For us, feature prioritization is really driven by the JavaScript landscape and what kind of code people are writing and what kind of support they need from the TypeScript to write those kinds of programs. If you look at every single language feature in TypeScript, it's always something that you can trace back to some pattern of programming that's common in JavaScript or it could sometimes even be specific libraries and how they work. You could imagine a world where we said, "oh we don't want to work

with Babel, we don't want to work with esbuild, because we want to be our own thing." But no, we said we've got to embrace the JavaScript development ecosystem, provide our tooling as something that can slot into other tools, not try to be the only game in town. Just try to work with everyone so that no matter what your build chain looks like, TypeScript is something that you can use. We've done work with Evan on Vue and we've done work with the React team, with the Angular team. I sort of think of us as the Switzerland

of technologies here. We're not married to one particular framework or one particular methodology right? We want to really generally just be the best development productivity tool for the ECMAScript / JavaScript ecosystem. The first time that TypeScript really saw massive adoption was when it paired itself with Angular and they decided to work together. The next big one was when it started to support different features and different type level syntaxes that allowed it to express what different front end frameworks were doing. So it supported KnockoutJS, it supported Ember, and these were all through different syntaxes that it

added to the language. The next big one was React, when it added support for JSX. And now TypeScript has reached such a pinnacle, it's reached a huge upward point in the community that people say "oh, WE integrate WITH TypeScript." My name is Ryan Dahl. I'm best known for creating NodeJS. In my mind TypeScript, is a natural extension of JavaScript. It adds types that allows you to construct more complex programs. As kind of the natural evolution, at least in my mind of JavaScript, I think it was clear to me that it should be a part of

a future runtime for JavaScript. Deno internally converts TypeScript to JavaScript. So TypeScript has this really nice property that it's very easy to strip out the types and what's remaining is JavaScript. So you don't need like a very complicated compiler pass to kind of quickly translate TypeScript into JavaScript. Deno has all of that built in. The type checking algorithm, having the TypeScript compiler, is also built in, but there's kind of two separate activities that it does. One is type stripping just to run the resulting JavaScript and the other is the type checking itself. Deno has all

of this kind of built in unlike with kind of Node and tsc where you have to kind of set up build processes to get that working correctly. TypeScript is a big selling point for Deno. I mean we use TypeScript all internally. Like any website that I would be programming now or any backend tooling, I would be using TypeScript. I think most developers these days feel that way. And yeah being able to not have to set up any tooling any build processes for this I think is definitely a reason people are using Deno. When we started

TypeScript obviously we were using TypeScript at Microsoft and then we started to hear about companies outside the company that were using TypeScript. And I think when Netflix announced that they were using TypeScript, I was like "wow, Netflix! That's like a real company." Which is funny when you think about it because it's obviously smaller than Microsoft, but you really feel like you've made it when it's a company with a really well respected engineering culture that chooses to adopt TypeScript. And I kind of feel like I have those wins almost every year now, because you hear you

know yet another company successfully migrating to TypeScript. And it's almost sort of a non event at this point but you do hear about it and it still feels good you know. Airbnb moves over or Bloomberg talks about their stuff, and you just feel proud. Bloomberg's made some of the biggest PR contributions to the language. For example the delivery of private fields and private methods. So we actually put together this plan and we presented it to the head of engineering. He read through it and reflected on it saying, "so, the future of JavaScript at Bloomberg, is

to change to TypeScript?" And that's exactly what we did. We made this voluntary. Any team that wanted to adopt it could pick it up. And we found within the first year, 200 projects had opted into this first class TypeScript support, and none of them went back. With AG Grid using TypeScript, it makes us more efficient. And at the end of the day, that's what writing software is about. It's about how to make software that meets the business requirements in the most efficient way possible and have it as maintainable as possible. That's what all these tools

come down to. And TypeScript enables us to do that. There's an anecdote you know, we set out and the PM was talking to someone and he said "TypeScript is going to be bigger than C# at one point." And the other person just laughed, just laughed, because the notion was preposterous. And here we are. And I think TypeScript is bigger than C# depending on how you measure it at this point. And that to me is just unbelievable. When we set out I thought static types are really cool. I like static types, but I can understand why

someone might not like static types. I think we have a ceiling of 30, 40, 50% of JavaScript developers. Maybe 60% in my wildest dreams. And yeah now depending on how you slice it, if you count people using static types in JSDoc, if you count TS files, if you count other stuff, maybe the sky is the limit. The State of Developer Ecosystem Survey, JetBrains runs it each year. Last year, 2022, we collected the responses of more than 30,000 developers. In 2017, when we ran our first Developer Ecosystem Survey, 12% of the users mentioned having tried using

TypeScript, during the previous twelve months, whereas a year ago, in 2022, it's already 34% of our participants that mentioned TypeScript as the language that they have tried during the last twelve months. And if we talk not about using TypeScript as ONE of the languages but using TypeScript as one of the THREE primary languages, in 2022 there were 18% of the respondents that use TypeScript as their primary language. In 2019, it was only 9%. This says that the number is rapidly growing. You can kind of think of the TypeScript numbers as actually being played down a

little bit. There are so many developers out there who are using TypeScript and don't even realize they're doing it. There's an alternative way of using TypeScript which is just by adding these things called JSDoc comments into JavaScript. What that means is you just have some code and then you just write a comment above that code and you use a special syntax. And that special syntax basically gives you types on that function or that thing. And so lots of folks out there say "I'm sticking to JavaScript, I'm sticking to JavaScript." But really what they're doing is

they're using TypeScript with JSDoc annotations. TypeScript is not just a language, it's an entire set of tooling all around JavaScript. TypeScript has just enabled IDEs like VS Code and WebStorm to give you so much extra information. Even if you're not writing TypeScript yourself, if you're just writing vanilla JavaScript, your IDE can understand that code using the TypeScript parser and then give you those hints to say these are the properties that are available on this object. So I think it's really a way that people have gotten used to TypeScript without using it themselves. So when they

transition into TypeScript, they're getting that same experience. But they've been reaping the benefits all along thanks to the IDEs being able to leverage the powers of TypeScript. If you use VS Code and you write JavaScript, then you are a TypeScript user. Because the language service that powers anything that happens in there is the TypeScript compiler. Let me put it this way, there's TypeScript the syntax, and there's TypeScript the tool. TypeScript the syntax is, yes ,that's a superset of JavaScript with type annotations and interface declarations and what have you, and you need some tool to erase

that before you can run the JavaScript. But then there's TypeScript, the tool. And TypeScript the compiler is perfectly happy to analyze JavaScript and infer types, or perfectly happy to analyze JavaScript with JSDoc annotations and get the types from that. Or, it's perfectly happy to analyze combinations of JS files and TS files in the same program and get the types, sometimes from manifest type annotations, sometimes from JSDoc, sometimes from inference. It doesn't really matter. And I think that's the beauty of it right? You use whatever works for you. If you are very keen on having an

inner loop where there's no transpolation required, you just want to be able to save and run, great, then you're going to probably be using JSDoc annotations because those can stay. But if you're keen on having something that's more readable, then you might go for the manifest type annotations. And it turns out most people generally do because they use bundlers anyway. And so hey if you're bundling you might as well transpile and erase the types. It's no extra cost. You have to read the files and parse them out anyway so you're there. And so that's what

esbuild and SWC do. The minute you have that packaging or bundling in your inner loop, you might as well use the TypeScript syntax because it adds basically no cost. But not everyone feels that way, and that's fine by us. When we think about how do we improve the TypeScript experience, a lot of that is really about how do we improve the JavaScript experience. That has to do with both JSDoc, and inference, and other tricks that we can do to make the JavaScript experience better. So when I hear about big projects like, I think it's Svelte

and Webpack, using only JSDoc, some people look at that and they say, "oh they're moving away from TypeScript." And I say no. They're embracing TypeScript. They're embracing this other flavor of TypeScript that we've made. That works too and we can deal with that. And it's kind of a win win for everyone. There's probably two elements at play in terms of why we're not aggressive about pushing TypeScript. We know that developers don't like being marketed to and that at the end of the day the most important thing to deliver on is developers are actually satisfied with

the product. That they like it. If you thought about it as an investment, right? You could invest in DevRel to evangelize the technology, or you could invest in the product and actually just make the product better. We think the most important thing is to focus on the product. I would say that there's no actual TypeScript community, because they don't need it. They are not trying to sell you TypeScript. You're using TypeScript because it's good for you. Wherever you find JavaScript or a JavaScript framework, like React or Angular or Vue, you're going to find TypeScript as

well. TypeScript plays so well into all of these things that we're already using. I really think that the big key to what makes software successful is the ecosystem around it. Like if you think of your iPhone, all of the aspects of an iPhone, they fit in so well with all of the things that you're already doing. The next purchase that you make needs to be able to integrate with your iPhone. Now the next software purchase that I make, or the next library that I adopt, needs to be able to support TypeScript. A TypeScript community definitely

exists. There's still people out there who don't want to use TypeScript. Otherwise, I believe basically all front end developers would be the TypeScript community. You have like an inflection point where the maintenance cost of not having any types and validating at runtime gets really, really high. But TypeScript is a bit more consistent by having all that complexity you deal with later and pushing it up front to the start of your development flow. It's kind of like brushing your teeth or eating your vegetables. It's hard to do upfront, because it's not a habit. But once you

have TypeScript embedded in your project, it's like it is that habit that you don't want to get rid of. In CoffeeScript, I never had to scroll. But don't ask me to look at those codebases today and have any idea what they do. It just seemed obvious that it was like my responsibility as a library writer to embrace TypeScript, because a little work on my side, and every one of my users could benefit. So Solid, almost from when it was first open sourced, has been built on TypeScript. JavaScript is still shit. TypeScript makes it easier to

manage the shit. It made me go from hating on JavaScript to using technically JavaScript for every single thing I build. I would argue that Microsoft understands developers better than the React team even does. Now that a lot of companies are starting to hire and look for developers who have TypeScript experience, it's kind of you know being a front end developer, "do you know React?" The second question they will ask you is like "oh, have you worked with TypeScript?" I don't want to learn another language. It's not another language, it's just a little bit of descriptions

on top. The first time you use it, you go "oh, I see why people like this type of thing." I built a project in TypeScript the other day and I didn't look at the docs once. When you've got people in the industry who everyone looks up to starting to say you know what? I'm adopting TypeScript into my own projects, and this is why... It now starts to feel like the doors open a little more. And I think that is starting to happen in the TypeScript ecosystem and has been happening for a little bit now. And

that's why I think it's starting to rampantly grow. The really interesting property about TypeScript is that it's kind of meant to disappear. I think what the TypeScript team really want is to improve JavaScript, or at least that's the feeling I get. And adding types into the language is just a kind of way to speed that process up, because without types you can't have autocomplete, without types you can't have sensible errors in your IDE. I think what it's doing, what TypeScript is doing is it's getting itself ready for a future where it doesn't need to exist

anymore. If you look at the way that the TypeScript team is participating in the evolution of JavaScript, Daniel Rosenwasser is on the TC39 committee, then I think one day, we will have a future where TypeScript doesn't exist. And I think that's because JavaScript itself will have either adopted types or have made space in the language where you can add types, and then TypeScript will just be a CLI that you run to just check that your JavaScript is running okay. And I think that the days of writing TS files might be numbered. It's a big number,

but they might be numbered. Just like with Babel, there is this moment where this entire set of communities could re merge back into each other. And like right now, TypeScript is a fork of JavaScript. And it would be incredible if we could get the Type syntax into JavaScript, so that all of those people that had to migrate to TypeScript for their tools and this additional syntax, that allows them to be able to say "hey this is a string", bring all those people back into JavaScript and make JavaScript a much bigger tent, and defork TypeScript. That

I think is a project I'd love to see TypeScript put more effort into. One thing that is holding us back today is that we don't have a standardized notation for the types in ECMAscript language. I would love to see that because I think that would enable more innovation in this space, where if the syntax was standardized then we could have alternative implementations. And whenever you have more than one implementation, the ecosystem becomes healthier. The main thing that I would want out of my tooling at this point is just to be faster. TypeScript is pretty fast.

But speed is something that you could always benefit from. And the only way that could probably be gotten at this point, is to not use JavaScript itself, but to use something like Rust. And there are many projects out there that show that Rust, and especially when it comes to parsing and manipulating AST trees, is significantly faster. I think right now the biggest challenge that TypeScript is facing is onboarding new people and explaining errors to them. Because the way that you visualize type errors in your editor right now is not a very rich display for most

people, and you're starting to see people work on this space. There's this extension, the Total TypeScript extension from Matt Pocock, which is an excellent way to explain TypeScript errors in more human readable English. But I think long term I want to see more exploration in alternate ways of more rich ways to visualize your TypeScript issues. Now that TypeScript has become so dominant in the industry, it no longer needs to advocate and justify its existence, it needs to be better for newcomers. TypeScript has become pretty dominant. I don't think that that means that we stop innovating.

I think it means that there's space where we just continue to try to do better. Because the thing that excites our team is just making our developers happy. That naturally gives us fuel to try to do better. You can just use plain JavaScript, you can fork TypeScript, it's an open source project, you can do whatever you want with it. There's still competition, there's competition on speed. There's alternative compilers these days that people are trying to build. Alternative type checkers where people are trying to rebuild the type checker and be faster. And that keeps us motivated

right? Because people want a better developer experience constantly. One of the things we're really looking at right now is performance. As TypeScript codebases get bigger and bigger, people are experiencing longer and longer build times, just because TypeScript is doing more and more work. So we're looking at how can we make just the core operation of TypeScript be faster. How can we do less work on each build? How can we surface that information in the editor more quickly? Another thing we're always thinking about is compatibility and then just thinking about next steps as we work with

the ecosystem more broadly. There's always ways that we can improve our interop with other parts of the tooling out there. I'm very much a believer in the long game. You don't create programming languages on a short time frame. It's ridiculous to think that you can create a programming language and have it be important and adopted and whatever in anything less than five years because programmer expectations are insanely high today. It's not enough to just define a language and write a compiler for it. No, that's table stakes. But you've got to have great tooling, you got

to have all these services, you got to be open source and you got to have a team that's willing to address the issues and you got to nurse it along and you got to write documentation. It's a big undertaking. I often joke, show me a perfect programming language and I'll show you a language with no users because those are the only ones that can actually be perfect. Some people ask well if you bring TypeScript into JavaScript don't you lose your job? Right? We're going to be the ones to type check it. We're going to be

the type checkers. You need someone to write that type checker. And so TypeScript doesn't cease to exist. It just works on a different file format or something like that. So I don't think that we're going to be going anywhere. I feel like what I'll remember of course is a lot of the brilliance on the team, the ingenuity, the moments where I got to be in the room when we came up with this or that or I got to be the person to come up with those concepts. And that's always going to be extremely rewarding but

it's definitely going to be the people that stick out to me the most. There's something about being in that situation when no one else believes that still I feel like yeah if I needed to work on something with Luke tomorrow no problem we could do it. We got to sort of invent a new kind of type system really motivated by tools and by IDE experiences as the primary goal. And I think there weren't that many examples of that certainly not in the JavaScript ecosystem and really only a few even in academia at the time. It's

a really amazing experience to have. And one of those things that you're really lucky when you get to have one or two of those experiences in your career of building something and sort of feeling that kind of excitement. To be able to help create a situation where people are really proud of their work, feel like they're doing something really meaningful, still loving it 12-13 years on, to me I'm really proud of that. And then the other thing I'm proud of is that TypeScript was really the beginning of Microsoft getting really comfortable with open source, of

changing its policies around open source. It's a blueprint for how do we do open source at Microsoft. In a sense we cut our teeth with TypeScript and we've reused that pattern again and again and I would say this was both TypeScript and Visual Studio Code and making .Net open source, I think all of those different actions kind of laid a foundation that made it acceptable for Microsoft to be the buyer of GitHub. I think that had we not had any successful open source projects by that point the community would have looked at that with a

lot more hostility. It's been a long journey it's a continuing journey. We've been at it now for twelve years and in my wildest fantasies I had never imagined that we would get the kind of adoption that we've gotten. I think we used to jokingly dream about "oh my God, if we could appeal to 25% of the JavaScript community that would be unfathomably fantastic, right?" And now we're like way bigger than that. I never thought that that was going to happen and I'm immensely proud of it. I think it's what keeps us going is just seeing

the joy that people have in using the tool and they're not shy about expressing it on Twitter and on our forums and issue trackers and Stack Overflow and whatever. And it's just fantastic to see that.. "I'm never going back to JavaScript." "Writing code in JavaScript feels like skydiving without a parachute" or "coding naked", or it's like all these funny analogies right? Ultimately, you want to go through life feeling like what you worked on made a difference, and this is really feeling like we're making a difference, and I'm just super proud of that.