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

Rate this content
Bookmark

TypeScript is becoming one of the dominant ways in which people write JavaScript. The goal of TypeScript is to augment and not replace JavaScript – so how does the team ensure that the future of JS is always JS.

33 min
18 Jun, 2021

Video Summary and Transcription

TypeScript's influence in the JavaScript ecosystem and its alignment with JavaScript's goals and principles. TypeScript's impact on the industry and its popularity among JavaScript programmers. The goal of TypeScript to innovate in types without introducing new concepts to JavaScript. The challenges of running TypeScript on other people's code and making it a native browser language. TypeScript's compatibility with JavaScript and its aim to be a thin layer on top of JavaScript. The efforts to improve support for JS and JS docs and the pain points of transitioning to TypeScript. The accessibility work in TypeScript and the absence of real competitors in the market.

Available in Español

1. Introduction to TypeScript and its Influence

Short description:

In this part, we will discuss TypeScript's influence in the JavaScript ecosystem and how the TypeScript team aims to align TypeScript and JavaScript to create innovative solutions. We will also explore the attempt to replace JavaScript with TypeScript and gain insights into the goals and principles of the TypeScript team. Let's dive in!

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.

2. TypeScript's Influence and Popularity

Short description:

TypeScript aligns with current and future JavaScript proposals, preserving runtime behavior and avoiding new syntax. It focuses on inference to find errors and make code more maintainable. TypeScript's popularity is evident in its high usage among JavaScript programmers. It solves real problems in large code bases and serves as excellent PR for Microsoft. TypeScript's success contributes to the growth of Microsoft's development ecosystem.

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.

3. TypeScript's Impact and Playground

Short description:

TypeScript has a significant impact on the JavaScript industry. It aims to innovate in types without introducing new concepts to the JavaScript language. The TypeScript playground demonstrates the goal of erasing the type system and producing real JavaScript. While TypeScript used to add extra features to JavaScript, it now focuses on backward compatibility and encourages the use of modern JavaScript syntax.

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.

4. TypeScript's Influence on JavaScript Future

Short description:

TypeScript is a welcome contributor in venues where the future of JavaScript is discussed. The goals of JavaScript and TypeScript are aligned, but TypeScript cannot decide the future of JavaScript. Charging for TypeScript or making it closed source is not feasible. Microsoft must embrace extended JavaScript, but running TypeScript on other people's code poses challenges. Making TypeScript a native browser language is difficult without browser engine ownership. The web's nature and JavaScript standardization make supporting TypeScript in browsers unlikely.

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.

5. TypeScript's Influence and Compatibility

Short description:

TypeScript's future is in alignment with JavaScript and removing backwards compatibility would ruin TypeScript's reputation. Although there is a programming language called Static TypeScript that aims to convert TypeScript to C code, it is a research project and not aligned with TypeScript team values. TypeScript's goal is to help migrate away from TypeScript by compiling it to JavaScript. Babel will continue to support TypeScript, and there are other JavaScript type systems compatible with TypeScript's DTS files. TypeScript's competition in the TypeSystems space is beneficial for the JavaScript ecosystem.

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.

6. TypeScript's Influence on JavaScript

Short description:

TypeScript aims to be a thin layer on top of JavaScript, providing value at the tooling level. It strives to improve TypeScript semantics while maintaining close proximity to JavaScript. This approach makes it easier for JavaScript users to adopt and continue using TypeScript.

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.

7. The Evolution of TypeScript with JavaScript

Short description:

TypeScript regrets some of the changes it made in the beginning, like adding features to JavaScript before they were introduced. TypeScript now aims to push JavaScript in a positive direction and add features in hidden ways. However, TypeScript prioritizes stability and consensus before implementing new language features. By working with others and avoiding breaking JavaScript, TypeScript strives to be a good citizen. My name was Otter, and I believe TypeScript is cool.

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.

QnA

TypeScript Support for JS and JS Docs

Short description:

Let us know all of your favorite things. Have a good one. Ciao, everyone. Let's jump right in because we have a lot of questions and not much time for Q&A. Are there any plans to improve support for JS and JS docs? Yes, JS and JS docs is a one-person effort by Nathan Sanders. He does great work in the JavaScript ecosystem within TypeScript. My favorite TypeScript feature is the revised website coming out with 4.0. It will make it easier for people to learn TypeScript. Regarding running TypeScript code, it is better to transpile all your code first and then run it. Ts-node is solid, but doing the work ahead of time provides fewer moving parts in the system. Deno effectively follows this approach as an entire runtime.

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.

Pain Points and Corporate Open Source

Short description:

So, the main pain points for people to start using TypeScript are the transition from JavaScript-only projects to ones with richer tooling, the need for better documentation, and the desire for plugins that allow the use of JavaScript files with additional features. TypeScript's corporate open-source nature requires more effort in terms of support and accessibility work, but it also leads to building better and more accessible tools for everyone.

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.

Accessibility, Competitors, and Q&A

Short description:

Accessibility work in TypeScript includes supporting multiple languages, localization, and improving the website's usability. TypeScript has no real competitors on the horizon. Join the Q&A Zoom room to ask more questions and maybe see a dog. Thank you, Orta!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher