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

Alright, start betting on typescript. So, I'm going to try and talk a little bit about typescript's influence in the javascript ecosystem, how the typescript team try to constrain themselves in order to make sure that typescript and javascript are both allies in trying to make cool things in javascript, and then what does it look like if there was an attempt at trying to usurp javascript via typescript via the team at Microsoft. 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, let's get started. My name is Orto 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 across many different programming languages that allow you to create limiter rules around how pull request etiquette works. I spent a lot of time quite recently just working in the typescript era, trying to figure out how to build complicated tools for it and how all these pieces come together. That eventually turned into me working on typescript full-time. So now that means I've got quite a lot of insight that I think would be super useful and is kind of unique, so I'm going to try and talk about how all that comes together. So the goals of this talk are to try to make it a little bit different from your average typescript talk. Most talks about typescript try and talk about what features are useful or how it provides useful editor tools, things like that. But this talk actually takes a step back and tries to think about how typescript affects the entire industry and 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 all together. 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 good bug tracking and making sure that typescript is as bug free as possible. The team itself has a few long term goals and principles. The two main documents around this, there is the operating principles. These try to describe what the typescript project represents. So what is the long term goal? How do we perceive ourselves in relation to other programming languages versus in relation to other javascript style, transpiled to javascript programming languages. These just sort of say, this is how we define ourselves. And then the other one, and potentially the more interesting one for this talk, are the typescript design goals. There's a lot here, so we'll kind of split it into two. So there's the design goals for interacting with javascript. So impose no runtime overhead on emitted programs is highly jargoned 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 aligning with current and future 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 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, 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, there's javascript and then there's types, which is the types of typescript. And 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, we try to find 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 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 at this came from Stack Overflow. Stack Overflow is a website that you can ask questions. But one of the interesting things here is it's not a javascript specific developer ecosystem. It is an all developers use Stack Overflow 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 oriented to a particular 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. This is a bazillion javascript programmers, so there must be a third of a bazillion typescript programmers. And, you know, you might be wondering to yourself, OK, so it's popular, people like it. There's also like a question that 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 codebases at Microsoft. And the other part is that 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, well 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. You know, for typescript there are effectively two audiences. There's typescript users and there's javascript users. And there's a whole lot of javascript users in the world. I always try and think of our user base as this kind of like narrowing down set of people where there is just a lot of javascript people, very few javascript and javascript.people. And then people migrating further down is like a goal, but they can stay where they are. And that's done by tooling all those levels and that is done by providing IDE features to everybody. So effectively, typescript is big enough to be like kind of has an impact on the entire javascript industry when changes are made. And so generally I like to think of, you know, a bet on typescript is a bet on javascript nowadays. And, you know, the reason is that 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 at the expression level. So to get you an understanding of what I mean here, I'm going to show you sort of, well, I'll show you the playground. So this is the typescript playground. It's an online place to 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 call on 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 is 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 submitted that is done to sort of add this extra feature to javascript. But that's not like where typescript is nowadays, but that's where they used to be. And you know, as time moved on, then typescript actually 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. And so typescript likes to think about it as like the expression features are removed. So you know, my 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 you know, there's many ways now that people are starting to replicate those features using modern javascript syntax. And that's what we encourage. The tc39 bit is interesting. typescript and tc39 are a best bud. If you've never heard of TypeTC39, it is a meeting that occurs every quarter. They basically bike shed on the future of javascript. tc39 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. They go through stages. And you know, typescript is there and it's a welcome contributor. All of these different venues where javascript is sort of being, where the future of javascript is being discussed. And we're just a contributor at 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. So 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 on 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 sort of malevolent version of typescript, right? 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. For suddenly typescript to turn around and start charging money for it or to go closed source is just not really very feasible. The co-creators of typescript, Anders Heijlberg, he created C Sharp as well, Pascal I think. He said that 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. So that should make it easy, right? Barely an inconvenience. 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 to make typescript a native browser language. And if this was back in the IE6, 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 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. But one of the biggest pictures against that is actually that the web isn't something like deno or Node where you can sort of pre-compile and pay the cost of transforming typescript to javascript. Browsers only ship one version of javascript and they've never needed to use Babel, for example, so they're not probably going to support something like typescript. You could make typescript differ from javascript. Start taking the features that people don't want in javascript out of typescript. First of all, there are pretty regular demands for this. 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. There's times when people want that. typescript could conceptually be removed from the language by making that stuff cause errors. But at the end of the day, typescript's future is in alignment with javascript and starting to pull apart javascript and removing backwards compatibility is going to really ruin our reputation with tc39 who control javascript. It's going to really annoy people to 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 new compiler errors as we improve error detection, but to go back and start regressing on things that have existed for a long time means that you can't do javascript in, javascript out. And realistically, because it's open source and there's a lot of contributors, someone would probably start a fork and that seems totally reasonable. And so there's just not really that much incentive for the typescript team to sort of extinguish javascript by trying to 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. And so they can't have a lot of the weird runtime trickery involved in javascript. And 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 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 convert to C. So this is a research project. It's definitely not typescript team values, but it's an interesting 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, typescript's goal would literally be to help you migrate away from typescript. 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. Babel is never going to stop. At this point, Babel is probably never going to stop supporting typescript in some form. And there'll always be things like Babel plugins or code mods that help you go from typescript to TypeScriptian or whatever. And then finally typescript has competition and that's really great because it keeps many people using TypeSystems across javascript. I want all of them to succeed because anytime you interact with libraries, I would much prefer that it has the stronger foundations by being statically analyzable. And there are even new javascript TypeSystems that aim to have compatibility with DTS files from typescript. So it's unlikely to happen that way. So it's unlikely to happen at all in my opinion, but that's why there's not that much incentives for typescript to do that. Then there's the typescript de-isolating itself. typescript used to be about using TSLint and you'd have these different tools for typescript in the world, but nowadays you have Babel and ESLint and a lot of people are using the exact same javascript tools they used to use, but for typescript. And that means that we can just keep typescript as this thin layer on top of typescript and providing value at 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 typescript succeeds in my opinion because it's so close to javascript semantics. There are so many great languages that provide much better safety, but they move further away from what javascript is. 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. And typescript regrets some of the changes it made in the beginning about adding features to javascript. typescript added classes before classes came to javascript, but luckily it guessed the syntax correctly or the syntax was highly inspired by typescript's work at trying to figure out what a class should look like in javascript. Enums are something that could come back into the language through tc39. There is a proposal for it, but it looks a little different. So 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. And 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 dot operator. This is a proposal that someone else made that typescript team adopted and 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 anyone could do something with it. And that was easy and accessible. When it was added to typescript, it was thousands of lines of code, had billions of tests, and realistically not that many people could do it. And 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 code base, and that's really complicated. So that's realistically the main reasons why typescript puts constraints on itself. design constraints to try and force ourselves into doing it the right way. We prefer working with other people. There's 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 code bases. So that's what typescript team does, and that's how we try to be a great citizen. My name was Otter. I believe that Black Lives Matter. I also believe that you should go protest if there's someone in your city. I think that typescript is cool. If you're using it, great. If you're not, maybe try it. And let us know all of your favorite things. Have a good one. Ciao, everyone. Hey, Elle. 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 are effectively a one-person thing, and he's always hammering on it. I think he's been working on and off of 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? We can bother them. 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 of the new stuff in that. 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 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 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? Like 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 like 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. And I think there are like these kind of transition points that need better documentation. So like jumping from a javascript only project to a javascript only project with richer tooling, like we generally call it JS plus JS doc. Like jumping through those transitions I think could be much easier. And that will move people down towards a stricter, tighter, 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 for typescript. So helping the transitions between those migration patterns is one of the biggest things I think that we can do. Yeah. Which maybe is where docs comes into play as well, right? Huh, 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 spells 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 entirely in the typescript project. 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. And I think that's some of the... It's not like... No other languages have plugin systems. So it's not really something you could 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, very easily. We're not saying stealing, we're saying inspired by, right? Yeah. Great artist steal. All right. 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 or? It's an interesting question. I think that leads to 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, like within the last decade, changed their mind 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 the time to sort of 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 building better and more accessible tools makes it available for everybody and rises the tide. But the trade off of this is days to months of my work and that kind of slows things down, but at the same time it allows more people access and that's totally valuable. These are the sort of things that if you were 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 a lot more people to have access to these tools. 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 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 write their variables in their own language. And some of the examples do now. Localization is one form of accessibility. Other forms are supporting people about javascript on the website or making sure that 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. Right. Another question is if you see any real competitors to typescript on the horizon, this is by Konstantin Botnia. Realistically no. I used 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 than the typescript team which they have to deal with flows, the type of place with codebase. We have to deal with lots of smaller, isolated codebases and do the entire community things and tools thing. So not realistically, typescript's goal is to provide a language but also to 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 work too so they do that occasionally. Right. And I'm sorry we can't, you know, all of the questions. I would advise for people to join Orta and the speaker Q&A Zoom room later on. There was one more thing where there was asked 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 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, so thank you so much. You're welcome. Have a good one, everybody. Black Lives Matter. Thank you.