How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem

All right, start betting on TypeScript. So I'm going to try and talk a little bit about TypeScript's influence in the JavaScript ecosystem, you know, how the TypeScript team try to sort of constrain themselves in order to make sure that, you know, TypeScript and JavaScript are both like sort of allies in trying to make cool things in JavaScript.

And then sort of what does it look like if there was an attempt at trying to usurp JavaScript via TypeScript by the team at Microsoft. And hopefully with all of that, we'll all come out a little bit smarter and have different ideas about how all the pieces come together.

Okay, so get started. My name is Ohto the Rocks. I've been doing large scale open source projects for a very long time, starting with a dependency manager for iOS. Moving on to this sort of cultural tool of across many different programming languages allow you to sort of create linter rules around how pull request etiquette works.

And I spent a lot of time, quite recently, just working in the TypeScript era, like trying to figure out how to build complicated tools for it, and how all these pieces come together. That eventually sort of turned into me working on TypeScript full time. And so now that means I've got quite a lot of insight that I think would be super useful and it's kind of unique. So I'm gonna try and talk about how all that comes together.

So the goals of this talk are to try and make it a little bit different from your average TypeScript talk. Most talks about TypeScript try and talk about, like, what features are useful or, you know, how to provide useful editor tools, things like that. But this talk actually, like, takes a step back and tries to think about how TypeScript affects the entire sort of industry. And you know, what the TypeScript team does to try and make sure that that's entirely copacetic. So buckle up and we'll have a good time.

To get started, we'll talk a little bit about the TypeScript team, if you don't know. We're roughly eight people that work on the compiler, and about 20 folks altogether. That means project managers. And there's an entirely other team whose job is to handle the integration with Visual Studio, not Visual Studio code, which is quite a considerable amount of work. And they do a huge amount of, like, good bug tracking and making sure that, like, TypeScript is as bug-free as possible.

The team itself has a few sort of long-term goals and kind of principles. The two main documents around this, there is the operating principles. These try to describe, like, what the TypeScript project represents. So, you know, what is the long-term goal? How do we perceive ourselves in relationship to other programming languages versus in relation to other like JavaScript style, like transpile to JavaScript programming languages? These just sort of say, like, you know, this is how we define ourselves. And then the other one, and potentially the more interesting one for this talk, the TypeScript design goals. There's a lot here. So we'll kind of split it into two. So there's like the design goals for interacting with JavaScript, right? So impose no runtime overhead on emitted programs is highly jargon-to-speak for just outright saying, if you put JavaScript into TypeScript, you get JavaScript back and we don't change things.

And then the next one is like aligning with current future like JavaScript proposals. So don't go off and make your own language that feels like JavaScript but does something else. And keep up to date with as JavaScript changes. We'll talk a little bit about that later. Preserve the runtime behavior of all JavaScript code. Also talks to the same idea of JavaScript in and JavaScript out. Avoiding adding expression-level syntax, we will get into later in more detail. And use a consistent fully erasable structural type system. Also something we'll get into more detail later.

And then on the other side, you know, there's JavaScript and then there's types. Which is the types of TypeScript. And, you know, TypeScript has a kind of unique take on type systems because it cannot create new syntax realistically, within some constraints to sort of help do existing design patterns. So TypeScript tries to do as much as possible via inference. And by goal, they specifically try to find, like, code that's likely to be errors and provide systems for working towards it, instead of creating new ideas and new paradigms in which people can sort of write code. The idea is, instead, make it so that you can find bad code easier, rather than pushing people in a particular direction.

On top of that then, you know, I can talk about how TypeScript influences the industry, but you kind of have to understand how, like, how big TypeScript is to get a sense of this. So, like, what makes TypeScript big? I think a recent poll that I think is quite useful is Stackoverflow. Stackoverflow is a website where you can ask questions. But one of the interesting things here is it's not a JavaScript-specific, like, developer ecosystem. It is a, all developers use Stackoverflow in every single programming language, basically. So when you see results from those kind of polls, then you can know that they're not, like, directly, like, oriented to a specific type of developer. So, on the left, you can see that TypeScript is the second most loved language in the world. And, on the right, you can see that, like, basically, one in three JavaScript programmers are also using TypeScript. So, that's a lot. There's a bazillion JavaScript programmers, so there must be a third of a bazillion TypeScript programmers. And, you know, you might be wondering to yourself, okay, so, it's popular, people like it. There's also, like, a question that, like, I always ask, which is, like, how does TypeScript get funded? And why is it even created? Well, in part, because it solves real problems in building large code bases in Microsoft and the other part is it's incredible PR for Microsoft. Like, you know, people sort of are introduced to Microsoft development environments outside of Windows now via VS Code and TypeScript, and then they go from there and say, huh, if VS code works well and TypeScript works well, well, maybe this Azure works well. Oh, the dog's come down. So, you know, if you want more TypeScript compiler engineers, start using Microsoft Azure.

But you can't think of TypeScript in isolation. For TypeScript there are effectively two audiences. There's Type Script users and JavaScript users and there's a whole lot of JavaScript users in the world. I always try to think of a user base as narrowing down set of people where there's a lot of JavaScript people and very few JavaScript and JavaScript dog people and people migrating further down is like a goal, but they can stay where they are. And we want to provide tooling at all those levels and that is done by providing IDE features to everybody.

So effectively TypeScript is big enough to be kind of has an impact on the entire JavaScript industry when changes are made. And so generally I like to think of a bet on TypeScript as a bet on JavaScript nowadays. And the reason is like TypeScript has such a complicated type system and all of that is done to try and map JavaScript and to try and not introduce new concepts to the JavaScript language. And they may have all these features but like at the end of the day TypeScript aims to innovate in only one place and that is in types.

Not provide new features of expression level. So to get you an understanding of what I mean I'm going to show you the playground. This is the TypeScript playground. It's an online place to you know show and highlight code with other people. And you can see here on the left there is some code that first is a type definition and then it's a const object that conforms to that type definition and on the right you can see this sort of the output of the JavaScript. So TypeScript removes the type definition and also sort of colon after the A in the left. And that's kind of the end goal for TypeScript. To take the type system, erase it and then you've got real JavaScript at the end of the day.

This has not always strictly been the case. So for example here's an enum which is a language expression feature that was added by TypeScript like seven, eight years ago. And you can see that by using that I have affected the JavaScript on the left. On the right there's just a lot of code that gets emitted that is done to sort of add this extra feature to JavaScript. But that's not like what TypeScript is nowadays but that's where they used to be. As time moved on then TypeScript added a feature explicitly to sort of undo that kind of damage to JavaScript that was done. So you can now create these existing expression structures that can also be completely erasable. So TypeScript like to think about it as the expression, expression features are removed, so you know, Spy Space, things like that. Well, they're not removed. They're not removed. TypeScript's infinite backwards compatibility effectively. They're just not things that we're super proud of in modern code and there's many ways now that people are starting to replicate those features using modern JavaScript syntax, and that's what we encourage. The TC-39 bit is interesting.

TypeScript and TC-39 best buds. If you've never heard of TypeTC39, it's a meeting that occurs every quarter, and they're basically bike shed on the future of JavaScript. TC-39 is a lot of different voices, you know, people that come from all these different backgrounds that try to understand where JavaScript is and where it's going to be, and they sort of pitch these proposals, and they go through stages. And TypeScript is there and it's a welcome contributor, all of these different venues where JavaScript is sort of being, the future of JavaScript is being discussed, and we're just a contributor, the same level of access that other companies have, that makes the browsers that you use.

And we try and give feedback on whether it's something that could be addressable in a type system, or try and help pitch features that we think would be very useful for people using type systems. That means that effectively the goals of JavaScript and the goals of TypeScript are aligned in a way that, it's not TypeScript to decide the future of JavaScript. It's not TypeScript to pitch to the rest of the standards committees what the future of JavaScript could look like. So if TypeScript is popular, and Microsoft's history of handling open source is not exactly, perfectly squeaky clean. What then could it look like to take TypeScript and make a malevolent version of TypeScript? A version of TypeScript whose goals are to undermine JavaScript as a conceptual thing.

So first off, when I thought about this, you can't charge for a compiler anymore. There's just too many really good compilers. TypeScript competes with Flow or Haggle or ClojureScript or Elm, and all of these are free and open source that anybody can contribute, anyone can improve, and are continually getting better every day. Suddenly TypeScript to turn around and start charging money for it or to go closed source is not very feasible. The co-creators of TypeScript, Anders Heidelberg, he created C Sharp, and Pascal, I think, he said at this point, basically no one's ever going to make a closed source programming language or charge for a compiler stuff ever again. And I think that's cool. I mean, I'd prefer to be in that ecosystem.

So realistically, Microsoft has to embrace extended extinguished JavaScript, which might seem feasible because the first two are done. TypeScript is embracing JavaScript and TypeScript is extending JavaScript with a custom type system on top of it. It should make it easy, right? Barely an inconvenience. But the biggest problem here is actually that TypeScript has to run on other people's code. And one argument that could work against that is that Microsoft could try and make TypeScript a native browser language. And if this was back in the IE 6, 7, 8, 9 days, there's a reasonable chance that that push could have been much more successful. But nowadays, Microsoft doesn't own a browser engine. They share Chromium with Google. They could try pitching to the standards committee that maybe we could get to a point where TypeScript could run in a browser. But anything like that would have to be in the sense of like, how can we remove official parts of TypeScript from JavaScript in browsers so that they could just run TypeScript code but won't do the type checking. No one else wants that responsibility. That's a nightmare. One of the biggest pictures against that is actually that the web isn't something like Denno or Node where you can sort of precompile and pay the cost of transforming TypeScript to JavaScript. You know, browsers only ship one version of JavaScript and they've never needed to use Babel, for example, so they're not probably going to do something like support something like TypeScript.

They could make TypeScript differ from JavaScript, right? So start taking the features that people don't want in JavaScript out of TypeScript. Right, first of all, there are pretty regular demands for this, right? There's lots of parts of JavaScript that are just weird and inconsistent that people get bit by that we can't even say is a typesist America, so there's times when people want that. That, like, TypeScript could conceptually be removed from the language by making that stuff cause errors.

But at the end of the day, like, TypeScript's future is in alignment with JavaScript and, you know, starting to pull apart JavaScript and like removing backwards compatibility is gonna really ruin our reputation with TC39 who controls JavaScript. It's gonna really annoy people that actually use it because suddenly their code is starting to break and TypeScript, as a rule of thumb, tries to never break people's code. You'll get compiler errors as we improve error detection but to go back and start regressing on things that have existed for a long time doesn't mean that you can't do JavaScript in, JavaScript out. And realistically, because it's open source, there's a lot of contributors, someone would probably start a fork and that seems totally reasonable. And so there's not really that much incentive for the TypeScript team to sort of extinguish JavaScript by trying to, like, fork the language and remove it.

But that's not to say that this idea doesn't have value. There is a programming language called Static TypeScript that came from Microsoft Research. His goal was explicitly to do that. They wanted to take TypeScript and convert it to C code. So they can't have a lot of the weird runtime trickery involved in JavaScript. So they actually let you write real JavaScript in a web browser that gets compiled in the web browser to C code that runs on, like, small hardware. Really cool stuff. Really interesting work. And they did it with TypeScript so they get all the tooling for TypeScript, but they just then need to add a few extra errors and warnings to make sure that it will run and convert to C. So this is a research project. It's definitely not TypeScript team values. But it's an interesting, like, idea of what it could look like if TypeScript were going to do that. So that's probably not happening.

But even if it did, like, TypeScript's goal would literally be to help you migrate away from TypeScript, right? Like, you just compile the TypeScript and it removes the types and you get JavaScript. So if you wanted to migrate away from TypeScript, you would run TypeScript on your code base at the highest level of JavaScript and then just start using Babel, right? Babel is never gonna stop, at this point Babel is probably never gonna stop supporting TypeScript in some form. And there will always be things like Babel plugins or code mods to help you go from, you know, TypeScript to TypeScript or whatever. And then finally, TypeScript has competition, and that's really great because it keeps both the, it keeps many people using TypeSystems across JavaScript. I want all of them to succeed. Because, you know, anytime you interact with libraries, I would much prefer that it has the stronger foundations by being statically analyzable. And there are even new TypeScript, new JavaScript type systems that aim to have compatibility with DTS files from TypeScript. So, you know, it's, it's unlikely to happen that way. And so, it's unlikely to happen at all, in my opinion, but that's one of the sort of, that's why there's not that much incentives for TypeScript to do that.

Then there's the sort of TypeScript, like, it's sort of de-isolating itself, like, TypeScript used to be about using TS Lint, and you'd have, you know, these different tools for TypeScript world, but nowadays you have, like, Babel and ES Lint, and a lot of people are using the exact same JavaScript tools they used to use but with for TypeScript. And that means that we can just keep JavaScript, TypeScript as this, like, thin layer on top of Type, on top of JavaScript, and providing value at sort of tooling levels, and that keeps the difference between them quite negligible. And that's a goal for us. We want to keep improving the TypeScript semantics so that we can keep supporting JavaScript users, because that's very important to us. You saw how many people are there? And for all, you know, TypeScript succeeds in my opinion because it's so close to JavaScript semantics. There are so many great languages that provide much better, like, safety, but they move further away from what JavaScript is, and you have to understand that difference a lot more. And I think that the closer that TypeScript and JavaScript are, the easier it is to adopt and the more likely people are to continue using it.

Then like TypeScript regrets some of the changes it made in the beginning about adding features to JavaScript. Like, TypeScript added classes before classes came to JavaScript, but luckily it guessed syntax correctly, or the syntax was highly inspired by TypeScript's work and trying to figure out what a class should look like in JavaScript.

Enum is something that could come back into the language through TC39. There is a proposal for it but it looks a little different. Suddenly TypeScript will have to support old style enums and new style enums. And namespaces we don't need anymore. So TypeScript regrets effectively the periods of time where it has moved away from what JavaScript is and wants to help push it towards where it could be.

So TypeScript is generally now trying to push JavaScript in a positive direction and tries to add things in ways that are completely hidden. But trying to think about it from the perspective of why TypeScript does it this way. I like to think about the question mark operator. This is a proposal that someone else made that TypeScript had pushed through for the final stages. When that feature was added to Babel, it was roughly 120 lines of code and a plugin that anyone could use and do something with it. And that was easy and accessible. When it was added to TypeScript, thousands of lines of code had billions of tests and realistically not that many people could do it.

So for TypeScript, adding changes to the entire type system and adding new language features, that is hard, complicated work. And so we really want stability before we actually go for new features like this. And so it's not in TypeScript's advantage to actually try and do these things ahead of time, but to be stable and wait until everybody's agreed on what it looks like before implementing. Because it's so much more work, and if you get it wrong, then we may have to have multiple implementations of the same thing inside the codebase and that's really complicated. So that's realistically the main reasons why TypeScript puts constraints on itself. Design constraints to force ourselves into doing it the right way.

We prefer working with other people. There's a little incentive for us to be breaking JavaScript. You can undo TypeScript by using TypeScript. Everything in the last two years has been done to de-isolate TypeScript codebases. So that's what TypeScript team does and that's how we try not to be a great citizen. My name was Otter. I also believe that you should go protest if there's some in your city. I think TypeScript is cool. If you're using it, great. If you're not, maybe try it.

Let us know all of your favorite things. Have a good one. Ciao, everyone.

Hey, El. Hey. Hi. So let's jump right in because I see that we have a lot of questions and we don't have a lot of time for Q&A. Let's start with are there any plans to improve support for JS and JS docs? Yes. JS and JS docs is effectively a one-person thing and he's always hammering on it. I think he's been working on and off for that for like four years. So continually improved just whenever he gets the time. Does this person have a name so we can bother them when it's... Yeah, that's Nathan Sanders. He does great work in the sort of JavaScript ecosystem within TypeScript. Okay noted.

What is your favorite TypeScript feature that is currently on the roadmap? So my favorite feature is actually I think the website's coming out with 4.0. So the revised website with all the new stuff in there. It's like so long that I wrote three separate blog posts about what's coming up in this website change. I think it will fundamentally make it a lot easier for people to learn TypeScript. Cool. Okay, next question because we're pressed for time. Many questions. This one is from Danilo. I've seen some people run TypeScript code in runtime with ts-node as opposed to building it before deploy and running node directly. Does the TypeScript team recommend one or the other way? So, I mean, I have a personal recommendation. I think the rest of the TypeScript team would probably agree with me is that it is better to transpile all your code first and then run it. I think of it as simply there are less moving parts in your system. Ts-node is solid, mature, and great. But like doing all the work ahead of time and then providing something to then work from is personally a great way to do it. Deno does that effectively and is an entire runtime built around that.

So that's only one abstraction and not two. So ahead of time is my opinion. Right, noted.

All right. What are the main pain points and this is again from Danilo, by the way, what are the main points to allow more people in the community to use TypeScript? What are the things that are maybe a blocker for people to start using TypeScript?

So I think I showed in the talk this sort of graph of the TypeScript user base, which is a bazillion JavaScript users via VS code and then they slowly and slowly get smaller and tighter as they use more and more of TypeScript features. I think there are these kind of transition points that need better documentation. So jumping from a JavaScript only project to a JavaScript only project with richer tooling, we generally call it JS plus JS doc. Jumping through those transitions, I think could be much easier and that will move people down towards a stricter, tighter, like more well understood code base by TypeScript and that will give you better tools and better safety. And at the end of the day, that's some of the biggest values from TypeScript. So helping the transitions between those migration patterns is one of the biggest things I think that we could do.

Yeah, which maybe is where docs comes into play as well, right?

Yeah. What do you think that TypeScript should borrow from another typed JavaScript language? So I don't know if it's another typed JavaScript language, but I personally would like to see sort of plugins to TypeScript that allow people to use like JavaScript files that aren't just pure JavaScript. Think about it as like a view or spell, or even a GraphQL file. They can all be actually represented in the type system, but they can't actually be represented in TypeScript today because TypeScript assumes that a file is all JavaScript and it lives JavaScript. It's extremely complicated at the end of the day, and TypeScript is slowly working on that sort of thing, but that's what I would really like to see. I think that's some of the features. No other languages have plugin systems, so it's not really something you can steal from someone else, but I think it's some of the best low-hanging fruit that would give a lot of people a lot of tools very easily.

We're not saying stealing. We're saying inspired by, right?

Yeah, you know, great honesty. Alright, let me see. There's so many questions I can't choose. I wanted to just throw in one of my own. Say TypeScript being a Microsoft project, do you think that makes it different from other open source projects in terms of community? It's an interesting question, right? That leads to, like, what is corporate open source? Microsoft used to ship languages closed source. In fact, Microsoft used to be very against open source as a conceptual idea. And quite recently, within the last decade, changed that line completely. Now my work is entirely done in the open. I think that working on corporate open source means that you have to put a lot more effort into support and you have to put a lot more effort in ahead of time to do the work that's kind of boring. The amount of accessibility work I have to do is so much more involved than previous work that I've done. And this is great, because, like, building better and more accessible tools makes it available for everybody and rises the tide. But the tradeoff is this is days to months of my work.

And that kind of slows things down, but at the same time allows more people access. And that's totally valuable. These are the sort of things that if you're doing open source on your own, unless you've got good foundations to work from, chances are you might be missing a lot of things that allow more people to have access to these tools.

So... And that is super interesting. Can you give an example of some of that accessibility work that you've been doing? Well, the easiest one to think about is straight up, like, supporting multiple languages. If you're learning a programming language, do I need to learn English in order to learn TypeScript? Yes. Does that suck? Yes. And, like, you know, we now support Japanese, Chinese. There's Portuguese and Spanish support in the website already so that people can learn in their own language. And then they can, you know, they can write their variables in their own language, and some of the examples do now.

So localization is one form of accessibility. Other forms are, you know, supporting people about JavaScript on the website or making sure that, you know, tabs act like native applications. All these things just sort of come together to add up on time but make it so much more available to everybody.

Great. Another question is, if you see any real competitors to TypeScript on the horizon, by Konstantin Botny. Realistically, no. You know, I use Flow before I moved to TypeScript as a user. I think it's a solid type system that does a lot of work. But they have so much different goals and aims in the TypeScript team, which they have to deal with Flow's code, the TypeScript code base. We have to deal with lots of small, smaller, isolated code bases and do the entire community things and tools thing. So, not realistically, TypeScript's goals is to provide the language, but also provide all the tools for things like VS Code and JavaScript, and no one comes close on the VS Code and JavaScript stuff. Except the WebStorm people. They're doing really good work. But they also can lean on the TypeScript to work too. So they do that occasionally.

All right. And I'm sorry we can't, all of the questions. I would advise for people to join Orta in the speaker Q&A Zoom room later on. There was one more thing where there was ask for a picture or like a dog should enter the stage. I don't know if we're talking about your dog, about my dog, someone else's dog. Please specify what dog this request is about in the Q&A room and we'll see if we can make it happen. So as I said, Orta, thank you so much for your talk. People will join you in the Zoom room so they can ask the remainder of the questions and maybe look at your dog. I don't know. I would also say thank you so much. You're welcome. Have a good one, everybody. Black lives matter.