This course has been updated! We now recommend you take the TypeScript Fundamentals, v3 course.
Transcript from the "Introduction" Lesson
[00:00:00]
>> Mike North: First, let me introduce myself, my name is Mike. And I work at LinkedIn, where two things I do make me a great person to talk to you about TypeScript. Number one, I run the developer training program, so I am a workshop instructor for the company. Where I help level up all of all of the engineers there, in a various array of topics, including TypeScript.
[00:00:25] And number two, I am a tech lead on the front-end stack, where I predominantly focus on TypeScript adoption, right? On making it so that if teams wish to use TypeScript with their project, everything works smoothly, and the documentation tools work, and all of the linting works nicely. So I have been knee-deep in this area, and I'm so happy to be here to share a lot of what I've learned with you.
[00:00:57] So first, before we jump in, and we're gonna get our hands dirty really quickly here, within about 10 minutes. Let's first pin down exactly what TypeScript is, so we know what to expect. So it's an open-source programming language, primarily, it's maintained by a core team of developers at Microsoft.
[00:01:17] And it's a typed, syntactic superset of JavaScript. What that means is, if you take TypeScript syntax, you can kind of see JavaScript's syntax within it. It does not mean that every JavaScript program can happily run through the TypeScript compiler without any errors. So there is sometimes confusion about that.
[00:01:39] Now, it's true that if you loosen up the TypeScript compiler, and kind of set it in the most flexible possible mode, a lot of regular JavaScript programs can make it happy. But there are inherently things you can do with a really flexible, dynamically typed language like JavaScript, that will never make a strongly typed language happy.
[00:02:04] TypeScript compiles to readable JavaScript, and it has no runtime part, no runtime component. What that means to you is that the types disappear in a build step. So you're just really, you can almost think of it like a static analysis tool that does a lot of checking on your codebase.
[00:02:24] But when you have that build that you're sending to your users, or that you're running in Node.js? Unless you do some really exotic backflips, none of that type-checking is there. And that's good in some ways, and that's bad in other ways. It's good in that there's no cost at runtime, right, it's not gonna slow your app down.
[00:02:48] Runtime type-checking, that's extra code that every user in every browser is gonna be running. So TypeScript disappearing in a build step is good there. But of course, when you're receiving some data from a fetch, or you're getting some input from a user? It's important to understand that there's really no type-checking that's gonna happen there, because at that point, it's just a JavaScript program.
[00:03:20] So the project kinda has three things inside of it. There's the programming language itself, there's the language server. Which is a program that kind of feeds your text editor a lot of great information that can manifest itself in auto-completes and tool tips, as you hover over various things.
[00:03:41] The language server is sort of something that you can query about, what's going on with my program at this point? And then there's the compiler, and that is used by the language server. But it is what actually performs the type-checking, and it is one way of taking TypeScript files and emitting JavaScript files.
[00:04:04] A huge advancement that came along with Babel 7, and Babel's what's let us take modern JavaScript, and kind of boil it down so that Internet Explorer can run it. And so you can just simply state which browsers you care about and you get something compatible. Babel can now take TypeScript files as inputs.
[00:04:24] Now, it's important to understand that no type-checking is involved in there. Babel kind of just knows which parts of the TypeScript code it can eat and ignore, leaving only the JavaScript behind. So you definitely wanna use the TypeScript compiler side-by-side with Babel. But the important advancement there is, you have one piece of tooling that's responsible for creating your JS files.
[00:04:52] You don't have to worry about, how does TypeScript represent a class for Internet Explorer? How does Babel represent it, and is there gonna be a collision there, so you can have a great assurance of consistency. And almost think of the TypeScript compiler as a really fancy linter, or another static analysis tool that just kind of verifies that everything looks good, but doesn't actually produce output.
[00:05:19] So since I taught the last version of this course for Frontend Masters, which was in 2017, we've seen a 300% increase in downloads. And we can see, this is a monthly download graph on the bottom. We can see that it's basically matched React, in terms of popularity and prevalence of use.
[00:05:42] So NPM does a survey every year, and they ask their respondents, what flavor of a JavaScript-y language do you use? CoffeeScript, or do you use ES6, or ES5, or TypeScript? And it turns out, 46% of respondents said that in some part or another of their programming, they make use of TypeScript.
[00:06:08] And if you look at all of the packages in NPM, over 40% of them declare TypeScript as a dependency or devDependency. So you're probably using it, even if you don't think you're using it. You're using something that's written in this typed language, and depending on that type-checking. And potentially, you could take advantage of that type information.