TypeScript Origins: The Documentary

I'm Steve Lucco. I work in developer software and started the TypeScript team. We were trying to make the JavaScript engine that was in Internet Explorer much faster. When we started, we were way up here, like off the charts in the main benchmark that measures how fast you are at JavaScript. At the end of 2010, we caught up and surpassed 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 fast engines to run them. And the next thing we did was try to invest in better tools.

We were starting to create an editor that eventually became VS Code. And I got to about 7000 lines of code and I got really angry, having moments where it took me half a day to find a bug because I had misspelled a variable name or I had used the wrong API in the JavaScript library or for example , in jQuery or something. It takes forever to track these things down because you don't have any information that a tool like a compiler can use to find these problems before running the code. And then you're just sitting in the debugger.

So I started to think that it was more important to create a tool than to finish the editor. That's when I started writing TypeScript. You were seeing this huge rise of the web platform. Not just at Microsoft but across the industry. There were fast JavaScript engines that were becoming the norm. V8 had been released maybe a year and a half before this. Microsoft was obviously working on the Chakra engine. There were fast engines coming from Mozilla and other players, so the web had become 10 to 100 times faster. One day, my boss's manager walked into my office and said, "Luke, we'd like you to work on a different team within the company." Which is never something you necessarily want your boss to say, but in this case it was kind of an opportunity to work on programming languages ​​and development tools for an area that was becoming increasingly important to Microsoft and I really think that for the entire industry. , who was working on the JavaScript language and tools.

One of the people I talked to was Steve Lucco and he and I talked about a bunch of things about what we could do with kind of a bigger investment in JavaScript. One of the things that really excited him, and I think we both spent quite a bit of time talking before I even joined the team, was the opportunities that existed to potentially bring in much richer kinds of tools on top of JavaScript. language. And in particular, what we would need to do to extend the JavaScript language to support it. Steve had been talking to a lot of other engineering managers and VPs and other people in the company who were facing a similar challenge, who were moving much of their development from desktop applications built with C# or C++ and using all the tools. that we were building with Visual Studio, they were moving to writing them with JavaScript, and the tools that were available to support them were not as mature.

Excel, Word, PowerPoint, you know the classic types of productivity software, they were all developed in C++ and were absolutely huge code bases. But they were rich client applications running on Windows and we needed them to be available in the context of the browser. So we took these legacy code bases that were millions of lines of code with thousands of internal Microsoft developers working on them who had C++ experience and now we were basically telling them that they needed to create an application that would run in the browser in JavaScript. JavaScript, as it existed at the time and has certainly evolved considerably since then, was not really 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 achieve that? We started giving talks about DevDiv, Microsoft's developer division, and at one of those talks, Anders Hejlsberg was in the front row. After that, Luke and I talked and said, "Oh, you know, Anders may have enough time to join us and help us." Luke and I had a lot of pieces of the puzzle, you know, classes, object types, enums, and so on, but we knew that Anders would really help us put those pieces of the puzzle together in a great way. I think at first Anders was a little 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 a little bit deeper into the problem space that he looked at it and said, "You know, actually, I think there is language design work programming". That has to be done here." And Anders is the programming language design guru at Microsoft. I remember being intrigued by this. Languages ​​have always fascinated me and when something new comes along you know where you're going "Oh, that sounds like an interesting problem! " And this really seemed like an interesting problem. We were seeing more and more teams within Microsoft doing strange things to write their JavaScript applications.

And in particular, they asked us if we would produce a technology called Script#, which was a transpiler that would transpile C# to JavaScript And I was a little curious as to why you would want to develop your JavaScript that way. And it turns out that was the only way that a large team, that at least they had found, that was the only way that a large team could. having developed development processes and the tools they were used to in languages ​​like Java and C#, with statement completion and going to definition and safe refactorings and type checking before running the code.

So they would write in C# with a fake runtime library and then transpile it to JavaScript and then run it in the browser. And that surprised me a little. I'm like "wow, that's crazy." I mean you're willing to go so far from your goal just to get a better experience. What if we thought about what is wrong with JavaScript and if there is a way to fix it? To some extent I was hesitant about building something new, but in many ways it's not something new, it's an improvement on something that already exists. And I was actually quite attracted to that because there is a basis and it's not like trying to invent solutions from scratch to problems that everyone has already solved.

There is JavaScript. It's more about how do we refine JavaScript, how do we add a type system to it? That's a fascinating idea. And then, of course, you realize that 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 God, this is kind of interesting." There aren't many type systems like that out there. But at first I only helped them with the design. Steve built the first compiler prototype, compiler 0.8. It had this JavaScript engine that was compatible with the entire web.

So I took the parser from that which was written in C++ and ported it to JavaScript. And that's why TypeScript supported the entire web and liked any JavaScript you threw at it from the beginning, because it was actually launched from a fully supported parser. And then once I had the parser fully supported, I started adding optional type annotations to things like function parameters so I could check them. And then I took the errors that I had that made me angry and injected them into my code, and the compiler found them right away. And right then, we had this great opportunity to hire the Eclipse team led by Erich Gamma, who is an incredible architect.

He had created some of the most impressive IDE experiences on the market at the time. I gave the VS Code prototype to Erich's team, but I made them agree to one thing: when we have enough TypeScript so you can actually use it, try using it in creating VS Code and give us feedback, because we desperately need feedback. As soon as possible and every day. We started very small in this building and our final product was this web-based editor. I must say that at first I was a little scared of the challenge. Web-based development tools need JavaScript, and of course my first concern was how to create JavaScript at scale.

And a side note on that, which I learned from honing my JavaScript skills, what also scared me was that JavaScript, the ultimate guide, is a little heavy. JavaScript, the good parts are a bit light, right? So this didn't boost my confidence, but it's still more anecdotal. I make my first trip to Redmond to meet with other colleagues, other leaders at Microsoft, and one of them was Steve Lucco. So he told me for the first time that he knew there was work on that, on this TypeScript initiative, which was Strada at the time. And I have to say, when I saw that, Steve even had that method running, right?

When he writes an object, he creates ".", Then he gets a code that suggests the methods, which are all implemented TS tools. This was almost love at first sight. It's very difficult to create tools like code completion or refactoring when you don't know the types. Because without types you have to guess and speculate, what could this type be? But once you have a type then of course you're happy from a tooling point of view because you can find out, for example, where this object is used because it has a type and what others are affected when I change the type, TRUE?

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

So I was very excited and very happy. I already believed in the power of static analysis, of statically typed languages ​​at that time, and that's why I set out on the journey. At first I was skeptical. I just absolutely hated anything that could get in the way of getting this instant feedback. I think maybe six months into doing VS Code, we wanted to refactor our code to make it cleaner and make it obvious which file matters which other files and stuff like that. That's when I realized how important it is to be able to change the code.

After doing all that, I thought, my goodness, doing JavaScript is like carving code into rocks. Once you've written this amazing JavaScript code, you'll never touch it again because you don't remember what you did six months ago. You can never refactor the code and you can't find bugs. It is impossible. You have a property called ID and you want to rename it to modelID and you find a replacement. Good luck. TypeScript has helped us in two different ways. It has helped us build VS Code. The second thing is what we basically ended up shipping. Without TypeScript there would be no VS Code.

It is impossible to achieve this. Code navigation, in the sense of searching for references, going to definitions, searching for implementations, searching for definitions. Yes, you need a linguistic brain to reason about the code you've written. And all of this is TypeScript. I remember it was a bumpy road at first. We were always running into all kinds of compiler errors, but Steve was fantastic. So basically, we would be like, overnight, we were taking advantage of the time zone difference. I emailed Steve overnight and the next day overnight he would email us the "oh there's a new compiler" zip.

And then we tried it and it was solved. And then you look at it and it's like, "God, 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, someone uses a VS Code feature, which is mind-blowing. All my computer friends use VS Code. Yes. So I'm very privileged to be a part of this. And when I look back, our codebase is now over twelve years old and it's still in shape, we're still evolving it, we're still doing dramatic refactoring. And all this would not have been possible if we only had JavaScript.

And of course, TypeScript and JavaScript became our first languages ​​that we supported first class with Intellisense with code completion refactoring, right? So it was also for us kind of a first taste of what VS Code can do with regards to language support. At the same time, I think we helped TypeScript. First of all we gave them feedback, right? As we grew, for example, to over 100,000 lines of code, we knew we had to have strong module support, a module system. It was a continuous feedback loop towards TypeScript, what are our pointsweak and what we need and of course also the errors etc.

What was also very helpful, I guess, is that when other teams at Microsoft saw us, who were actually doing TypeScript, they looked at us and then migrated too, right? So I met at least three teams, when they saw what we do and asked us how we do it and if we like it. So in a way, we also helped evangelize TypeScript based on how much we like the product. And I think it was just a very productive symbiosis for both parties. There is simply a lot of symbiosis between our two teams. I think our development philosophies are very similar and we still think that one of our key users of TypeScript is VS Code.

And it is the cabin in which we all live day to day. So we not only feed our own language, but we also feed our own development environment. I have untold respect for the VS Code team and the work they have 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 create great tools enabled by a static type system because that's how you get all these productivity features, like statement completion and refactoring, go to definition, and code navigation. We also knew we wanted to create a transpiler that would allow us to take modern JavaScript constructs, like classes and modules, and transpile them into idiomatic JavaScript which at the time didn't have these concepts.

And of course we also needed a transpiler to erase the types. And then there was a third angle that we never pursued much and that was the idea that maybe we can somehow encode the types into some kind of runtime information that the VM can pick up and do a better job of selecting class layouts. in memory of. . At first we met three times a week, Monday, Wednesday and Friday, and went over all the basics of what we wanted to do. So structural typing was a really important principle, which is a technical thing that simply means that when you compare two objects, what matters is what their structure is, not what their names are.

The other really important thing was using a lot of type inference, which is where people don't have to write a lot of annotations to get a lot of value. And we sort of took the fundamental approach that no, JavaScript was going to be successful, 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 to provide additional tools that help people on top of that and we should build those tools in a way that is as compatible as possible with everything else that is built on that platform.

So if libraries are being created, we want to make sure that the types can be used with those libraries, it shouldn't compete with them 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 very much about making it easy to adopt and easy to abandon. And we also knew that to attract the JavaScript community, we had to be open source. I think Steve and I from the beginning and Luke were convinced that no one would give us the time of day if it wasn't open source.

But Microsoft at that time didn't really know anything about open source. I mean, we didn't know how to do open source development, we didn't know the open source culture, we didn't know the open source repositories, the workflows, nothing. Remote teams. We barely had remote teams. It was like swimming against the current. At the time, you have to remember that most of Microsoft's business was derived from licensed proprietary software running on its hardware. The idea of ​​us making something not only open source but also free, it was kind of like this question: What is the commercial value of that?

Why are you doing something? It was confusing for a lot of people. They just didn't understand why we would invest in something like this if it didn't directly translate into licenses. And then I think the other dimension is that it raised the question of what does that mean broadly for Microsoft's broader stance on licensed software? Are you saying we don't believe people should pay for closed, proprietary software? So it was just a matter of changing a lot of people's mindsets about how they thought about what our business was and how it should evolve. For us to be successful with any framework or tool in the web community at that time, it had to be open source, and I had to go convince management that that was what had to happen.

And so there were many different levels of management that really needed to weigh in and agree. At the time there was Developer Division management that needed to support this and there was an internal open source team at Microsoft that had been working on some sort of open source relationships. And then there was also the Internet Explorer team and they were obviously a pretty big giant in terms of Microsoft policy. And it took about six months of promotion to help people understand why, what it would take, and what it was really like to work on something openly.

Should we do this only for the Visual Studio product? Or should we go where most web developers write code that for many was Sublime Text at the time, or Notepad++ or Emacs? But once we get down to it, where do we put this open source? Well, we have an open source repository called Codeplex. Of course you have to go there. Well, but there's no one there. They are all on GitHub. Well, you can't wear it, no. So there was a lot to work out in terms of what it would look like for us to have a successful launch.

In general, everyone assumed that the cards were stacked against us and that we really had no chance of winning over web developers. Hi, I'm Anders Hejlsberg, a technical fellow at Microsoft, and I'm here to talk about TypeScript, which is a project 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, Denmark in October 2012, and I was invited to speak there. And this basically matched the TypeScript launch window beautifully. So we decided to make that the official release. If I remember correctly, we released TypeScript publicly the night before the conference.

And then Anders had a session on the agenda that we hadn't published the actual details of, but only Anders was talking about. And then it turned out that it was his chance to release this. We had the opportunity to meet with Lars Bak. His team was the team that created the original V8 virtual machine, which now powers Chrome and anything that runs JavaScript. They had become increasingly frustrated, or Lars had become frustrated, with JavaScript and was working on a new technology called Dart, which was basically a new language to replace JavaScript. There was a kind of contrast between the two approaches.

Do you replace JavaScript or try to fix it? And I was 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 some places, the question is whether it is broken enough to deserve to be replaced by something else. It looks like CoffeeScript with optional writing to me. There was a lot of confidence in the Dart team. They said, "Wow, we're way ahead of you, we're doing really well." And I remember feeling "hmm, I really like our approach.

I really think it's better for the developers, but they're way ahead." To this day I have a lot of respect for Lars. I mean he is a brilliant engineer. I didn't believe in replacement that much because I think JavaScript isn't broken enough and I didn't think Dart fixed it enough either. And I think time has probably proven us right with our focus on TypeScript that it can be fixed. Never try to fight the web, right? I want to say that the web always wins and in this case it also won. This makes us look professional, whereas before people began to doubt our competence.

TC39 was up and running and people were working on a huge, like probably the biggest update ever to the language, which was ECMAScript 6. But what was interesting was that there were all these new things that were going to land. in the language, but people were not going to be able to use them. Because people were running Internet Explorer 6, Internet Explorer 6 will not have new versions of JavaScript. That's like it's not going to happen. So what TypeScript did was transpolation. You could write new code and run it in old browsers, and that was cool. You know I don't like JavaScript.

In fact, I think JavaScript sucks. You had Java with its applets, Microsoft with Silverlight, and then JavaScript, and then Google had GWT, which is a way for Java developers to create 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 advantage. It allowed JavaScript to be this more strongly typed language and made it more attractive to classical developers. I think some people like not to use TypeScript because it complicates their code. And developers enjoy solving problems, even if it is a self-induced problem.

But they still get something like "yeah, I'm doing something good, I'm solving a problem", even though that problem wouldn't exist if you were using TypeScript. Some of my colleagues say that "oh, I found your answer on Stack Overflow". It still seems very, very strange to me. I was primarily a C# developer at the time and kind of avoided JavaScript. I felt like it wasn't safe enough. I didn't have the tools to make sure my code was correct. I didn't have the tools to refactor it. And that made me really doubt whether JavaScript was a real language that I would want to use.

And when I saw TypeScript, I thought: yes, this is exactly what I need, this is exactly what I want. And it was amazing to use. Hello, I'm Tudor Golubenco. I am the CTO of Xata. JavaScript was a bit of a mess, so to speak. There was a short book written about JavaScript, the good parts, and it wasn't really a very thick book. TypeScript brought a more modern way of developing JavaScript. In general, I think people understand that the benefits of the type system outweigh the effort of adding types everywhere. Right now, about 40% of Webstorm users are actively editing TypeScript files.

JetBrains introduced support for TypeScript 0.8 just a month after its release. That's how it was at the end of 2012. Support came to all six IDEs we had at the time, including Webstorm. In general, there was a trend in new compilation in JavaScript languages. CoffeeScript definitely existed and Google's Dart was introduced around that time. So when we saw TypeScript coming from Microsoft, I think we all had reason to believe that it would be something that a lot of people would be interested in. It allowed people to get all the benefits of static type checking, without having to put too much effort into learning. a new language.

I actually thought "wow, this is a great idea, but I think Microsoft is going to ruin it all." At that time it was a very different company. We, or they at the time, just didn't know how to do open source. In a way, they fumbled the ball every time. As an outsider, you'd look at a Microsoft open source project and think, "if I look at this, will they sue me or something?" For most of my career, Microsoft was always the bad guy. I liked Linux and installing my own systems, compiling the kernel, etc. And Microsoft was like the antithesis of that.

Are you hungry? Because we have cookies. Do you want a cookie? Microsoft used to be very aggressive with its competition to the point that the phrase "adopt, extend, extinguish" was a kind of motto that it would take over an area of ​​tools or an area of ​​something by first adopting existing standards and then adding for them, and then making Microsoft's style the only good one, which is very reasonable why a lot of people didn't like TypeScript at first. They were worried that this was a literal example of Microsoft spreading JavaScript and then taking control. Thank God that's not what ended up happening.

And now Microsoft is one of the best open source players among large companies. But internally, under Ballmer's leadership style, Microsoft was very hostile to open source. I remember hearing stories from my teammates at Sway, the app I worked on in Office, that they had to get permission to use jQuery, the most popular standard JavaScript library. And then one engineer, a very smart guy named Andrew Smith, wasn't sure, they weren't sure if they would allow TypeScript. So he kept a separate version of the codebase in TypeScript for a long time until they finally got approval. And it's mind-blowing to think about because today Microsoft only uses open source and contributeswith VS Code and TypeScript and all kinds of things are open source.

It was a slow transition from Ballmer's aggressive, "open source is a cancer" to Satya Nadella's, "embrace the world and be a good citizen." Microsoft's strategy, if it saw a technology emerging, would be to do a quick follow-up to beat the competition, win over users, and then kill the project. That was kind of the era of the late '90s and early '00s that had dragged on and certainly were the browser wars and what had happened there, especially for the web community, was still top of mind for many. The way we operate the team today, and have done so for at least the last ten years, is that we live by the saying that trust is gained in drops and lost in buckets.

That's why we think about every interaction with every developer we make trying to serve as a moment where you can decide: am I gaining trust or am I losing trust? I will never 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 like third rail problems in the community that I would never associate open source or Microsoft with that. I think today our position is really different and part of that is because our business model has evolved.

What has started to happen over the last decade and a half, as we move towards the cloud and utilities, is that the business model is not so much about the proprietary software that runs on the hardware, but rather about the hardware that we use . execute and operate on your behalf. So it's a really different type of model in terms of what the core of our business model is. And I think that's been an essential dimension of why our stance on open source has really evolved. It was never a bad game. Fundamentally, open source and Microsoft make a lot of sense together, because the mission is empowerment.

And that's true for open source. It really empowers developers because we can share infrastructure, and that's what Microsoft is trying to be. TypeScript was kind of the spearhead. It was the first big project to come out open source and Microsoft's fear diminished a lot when everyone saw that it was a positive thing, both for the community and for Microsoft. It was one of the things that helped Microsoft become less afraid of open source and be ready to embrace it and try again with VS Code and then also release all of .Net as open source. It was kind of a trickle from 2012, 2013, 2014.

You started to see more of these projects getting this kind of, I don't know, permission to adopt the same kind of model, and people were very excited to do it like Well. When we started working on the TypeScript project, there was actually no open source project at Microsoft. So far, we are the largest contributor to open source of any company. At first, TypeScript's reception was passionate but small. There was going to be a huge impact for large teams, for the type of teams we had within Microsoft, which were hundreds of engineers working on hundreds of thousands of lines, millions of lines of code base.

But one of the things that you saw when you worked with these teams that were adopting it was that for all of their interfaces, with all of the libraries that they were working with, they had to write type definitions for those libraries, and we, of course , Of course made it relatively easy. But it was only work you would have to do. It was activation energy for any team that wanted to embrace this. For a long time I was worried that the potential of TypeScript would be limited in some ways by the upfront work someone would have to do.

Probably the biggest surprise for me related to TypeScript was on release day. I think it was the day or maybe the day after the release, this DefinitelyTyped project appeared. DefinitelyTyped is like a mega repository. I don't want to call it monorepo, it's huge. I don't know what it is right now, but it's something like the 7th most active repository on GitHub last time I checked. And since people keep writing new JavaScript packages, it may now be higher on the list. It is a long time past the point where it is manageable by any 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 then he created a repository called DefinitelyTyped, I don't know how he got the name, on GitHub. Boris simply took the TypeScript definition written by Microsoft for jQuery and put it in DefinitelyTyped. And that's really significant because at that point Microsoft could have stepped in and said "no, you can't do that." So it was really good that that didn't happen. Microsoft just lets it be. People could see that there was something independent that lived alongside TypeScript but that wasn't created by the TypeScript team that was there and worked and allowed the rest of the world to start consuming TypeScript.

At first we were about 5 to 10 people gathered around and people came and went and... The exhaustion became real. I think the TypeScript team was aware at this point that they probably needed to help in some way because the DefinitelyTyped project was starting to run into problems. And they also started to see this potential problem between the contrast between DefinitelyTyped and an alternative project called Typings. There was divergence in the community because of this and the question is: where are we going and how does it work? So the big deal, the big change from DefinitelyTyped's perspective, was when the TypeScript compiler was changed to serve DefinitelyTyped's output type definitions to a dedicated repository scope in NPM called @types.

And that's the mechanism used today to consume type definitions for libraries that don't include their own type definitions, which is still a lot. You had 40 keystrokes in just a few weeks or a few months, and within a year there were hundreds. And there were hundreds of contributors. I underestimated the impact that this open source movement had in some sense around the web platform and around GitHub and so on. The fact that that was possible, the fact that the open source ecosystem allowed it, the fact that the DefinitelyTyped project was developed so early, I think is one of the biggest enablers of why TypeScript has become something that has been successful in the last ten years. .

That's an important lesson I learned from TypeScript. Even if the response at first is very calm, there may be a gem like Boris who will do something that will make more difference than anything you are doing in how important it is to the world. The initial reaction was slow, but it formed this wave that never stopped. As if it kept rolling, getting bigger and bigger. So we knew that there was fundamental momentum here, that this was going to have significant success. And I think I left it probably six months after 1.0 and moved on to an opportunity that was also in the developer division.

One of the things I was most proud of was helping to kind of drive a new decision framework for how we would do open source projects in general at DevDiv and ultimately it became company policy and really It went from mandating that everything go to CodePlex by default and saying, no, GitHub will be the place where we open source code by default. So taking that learning from what we did with TypeScript and applying it not only to TypeScript but to what Microsoft would do in general was a fun thing to do in that new role. After you left, I really missed your input.

For me it was 2.0. If things have gotten to the point where I'm thinking, "Wow, everyone in this is doing so much better than I would and they're a great team," it's a good time to move on. But it was really bittersweet with this one because it was a really special project and I really loved that moment of going from the impossible to maybe this is possible. And that feeling of that, it's really incredible. And some of them, we had a group of people who were working with us on TypeScript even before version 1.0, who are still working on it, with Daniel, with Ryan, with Anders, with so many other people who have been working on this now. for ten years, and somehow continue to improve it.

And I think in addition to the language design that they've done, just the work that they've done to build the community and the ecosystem around it and the partnerships that they've made, with Angular and with other frameworks, and bringing in all these different groups. of interest that in other contexts could be considered competitive with Microsoft. Just a huge amount of credit for where TypeScript is today. Anders and the team are amazing. What we learned from AngularJS is that AngularJS was great for getting you up and running quickly, but as teams got very large, it became difficult because you don't have type systems.

So we knew that we wanted to have some kind of type system within Angular in the next version of Angular that we were working on because we wanted to make sure that Angular scaled. There wasn't really any type system available and the closest thing that existed was the closure compiler within Google. But it was not very popular externally. So AtScript was our kind of ad hoc solution to add a type system to JavaScript but also to add the annotations that we needed for Angular. Okay, you just don't want the crystal to appear and disappear. So we introduced AtScript to the JavaScript community at a conference, ngEurope, in Paris in 2014.

We're not building a language. Just to make this clear, we are not creating a language, and what we are not doing is 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 came to us to tell us that they're trying to build something that we've already been building for quite some time. How about we join forces? AtScript was really born out of a need rather than a want, like no one wanted to work on this, but we needed it.

So when the Microsoft team came to us and said, "Hey, you know we're working on something similar called TypeScript that probably fits the exact same needs," as long as our needs were set, we were glad we didn't. work on it. . For the TypeScript team, that's their bread and butter to create a better language. We didn't want to put all our bets solely on TypeScript. There was a meeting that we called, Brad Green, I think, was the main organizer, and we invited the TypeScript team, we invited the JS compiler team, and we invited Flow from Facebook, and I think Dart was there as well.

We spent a day discussing where JavaScript was, where we were going, and what we needed. Interestingly, of everyone in that room, the TypeScript team was the only one who was actually willing to collaborate with us. Everyone else, I don't think they were convinced or were not sold on the idea of ​​working together. The challenge, however, was making sure Microsoft had the features we wanted, because from the beginning, TypeScript was close to what we wanted, but it wasn't necessarily exactly what we needed. And then we had to work with Microsoft on annotations and make sure that the annotations that they added to the system were 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. I think mainly of Yehuda Katz. And it was kind of a compromise in the sense that it allowed us to do the static analysis that we needed, but it also gave a kind of side effect on the behavior of the decorators that other people wanted. Decorators were very much, yes, that was a bargaining chip of Angular. We made the decision to do it. We started including and considering TypeScript in the Angular codebase starting in January 2015. And in March there was an Ng-Conf in Salt Lake City, where we did a keynote and invited JT to come on stage to talk about TypeScript and what we were doing, and then we announced that AtScript and TypeScript were going to merge and in the future it will be just TypeScript.

At some point I said, "Hi Anders, I'm really sorry. I think I pirated a copy of Turbo Pascal in 1993." And he said "well, okay, if you get Google to use TypeScript, we're good." Over time, it became much clearer that Angular would be written in TypeScript and that TypeScript would be the primary language in which Angular would be written or even the only one in which you had to use TypeScript to use Angular. Brilliant. And we think it brought a lot of value to our users. And Angular, of course, is primarily an open source framework, that's great.

However, it turns out that Google internally also wantsuse Angular. So Google is a big user. Angular is very important to us and having a new programming language on Google is a very high bar. So Google is very conservative in adopting programming languages ​​because it turns out that programming languages ​​are extremely important but also extremely expensive for businesses. If you bring in a new programming language, you need to have a compiler, you need to have a type checker, you need to have all the libraries available, you need to train all your engineers, etc. And that is a very high bar.

And this created an interesting situation where the Angular team said “yeah, let's do TypeScript!” But we also need to convince Google to actually use TypeScript. So we formed a small team. Alex Águila and Radoslav Kirov were part of it. Initially just the three of us started and added more people over time to essentially overcome the technical challenges of implementing TypeScript at Google, but also going through this approval process, which was kind of fun because we were the first language in terms of I know, go through this process. Basically, they set up this process as a polite way of saying "no, you can't allow this." And what we did was we said "yes, we'll try to follow this process." And they were basically marking the track as we went over it.

So they were imagining or making up the process as we ran it, which was a bit of a funny situation. And finally, after a few years of deliberation, not many, we said "yeah, okay, TypeScript 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 interface on Google, meaning something written in JavaScript, you have very little chance of not using TypeScript. So TypeScript really is ubiquitous in this monorepository that we have and is used in more or less everything we do today. This may sound like "oh, it wasn't very difficult", but the list we had on Google has never in the history of Google been expanded to another language.

So at some point someone said this is the list of languages ​​that people will use at Google to build apps and no one tried to add a language to that list, or if they tried, they failed. But he did. The community reaction to announcing Angular 2, which was essentially a rewrite of AngularJS along with TypeScript, was actually somewhat mixed. There are people who saw this and saw it as a future, and they got excited. But there were also a lot of people who didn't understand why we were doing this and thought it was an unnecessary complication. And this resulted in two things.

First, TypeScript got a big boost. I think that was the first important one, where we started to take off. Everyone who wanted to use Angular, and there were many, there were hundreds of thousands of developers in the early days of Angular 2 who wanted to use it, were just forced into 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 it was the only real language and it was the only thing they wanted to use. That gave a boost to React, because React was becoming popular at the time, and the history of React was very much "this is JavaScript." You use functions.

This is not another framework or library. You are just using JavaScript. And we just added a little bit of syntax to it. I'm glad to see that over the years the community has changed and almost everyone believes this was the right step in the right direction and TypeScript is essentially a plus right now. I don't think anyone would say that you should start a JavaScript project today and not use type information for it. Now, it's never perfect. You set these goals and then implement them. There were times when we needed to correct course. One of the reasons we were hesitant to use TypeScript was that TypeScript was not a strict superset of ES (EcmaScript), but we needed it to be.

And it seemed like that was what the TypeScript team thought they wanted to do. But on the ground there were things where they were implementing the language, that were not implemented perfectly in this spirit, and we needed them to correct course in this direction. When we started, JavaScript was a very small language with some very big holes. There were not classes. There are no modules. There is no notion of type annotations or anything like that. Well, typographical annotations are one thing. But classes? I mean, it would be difficult to program without classes or attract programmers who want a more adult 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 first versions. And you might think that we are expanding the language, of course, and therefore going against our own design philosophy. But at the time, that was the right thing to do. Certainly all the big holes have been filled, right? Now there are classes, there are modules, there are all kinds of other features that weren't there before, deconstructing what you have. I mean tons of things. At this point, JavaScript is a much more mature language and it simply doesn't make sense for us to create language features that are not within the scope of TC39 because that is simply swimming against the current.

We would prefer to participate in TC39 and be confident that whatever comes out of there will be something we can create a good type checking experience for. And that's the perspective that I think is very 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 co-chair of TC39, the committee that defines the JavaScript language. The TypeScript team itself is directly involved in TC39 to help guide the direction of JavaScript. We have what's called the staging process, which is a four-stage process, whereby we gain more and more confidence that a feature, a change in the language, will eventually land and become part of the standard.

To start, we have stage one, which is an idea, a definition of a problem. In the second stage, we have a pretty good idea of ​​what the candidate's solution might be. And then with stage three, we think we have all the details worked out and it's ready to roll out. And finally, if all goes well and we have two implementations, it becomes stage four, which is then guaranteed to be part of the standard. TypeScript was ahead of JavaScript in many ways. For example, the launch of the classes came early and obviously from an experimental point of view, even the decorators also arrived early.

When such deviations have arisen, the TypeScript team has gone the extra mile to correct and converge the language towards the JavaScript standard definition. One of the first issues in the TypeScript repository was a request for what became optional chaining, which is a way to access 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 repository topic was huge. They came to TC39 and joined the champion group that was pushing that proposal and eventually took it to stage four and it became part of the language.

And this was actually a huge success, because it means that JavaScript and TypeScript are consistent and on a great path to convergence. These are all people who care enough to work directly in the JavaScript language. They usually have opinions. It is the most used language in the world, so that impact is difficult to achieve. I really felt rewarded by it. It is one of the few truly significant language standardization processes that exist in the world today. C++ is another. These are languages ​​that actually have multiple implementations created by different groups that must agree on a common specification.

And it is definitely a job that we fully support. What I personally love about TypeScript is that I could probably come to work drunk and still code pretty well. Many front-end frameworks have a kind of framework war. That's the kind of dialogue that happens on the frontend, you know, like especially Remix VS NextJS VS Astro VS anything else. But TypeScript is a little calmer, a little more relaxed. And why is that? Well, actually it wasn't like that two or three years ago. TypeScript had a big competitor. And that competitor was Flow. And it seemed like Flow was something that came out of Meta, out of Facebook, and it was the biggest thing in terms of a written language or a written version of JavaScript.

So if you looked two or three years ago, there would be a lot of people on Twitter saying "TypeScript sucks! TypeScript just doesn't work. TypeScript isn't as good as Flow." In fact, people trusted between Facebook or Microsoft. One would expect two different technologies within a company to work very well together. But in reality, with large companies it is very difficult to get teams that are very different to really talk and make sure that they are working together on creating new features. So even if you would like React and Flow, two technologies created by Facebook or Meta, to work closely together, it's actually not true.

And the types you would get with Flow were worse than the types you would get with TypeScript. I think there are a lot of really interesting collaborations in open source. Everyone works to collaborate to create a better ecosystem, to raise the tide, so that all boats float higher. Flow, like its name, implies that it will try to discover each type in your system by flowing the types through your system based on where it was used. So if you treat something as a number, then it will act like a number throughout your type system. Whereas TypeScript said "hey, we'll force you to type in certain sets of places, and if you do that, we'll give you a type system." And these two types of approaches have different tradeoffs at different levels, and in the end, both teams ended up building both parts in different ways.

But it seemed like TypeScript finally reached a point in its popularity where the Flow team realized that trying to do all the additional public open source work necessary to commit to competing with TypeScript was making it more difficult. build Flow for its main goal, which was to be the type checker for the entire Facebook codebase. Flow simply decided that they were going to start playing a different game than TypeScript. Flow, they have never hidden this. Its main goal is to be a technology for use within Facebook, so they also jump the fence into the open source community.

But we've always had a design philosophy: we're designing this product for the community, those are our customers, and of course the internal teams can use it too and we'll help them, but that's not the case. t specifically for internal Microsoft processes. So the fact that TypeScript as a community is so quiet these days is because there's really nothing to fight about. TypeScript just won, really. In some ways it surpassed all its competitors. It integrated with everything. TypeScript is the new default. So we agreed that TypeScript was good. And I don't think you're going to see that in many other toolchains, in any other situation, because TypeScript is on a different level than most other front-end tools, because it's just on top of everything or rather said, underneath everything. .

It sits between your front-end framework and JavaScript itself and there is nothing else at that level of the pyramid. In reality, for most projects, TypeScript simply outperformed Flow in all of these different metrics. And the metrics were Angular, React, Vue, Svelte. They brought first-class TypeScript integration and TypeScript worked very hard to integrate with them and outperformed things like Flow, like CoffeeScript. Those things never had as good an integration as TypeScript. And that simply meant that TypeScript became the default option 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 can't eat it. Up to you. For us, feature prioritization is really driven by the JavaScript landscape and the type of code people write and what type of support they need from TypeScript to write those types of programs. If you look at every language feature in TypeScript, it's always something that you can trace back to some programming pattern that is common in JavaScript or sometimes it could 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 business." But no, we said we had to embrace the JavaScript development ecosystem, provide our tools as something that can be integrated into other tools, not try to be the only game in town.

Try to work with everyone so that no matter what your build chain looks like, TypeScript is something you can use. We've worked with Evan on Vue and we've worked with the React team, with the Angular team. I think that here we are theSwitzerland of technologies. We're not married to a particular framework or methodology, right? Overall, we want to be the best development productivity tool for the ECMAScript/JavaScript ecosystem. The first time TypeScript really experienced mass adoption was when it was combined with Angular and they decided to work together. The next big issue was when it started supporting 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 this was all due to different syntaxes that it added to the language. The next big advancement was React, when it added support for JSX. And now TypeScript has reached such a peak, has reached such a huge point of rise in the community that people are saying "oh, WE integrate WITH TypeScript." My name is Ryan Dahl. I am best known for creating NodeJS. In my opinion, TypeScript is a natural extension of JavaScript. Adds types that allow you to build more complex programs. As a sort of natural evolution, at least in my opinion of JavaScript, I think it was clear to me that it should be part of a future runtime for JavaScript.

Deno internally converts TypeScript to JavaScript. So TypeScript has this really interesting property that it's very easy to remove types and what's left is JavaScript. So you don't need a very complicated compiler step to quickly translate TypeScript to JavaScript. Deno has all of that built in. The type checking algorithm, which the TypeScript compiler has, is also integrated, but performs two separate activities. One is type stripping just to execute the resulting JavaScript and the other is type checking itself. Deno has all this kind of stuff built in, unlike Node and tsc, where you have to configure build processes for it to work correctly.

TypeScript is a big selling point for Deno. I mean we use TypeScript all internally. Like any website you would be programming now or any backend tool, you would use TypeScript. I think most developers today feel that way. And yeah, I think being able to not have to set up any tools or any build processes for this is definitely one of the reasons why people are using Deno. When we started TypeScript, we were obviously using TypeScript at Microsoft and then we started hearing about companies outside of the company that were using TypeScript. And I think when Netflix announced that they were using TypeScript, I thought, "Wow, Netflix!

It's like a real company." Which is funny if 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 highly respected engineering culture that chooses to embrace TypeScript. And I feel like I have those wins almost every year now, because you hear that you know another company that successfully migrates to TypeScript. And it's almost kind of a non-event at this point, but you find out about it and it still feels good, you know? Airbnb moves or Bloomberg talks about his stuff and you feel proud.

Bloomberg made some of the greatest public relations contributions to the language. For example the delivery of private fields and private methods. So we put together this plan and presented it to the head of engineering. He read it and pondered saying, "So the future of JavaScript at Bloomberg is to switch to TypeScript?" And that's exactly what we did. We made this voluntary. Any team that wanted to adopt it could do so. And we found that within the first year, 200 projects had opted for this first-class TypeScript support and none of them turned back. With AG Grid using TypeScript, it makes us more efficient.

And at the end of the day, that's what writing software is all about. It's about how to create software that meets business requirements as efficiently as possible and is as maintainable as possible. That's what all these tools boil down to. And TypeScript allows us to do that. There's an anecdote, you know, we went out and the Prime Minister was talking to someone and he said, "TypeScript is going to be bigger than C# at some point." And the other person just laughed, just laughed, because the idea was absurd. And here we are. And I think TypeScript is bigger than C# depending on how you measure it right now.

And that to me is just incredible. When we started, I thought static types are really cool. I like static types, but I can understand why someone doesn't like static types. I think we're capped at 30, 40, 50% JavaScript developers. Maybe 60% in my wildest dreams. And yes, depending on how you slice it, if you count people using static types in JSDoc, if you count TS files, if you count other things, maybe the sky is the limit. JetBrains conducts the State of the Developer Ecosystem Survey every year. Last year, 2022, we collected responses from more than 30,000 developers. In 2017, when we conducted our first developer ecosystem survey, 12% of users mentioned trying to use TypeScript in the previous twelve months, while a year ago, in 2022, already 34% of our participants mentioned TypeScript as the language. that they have tried during the last twelve months.

And if we are not talking about using TypeScript as ONE of the languages ​​but rather using TypeScript as one of the THREE main languages, in 2022 there were 18% of respondents who used TypeScript as their main language. In 2019, it was only 9%. This says that the number is growing rapidly. You might think that TypeScript's numbers are actually being minimized a bit. There are so many developers using TypeScript and don't even realize they're doing it. There is an alternative way to use TypeScript which is to simply add these things called JSDoc comments in JavaScript. What that means is that you just have some code and then you write a comment on top of that code and use special syntax.

And that special syntax basically gives you types of that function or that thing. That's why a lot of people say, "I'll stick with JavaScript, I'll stick with JavaScript." But really what they are doing is using TypeScript with JSDoc annotations. TypeScript is not just a language, it is a complete set of tools related to JavaScript. TypeScript has just allowed IDEs like VS Code and WebStorm to give you a lot of additional information. Even if you're not writing TypeScript, if you're just writing basic JavaScript, your IDE can understand that code using the TypeScript parser and then give you those hints to tell you 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 to TypeScript, they get the same experience. But they've been reaping the benefits all along thanks to IDEs being able to harness the powers of TypeScript. If you use VS Code and write JavaScript, then you are a TypeScript user. Because the language service that powers everything that happens there is the TypeScript compiler. Let me put it this way, there is TypeScript, the syntax, and TypeScript, the tool. TypeScript syntax is, yes, it's a superset of JavaScript with type annotations and interface declarations and whatever, and you need some tool to clear that before you can run JavaScript.

But then there's TypeScript, the tool. And TypeScript, the compiler, is perfectly willing to parse JavaScript and infer types, or perfectly willing to parse JavaScript with JSDoc annotations and get the types from there. Or, it's perfectly happy to parse 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. Really do not care. And I think that's the beauty of it, right? You use what works for you. If you are very interested in having an inner loop where no transpolation is required, you just want to be able to save and run, great, then you will probably use JSDoc annotations because they can persist.

But if you want to have something that is more readable, then you can go for manifest type annotations. And it turns out that most people usually do it because they use packages anyway. And if you're grouping, you can also transpile and clear types. It does not involve any additional cost. You have to read the files and parse them anyway to be there. And that's what esbuild and SWC do. By the time you have that package or package in your inner loop, you can also use TypeScript syntax because it basically adds no cost. But not everyone feels that way and that's okay with us.

When we think about how to improve the TypeScript experience, a lot of that is really about how do we improve the JavaScript experience. That has to do as much with JSDoc as it does with inference and other tricks we can do to improve the JavaScript experience. So when I hear about big projects like, I think, Svelte and Webpack, that use just JSDoc, some people look at it and say, "Oh, they're moving away from TypeScript." And I say no. They are adopting TypeScript. They're adopting this other version of TypeScript that we created. That works too and we can deal with it.

And it's kind of a win-win for everyone. There are probably two elements at play in terms of why we're not aggressive about pushing TypeScript. We know that developers don't like to be marketed to, and at the end of the day, the most important thing is that developers are truly happy with the product. What they like. You did think of it as an investment, right? You could invest in DevRel to evangelize the technology, or you could invest in the product and actually just improve it. We believe that the most important thing is to focus on the product.

I would say that there is no real TypeScript community, because they don't need one. They're not trying to sell you TypeScript. You're using TypeScript because it's good for you. Wherever you find JavaScript or a JavaScript framework, such as React, Angular, or Vue, you will also find TypeScript. TypeScript fits very well with all of these things we're already using. I truly believe that the big key to software success is the ecosystem that surrounds it. If you think about your iPhone, all aspects of an iPhone fit very well with all the things you're already doing. The next purchase you make should be able to integrate with your iPhone.

Now, the next software purchase you make, or the next library you adopt, should support TypeScript. There is definitely a TypeScript community. There are still people who don't want to use TypeScript. Otherwise, I think basically all front-end developers would be the TypeScript community. You have like a tipping point where the maintenance cost of not having any type and validating at runtime becomes really high. But TypeScript is a little more consistent in having all that complexity to deal with later and bringing it to the beginning of your development flow. It's like brushing your teeth or eating vegetables. It is difficult to do it from the beginning because it is not a habit.

But once you have TypeScript integrated into your project, it's like it's that habit you don't want to get rid of. At 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 seemed obvious that it was my responsibility as a library writer to adopt TypeScript, because with a little work on my part, all my users could benefit. So Solid, almost since it was first open sourced, has been built in TypeScript. JavaScript is still shit. TypeScript makes it easier to manage shit. It made me go from hating JavaScript to technically using JavaScript for everything I build.

I would say that Microsoft understands developers better than the React team. Now that many companies are starting to hire and look for developers who have TypeScript experience, the thing you need to know about how to be a front-end developer is "do you know React?" The second question they'll 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 bit of descriptions on top of it. The first time you use it, you say "oh, I see why people like this kind of thing." I built a project in TypeScript the other day and didn't look at the docs once.

When you have people in the industry that everyone looks up to and you start saying, you know what? I'm adopting TypeScript in my own projects and that's why... Now I'm starting to feel the doors opening a little more. And I think that's starting to happen in the TypeScript ecosystem and has been happening for a while now. And that's why I think it's starting to grow unchecked. The really interesting property of TypeScript is that it is destined to disappear. I think what the TypeScript team really wants is to improve JavaScript, or at least that's the feeling I get.

And adding types to the language is simply a way to speed up that process, because without types you can't have autocomplete, without types you can't have sensible bugs in your IDE. I think what TypeScript is doing is preparing for a future where it no longer needs to exist. If you look at the way the TypeScript team is participating in the evolution of JavaScript, Daniel Rosenwasseris on the TC39 committee, so I believe that one day we will have a future where TypeScript does not exist. And I think that's because JavaScript itself will have adopted types or made space in the language where types can be added, and then TypeScript will just be a CLI that you'll run to check that JavaScript is working fine.

And I think the days of writing TS files might be numbered. It's a big number, but they may be counted. As with Babel, there comes a time when this entire set of communities could merge with each other again. And like now, TypeScript is a fork of JavaScript. And it would be amazing if we could bring Type syntax into JavaScript, so that all those people who had to migrate to TypeScript for their tools, and this additional syntax, which allows them to be able to say, "hey, this is a string." , bring all those people back to JavaScript and make JavaScript a much bigger store, and eliminate TypeScript.

I think it's a project I'd love to see TypeScript put more effort into. One thing that holds us back today is that we don't have a standardized notation for types in the ECMAscript language. I would love to see that because I think it would allow for 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 I'd like to get out of my tools right now is for them to be faster. TypeScript is pretty fast. But speed is something you can always benefit from.

And the only way to probably achieve this right now is not to use JavaScript itself, but to use something like Rust. And there are many projects that show that Rust, and especially when it comes to parsing and manipulating AST trees, is significantly faster. I think the biggest challenge TypeScript faces right now is bringing in new people and explaining the bugs to them. Because the way you view typos in your editor right now is not very rich for most people, and you're starting to see people working in this space. There is this extension, the Total TypeScript extension by Matt Pocock, which is a great way to explain TypeScript errors in more human-readable English.

But I think in the long run I want to see more exploration into alternative, richer ways of visualizing TypeScript problems. Now that TypeScript has become so dominant in the industry, it no longer needs to defend and justify its existence, it must be better for newcomers. TypeScript has become quite dominant. I don't think that means we stop innovating. I think it means there's room for us to keep trying to do better. Because what excites our team is making our developers happy. Naturally, that gives us fuel to try to do better. You can use plain JavaScript, you can fork TypeScript, it's an open source project, you can do whatever you want with it.

There is still competition, there is competition in speed. Nowadays there are alternative compilers that people are trying to create. Alternative type checkers where people try to rebuild the type checker and make it faster. And that keeps us motivated, right? Because people constantly want a better developer experience. 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 compile times, simply because TypeScript is doing more and more work. So we're looking at how we can make the main TypeScript operation faster. How can we work less on each build?

How can we display 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 are always ways to improve our interoperability with other parts of the tools available. I believe a lot in the long game. Programming languages ​​are not created in a short period of time. It's ridiculous to think that you can create a programming language and have it be important and adopted and whatever in less than five years because the expectations of programmers are incredibly high today.

It is not enough to define a language and write a compiler for it. No, that's what's at stake. But you have to have great tools, you have to have all these services, you have to be open source and you have to have a team that is willing to address the problems and you have to take care of it and write documentation. . It's a great company. I often joke: show me a perfect programming language and I'll show you a language without users because those are the only ones that can really be perfect. Some people ask well, if you incorporate TypeScript into JavaScript, don't you lose your job?

Good? We will be the ones to write and check it out. We will be the type inspectors. You need someone to write that type checker. And so TypeScript does not cease to exist. It just works in a different file format or something. So I don't think we're going anywhere. I feel like what I'll remember, of course, is a lot of the brilliance of the team, the ingenuity, the moments when I was in the room when we came up with this or that or when I had to be the person to come. with those concepts. And that will always be extremely rewarding, but it will definitely be the people that stand out to me the most.

There's something about being in that situation where no one else believes that I still feel like yeah, if I needed to work on something with Luke tomorrow, no problem, we could do it. We had to invent a new type of type system really motivated by IDE tools and experiences as the main goal. And I think there weren't many examples of that, certainly not in the JavaScript ecosystem and really only a few, even in academia at the time. It is a truly incredible experience. And one of those things where you're very lucky is when you have one or two of those experiences in your career of building something and feeling that kind of excitement.

Being able to help create a situation where people are really proud of their work, feel like they're doing something really meaningful, and still like it 12 or 13 years later, for me I'm really proud of that. And then the other thing I'm proud of is that TypeScript was really the beginning for Microsoft to get really comfortable with open source, to change their policies around open source. It's a model of how we do open source at Microsoft. In a sense, we started with TypeScript and we've reused that pattern over and over again and I would say this was both TypeScript and Visual Studio Code and making .Net open source, I think all those different actions laid a foundation. that made it acceptable for Microsoft to be the buyer of GitHub.

I think if we hadn't had any successful open source projects at the time, it would have been viewed with much more hostility by the community. It has been a long journey, it is a continuous journey. We've been at this for twelve years and in my wildest fantasies I had never imagined we would get the kind of adoption we have had. I think we used to jokingly dream about, "Oh my God, if we could attract 25% of the JavaScript community, that would be incredibly cool, right?" And now we're much bigger than that. I never thought that would happen and I am immensely proud of it.

I think what keeps us going is just seeing the joy people have using the tool and they're not shy about expressing it on Twitter and in our forums and issue trackers and Stack Overflow and whatever. And it's great to see that... "I will never go back to JavaScript." “Writing code in JavaScript feels like skydiving without a parachute” or “coding naked,” or are these all fun 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 very proud of that.