Sessions is temporarily moving to YouTube, check out all our new videos here.

TypeScript - Why Even?

Mike Barker speaking at Front-End London in August, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

The dynamism and flexibility of Javascript is what makes the language so great, so why would you want to add static typing and more traditional concepts to an already rich language? This talk covers why, and how, you can do this using TypeScript.


Hello, I'm Mike. This is my first talk so, I'm slightly shitting myself. Okay, so TypeScript, why even? Why bother with TypeScripts and what's the need? First of all, who am I? That's my mug. So I'm a senior JavaScript Developer at a company called Tictrac. We're based on Old St. and we develop a white label product, that sort of helps people make better decisions about their health. Previously worked in agencies in London, Bristol, Kent. Back in London now. Really enthusiastic art accessibility. And yeah, I'm a Bristol expat. This is my website, it's shit. But it's quite, it's quite accessible. I made a fine effort that it was accessible. I've also got a Twitter handle which is @mrdbarker, not Mr. D. Barker as most people like to refer to. So that, you can follow me. I pretty much just retweet a Scottish comedian called Limmy. If you know him, you know. So why JavaScript? First of all before we get on to why even TypeScript, we need to appreciate why even JavaScript. So it's versatile programming language with a low to medium barrier to entry. So I put low to medium just because if you like some of the new ES6 constructs, are a bit more advanced. So low to medium, you can start off really small and kind of work up build. With applications and all of that sort of stuff, right. It's built into every web browser. So you can be sure of it. If you've run it in one browser, it will run exactly the same in the other browser. And it's standards based through TC39 which kind of backs up that last statement kind of. And it runs in different contexts. So you can run it client-side, server-side, on certain low-power devices. And it's great for hover button styles as well. So if you've got a button and you need a different style when you hover over it, I recommend JavaScript. But you know, what's wrong with it? I mean, as great as those last statements were, apparently what's wrong with it, is that it's dynamic. So wrong, good, hm. It's dynamic, its constraints are not enforced at runtime, so there's not a type system that's enforced at runtime. There is a type system right? But it's not, you can make mistakes. Aggressive type coercion. That's what's wrong with it. Scoping issues, largely fixed with, excuse me, ES6. Classic kind of vast statement and having access to it somewhere else. That kind of stuff. And apparently it doesn't scale. Which is a big problem. Because we need JavaScript to scale. So what is TypeScript? So it's a typed superset of JavaScript, created by Microsoft. Which succinctly means that all, all JavaScript is valid TypeScript. Compiles to valid, idiomatic ES3+ JavaScript. Depending on your target. And it aims to fill the gaps of the JavaScript language. Or what Microsoft believed to be the gaps of the JavaScript language. And it's JavaScript that scales, so we kind of, we've got that one. And it's an open-source effort. So you can contribute on GitHub, open PRs in fact, that kind of stuff. So why use TypeScript? For medium and large size applications, and kind of managing, refactoring, this kind stuff can be time consuming, can be prone to error. Can be. Subtle runtime errors are less likely due to the static nature of language, the compiled nature of TypeScript. So everything has to be compiled, if it doesn't pass it, it doesn't succeed, you won't be able to run the invalid code in the browser. And it's self-documented code through type system and comments so, rather than defining your types in comments, you define in the language itself. And you can kind of back that up with comments to better, give up the developers for kind of better information. Also coding. And as such we develop, our developer experience is far richer. Because IDEs are able to kind of latch on to this. All of this information, and it's kind of made the developing experience far better. So what's it add? It adds a TypeScript as the name, which suggests ES6+ to ES3 transpilation. Kind of depends what your target is. But ES6+ so, new specifications, async await, that kind of stuff. Works. Refactoring support, so this is, this is largely a byproduct of what TypeScript brings. But, refactoring. And then extensible language service. Which kind of helps packagers, developers, enrich IDA behaviour. As I alluded to earlier, documentation that stays in sync with codebase without managing two sets of types. So you can be sure that you don't need to update your comments with type information as you update your code, which is how it should be. So it brings types, but JavaScript has types anyway. But these are some of the defining types so. Yeah stuff like boolean, number, symbol, string, Array, object. Undefined, null are actually now types of their own generics, enums. This should say more. Map weekset, map set, all of that sort of stuff. As well as user defined types so you can kind of extend the language with your endtypes. So how to write in TypeScript? You draw some circles. Then you write in TypeScript. Something. Profit! That's it. That's exactly how you write in TypeScript. Any questions? Okay. So how to write in TypeScript? So you're gonna instal the TypeScript compiler via npm. If you're not familiar with npm I've linked it. Let's assume that we have installed TypeScript globally. You create a TypeScript file. TypeScript file is just a JavaScript file but ends in .ts instead of .js. And then you run the TypeScript compiler against that. So, in the command line, in the directory, tsc yourfile.ts. And alternatively, you can create a tsconfig.json file with a set of configuration settings and then simply run tsc in the same window, that way you can target multiple kind of files, have different settings. Or you know, you can repack all of that sort of stuff or it works. Live demo. Here we go. Okay so all I've got, all I've got is a blank, blank thing, Visual Studio Code, cause that's what you have to use if you're a TypeScript developer, it's just a rule. Uh okay so we'll quickly initialise a project. Getting ahead of myself. Create a .ts config. of .json file. Save that for a minute. Quickly instal TypeScript. So I'm using MPM5+ so it's got save by default. There we go. Okay so we're gonna need a source and index.ts. Probably use alert instead. Just a bit better for debugging. Okay. So I, rather than installing TypeScript globally, I've just installed it locally so we can, hopefully, fingers crossed, run this, it will build if I've turned off that, we'll be able to see it. Hey, there we go. And we can run that in the browser. So obviously that's not really that impressive. But we have something compiling. So where first to start. So we have TypeScript for where you declare types with the code on after a type. So my variable. Let's say it's a number for example. 'Cause it's consigning to a signer. Because we're assigning it, in this case we could omit the type declaration, TypeScript, we'll know, it knows it's type of number. Let's assume we have a. So that's how we declare a type, a very simple type, obviously. So as I said earlier, we have kind of a string, boolean. And now obviously cause TypeScript knows its information, as soon as we try and, kind of go off track, then obviously this isn't gonna work. My variable too. We've defined it earlier, it has to be a string. So if I were to try and run this once. So far. Should be false. Okay. So type zero is not assignable to string. Which is fair. And my synopsis alluded to the idea that JavaScript is dynamic. So we can do something like a union type, which says that we can have a string or a number. In which case we can say, my variable equals two, and we can redefine it later. Sorry, a string there. And as I said JavaScript is dynamic. So we need to check myVariable2. In this case we've checked that it's a string so TypeScript knows it's a string. So then if we try and, in this case, that this would, this would work. But if we were to call, string methods on this, this would work okay. So I'm gonna go over here. Simple types. Just pick up where we were before. So we can, in this case, I've kind of got some stuff at the top there. We've got example1, example2 there. Any is a type, so if you've got something this can literally be anything. Then you can declare it as any. If you're running in strict mode and you didn't declare it was any, and you implicitly declared it was any, it's gonna fail. It just won't compile. So I got some other ones there. Union types. Kind of showing how you would check types at runtime and then do different things on that and retain the type safety that TypeScript gives you. TypeScript allows you to create other types as well. This should probably be an interface. But you can create other types. So user defined types that I alluded to earlier. Or you can create your own type that extends from an existing type. An arrayType where it can be an array of strings or numbers. That kind of thing. And there are lots of different ways you, I've kind of got these examples I don't wanna, focus too much on these. I'll link all of these at the end. Because we'll be here all night. So TypeScript type interfaces which you can describe objects, objects can have affects, properties, that kind of thing. Interfaces can be extended, which can be really useful. So and then, in a classic example, in iDog extends in iAnimal and kind of inherits everything. And iFish is an iAnimal and, has some additional properties on it in this case. Classes can implement interfaces. So the dog implements the iDog interface. Therefore it needs to have the canWalk method on it. Otherwise it's invalid. And the same goes for the fish. If I were to remove this, it's just not gonna work. So optional properties, which is very common in JavaScript. So your API or Library or whatever takes, some optional configuration, this is how you do it. Just a question mark. So classes are the same. It's type 2 out of JavaScript. So, well they're the same but different. So in this case we can define properties as being private, protected, public. That kind of thing. Public, static. Yeah. And we get some kind of syntactic sugar in that we can define the values of these within, well outside of a constructor. So this will, this block here will essentially get hoisted down into the lost section of the constructor. First line, constructor past tupicle. So we can also set private, public, protected that comes in on the constructivist kind of stuff. Extend classes. If we were to, start calling superextends on the above class it's not gonna work, types aren't right. TypeScript is, type safety, it's just not gonna compile. And this example is how you would achieve polymorphism or parametric polymorphism by overloading a method that takes different types in and outputs different types based on the input types. I'm gonna skip over just a couple examples. These are all gonna be on GitHub. Or they are on GitHub. A practical use case is, all the cool case light react. So how you might create a react component. So this is a react dot stateless functional component. I've defined an interface up here. That describes what props it can take in. They are actually some enums from another example. But it's also on GitHub. And then we just check it and we output some different JSX based on that. So when we then consume, if we were to pass in different configuration that wasn't accepted at all in a predefined way, then we would get errors, when you try to compile that. So hopefully this kind of demonstrates a practical use case, like I said, these are all on GitHub so, you can, I've tried to put loads of comments on there. So people can follow free. Okay. So that was the Live. Oh I've lost the clicker, there we go. So in the interest of being open minded, why wouldn't you use TypeScript? So small projects with minimal JavaScript. If you've only got a few JavaScript files and they're simply adding events and that sort of stuff, you have to question the added complexity of build processes are really gonna benefit you. Is it really worth spending your time doing that? And alternatives such as Flow may make a bit more sense to your project. So some links. Code examples. TypeScript lang, where you can find out more about TypeScript language. There's Roadmap. The Weekly newsletter, great post by Tom Dale around why Glimmer chose to use TypeScript. My shit website and my Twitter. So yeah. Thank you.