Drew McLellan: He’s a web developer and web lover based in Linz, Austria. Currently working at web performance company Dynatrace, he writes, speaks and organizes events all about software development and web technologies. Lately he’s the author of the book TypeScript in 50 Lessons, published this autumn by Smashing. So we know he’s an expert in TypeScript, but did you know he can juggle up to eight fiery weasels whilst blindfolded on a unicycle? My Smashing friends, please welcome Stefan Baumgartner. Hi, Stefan. How are you?
Stefan Baumgartner: Hi. I’m smashing. I didn’t that about me, so that’s very interesting.
Drew: It’s amazing what people find out about themselves on this podcast.
Drew: So, I wanted to talk to you today about TypeScript.
Drew: It’s the subject of your new book, so clearly it’s something you’ve spent a lot of time getting to really know in depth.
Stefan: Yes, absolutely.
Drew: For those who have not used TypeScript before, so might not be familiar with what it is, how would you describe TypeScript, and what problem is it actually solving for us?
Stefan: And TypeScript tries to give you a type system around all that, to give you this information. So, it tries to figure out which types you set when assigning variable. It tells you which function signatures expect which well use at which position, and which return objects that you get that you can then access and modify and work with.
Stefan: Yes, yes, this is exactly what it is. So, the strictness is totally up to you. So you can tell TypeScript how strict you want to have it. But their goal is to catch as much errors, or as much possible errors, that there can be. Like oh well this value could be null, so better do a check if this value you exists or it can be undefined. Or, at this position I don’t exactly know if it’s a string or a number so check if it’s type of string, check if it’s type of number.
Stefan: So TypeScript knows more, or can give you more information about the class of failures that you’re dealing with. And right now, the main goals of TypeScript are to catch as many errors as there are. So they spent a lot of time in providing more tools for you to declare your types and to declare the strict rules for you to figure out if there’s any error in your code that you might have a problem with in the long run.
Stefan: There’s weakly typed, and another word for that is also dynamically typed, which means that you don’t always have to know which type your variables or your constants have. So, the moment you assign a variable, let’s say var fu or let fu with a number once you forget something, the cross-credentials say fu is now of type number, it’s a number and I can’t do number operations on top of it, like addition, multiplication, subtractions and all those kinds of things. If you assign it a string then it’s a string.
Stefan: And, with TypeScript, you can explicitly set the types or you can tell TypeScript to infer a type from an assignment. So the moment you assign one to free, TypeScript knows, Hey, this is number, and throughout your whole code, throughout every user through, it will think it’s a number and it will tell you if you do something that is not allowed with numbers. So, yeah. And this is the difference between a statically or strongly typed language, where you say, okay, once it has the type it has to be of the type and the type can’t change afterwards. In the weakly or dynamically typed language where the type just depends on where you are in your code and it can change, especially at run times or during the execution of the code, which can cause a ton of problems if you don’t pay attention.
Stefan: Exactly. The best example is for, for example, at the string two, with the number two, and you get 22 as a string, at the number two vice-versa and you get the number four. So, it’s apparently the same operation, but just if you swap the number in the string you get two totally different results. And TypeScript pays attention that it don’t have errors like that. And the one biggest rule that it sets like, so once you do an assignment, it has to be of that type, and the type can’t change.
Drew: Type checking is one thing, but surely that’s the sort of thing we can, we don’t need a new language to do. That sort of analysis we could just have running in a code editor in a VS Code or whatever for example. Does TypeScript add things that take us beyond just what you could do in a code editor?
Stefan: So, editors and language are very, very much connected and you get the best benefit if you’re working with modern day editor. And thanks to the TypeScript team this doesn’t have to be VS Code. It can be basically any editor. So the proactive blankets for almost any editor out there that supports a so-called language protocol. There also getting it for all the other programming language, feedback and editor feedback, and analyzing information.
Stefan: So, yeah. This is actually the main use-case for that. And, of course, if you have bigger projects and you used to compile stepped version of TypeScript, having some sort of continuous integration, continuous delivery, where you constantly check if your project makes sense, you’re creating bundles that you should begin, this is also a part of TypeScript plays a huge role because with every commit to a GitHub repo or something you can do type checks and see if there might be an error slipped in that should be taken care of.
Stefan: And one thing that’s particularly interesting here is that TypeScript is one of the few and certainly the most popular type system that works with structural typing, which means that as long as the shape properties and types of those properties is the same as the object that you pass along or the object that you get from somebody else, it will say it’s okay. You don’t have to have the exact name, it just needs to have the exact structure. So if you have a type called book which happens to have name, description, and price and you have a type called video which happens to have name, description, and price, those types are compatible with each other.
Drew: Okay, so that means we can sort of define customer types that make sense in terms of the project and the objects that our project is trying to model and then use TypeScript to enforce the shape of those.
Drew: So if we’ve got a product that has a price property that’s an integer in sense or what have you, then TypeScript will enforce that for us and if we pass in something that’s not a product or doesn’t have a price or whatever, that’s when we start getting our errors. Can you then go sort of step beyond that if you had like a cart type that had an array of products inside it? Can you enforce all the way that level?
Stefan: Yep. Yeah, exactly. You can enforce that as well. There you enter also a class of types which is already goes into very advanced topics which is generic types. So, the array type is a generic type. It tells you an array has certain interest so you can index them. It has a certain properties like length or map or for each, but the well use inside this array are defined by a so called generic. So you can say you have an array of number, you have an array of string, you have an array of articles.
Stefan: So, and this is actually where the fun starts. The thing like creating object types, creating regular types like number, string, etc., or creating function types that’s one thing. But if you try to model a very complex behavior just within the type system, this can get very, how do I say it, mind boggling. Yeah, I guess mind boggling is the right word. This can be very mind boggling, but also a lot of fun.
Stefan: And this is where I kind of got my, found my call to work more with TypeScript because I just found out that I could do so many that I see in, not only in my code but in the code for my colleagues and code that I find online, to make more sense out of it and to be prepared for future scenarios. So, I mostly write types in TypeScript because I know that at some point in time I have to revisit code and I want to know what I’ve been thinking back when I originally wrote it.
Drew: Where is in your project that you would define these types? Because presumably you want them to be reusable all around your project. Where do you define them?
Stefan: If there’s a type that is used throughout the whole project, I’m not only expecting the type, but also the objects or the functions for that objects. So this is some way of splitting and moving files and types around. There’s a very rare case where I also have one of those global type finishing files next to me, which is if my app has to deal with something that’s in the environment where I run it, be it either node or browser or whatever, where some global ideas or global concepts are that I want to carry in my program and hold. And this is actually a pretty standard set up.
Stefan: So you have your TypeScript files on one side, you have couple of type definition files on the other side, and then TypeScript tries to figure out everything, if it makes sense and if it’s possible to do and hopefully that’s the case.
Drew: Yes, I think we’re all very sort of used to having a build step, combilation step, in our work flows these days, aren’t we? With whether it’s running Babble or dealing with JSX and React or Web Pack and what have you so…
Drew: I guess adding TypeScript into there is just another small step in the process and quite easy to do.
Stefan: Yeah. So it’s, on one side TypeScript is a great extension, especially if you have a Babble set up running. So they provide an interface where you can do TypeScript type checks, even though your whole application is transpiled with Babble. TypeScript also has a lot of tools so it can be the only transpiler that you need. So it can transpile JSX, it can transpile down to Equiscript 5, Equiscript 3. The only thing that it doesn’t do anymore is bundling. So if you want to have bundled up application you need to take another tool like Roll Up or Web Pack or whatnot.
Drew: One of the features that I liked in newer versions of PHP, back when I was writing a lot of PHP, they brought in the ability to declare the types of each argument that a function was expecting. TypeScript does the same thing, right? You can say the first argument should be a number, the second argument should be a string-
Drew: … and then the tool sets going to catch that if you try and pass the wrong thing in.
Drew: In a lot of sort of real world cases I find that I have function arguments or variables that would be of a given type, but there might also be null. Is that something that TypeScript allows for?
Stefan: Yep, yep. So, this is where you enter the wonderful world of Union types and this is the big chapter in my book in the middle where we go from beginner concepts to advanced concepts. Where we realize that you don’t, not only have different classed of types like numbers, string, or several object types, but you can combine them. So you can say, this argument can be of type of string, of type number, or of type null or of type undefined, or for some object type. And with that your arguments, especially function arguments become much, much more varied.
Stefan: And with this one little addition, like make sure you check for your null-ish values and if you don’t allow null-ish values they can’t be null. This erases a whole clause of errors that you would otherwise encounter. And this is also one lesson in my book where I just talk about this one compile of next trick null checks and what it means for your work and what you suddenly have to do. And at some point you realize, okay it’s much more tedious to add pipe null to every possible case where it could be null, instead of just for one time in one place of your code, check if it’s actually null and then just continue with what you did. So, that’s a very nice way of working with null and undefined values.
Drew: A lot of sort of more formal languages, OO type languages, have classes and give you the ability to define a class interface to be able to say if it’s a class that uses this interface it needs to have these methods, it needs to behave like this. Is that something that TypeScript gives us?
Stefan: You also can implement, you know the implements keep it exist, you can implement an interface, you can implement a type. There are, just in some rare cases, effective to some rare cases there are totally the same. So, yes they exist, but they mean something different than your used to from other programming languages. And this is also something where I’d say people who come from other programming languages have to look out for things like that because they can be false friends. Where you, they think, Okay, oh this just works just like in Java or this works just like NC Sharp, where in turn it’s just borrowed language or it’s just the same names for concepts that are nuanced and somewhat different than to what you would expect.
Drew: It can be a real sort of mental hurdle to jump over, isn’t it?
Drew: If you’re familiar with a name meaning one sort of thing and now it means something else.
Stefan: And this is, I guess, what makes TypeScript so special. When I started working with TypeScript, like seriously working working with TypeScript, the things that it most was like having a react component and being super happy that if I press control space that I get all the name of the properties my function component would expect. So this alone helped me a lot and it did nothing else but using this feature for a very, very, very long time. And then I started, in some sort of library code that I created for my colleagues or for people who I work with, creating a type core set around my function so people who use my code know better what I meant when I wrote those particular functions. And there I go all in. I’m very deep, deep down the type system rabbit hole.
Drew: Yeah, I mean that’s interesting. In the last episode of this podcast I talked to Natalia from Vue JS all about Vue 3 and one of the big changes they’d made in Vue 3 was that it was rewritten using TypeScript. How important is it for libraries and frameworks to adopt TypeScript? What benefit is that actually providing those who are working with the library and not on the library code itself?
Stefan: So, I think for one part you get a lot of implicit documentation. Especially if you import Vue or React, React is kind of a mixed bag, but if you import Vue or Preact for that matter, Preact is also written in TypeScript. People who use your framework immediately have some information about all the functions and all the objects that they get without you needing to look up anything and you get some extra checks if what you’re doing is the right thing to do.
Stefan: So that’s a lot of implicit documentation for all the users of those libraries that you get, basically for free, if you start writing in TypeScript anyway. So every project that is written in TypeScript gets, produces all this extra information for free. I guess as a team, as a library author, it makes contributions a lot, lot easier for the same documenting reasons. It also makes checks a lot easier because there’s a whole class of errors that you can catch in the type system that you, that would take ages to catch in tests. That’s why nobody writes test for that, especially if this is of a certain type, kind of tests.
Stefan: But also, I think, especially when you have lots of people working in the same hole base or lots of people who need to work with each other, this can be an additional layer of guidance in your project where you don’t have any bad surprises in the end. So, of course technology doesn’t solve any communication problems. This is not what TypeScript is intended for, but it can lower, it can make lot more room for the right discussion then, if you don’t have to talk about what do you expect from me in your code, but rather what should your code do or what should your library do.
Stefan: And, I always say that if you ever write code for other people or if you write code with lots of people or if you just write code for yourself, you have to revisit the next day, consider TypeScript because it might help you in the long run. And this is not just an investment for the next project of next week, but more for one who say, Okay, especially if long lasting projects for month, two, or years. Definitely offer that. You’re never going to know what you’ve been thinking of when you wrote the little piece of code one year ago, but types can give you a hint of what you meant.
Drew: And I guess we could go through all sorts of those benefits, all sorts of features that are in TypeScript, we could go through them blow by blow, but it doesn’t necessarily make sense to do that in a podcast. It’s difficult to describe code, isn’t it?
Stefan: Oh, you an write an entire book about that.
Drew: Are there any particular features of TypeScript that you’re most excited about or think provide the most value to users?
Stefan: I guess one of the features from the type system that I like most, which is again advanced but not super advanced so that it’s easily graspable, are union and section types. Where you can say, Okay, this argument or this variable can be not only of this type, but also of another type. Or it needs to have features from this type and this other type. And if you, once you realize that you can make use of that, you suddenly can model your application a lot, lot better.
Stefan: So, I adopted a work for where I tried to think about the object and the functions that I have, like what do they expect, what is the data, how are the properties designed. And then I tried to work with them as much within functions and if you use an intersection types you can, you have so many tools of modeling your data that if you spend a little time doing that you catch a ton of errors and a ton of problems up front without spending too much time into, in TypeScript land.
Stefan: And that’s why I guess they would be my most favorite feature. And also the fact that TypeScript transpires everything. I don’t need any Babble or any other transpile and I’m pretty tired of having too many tools that I need to use. So if I just can rely on one tool and maybe another one for bundling, that takes a lot of noise off my mind. So, that’s what I’m also very thankful for. It can just do a lot.
Drew: You’ve written about what it can do in a new book for Smashing. Loads of great information for people who are wanting to learn TypeScript. So, what sort of developer is the book aimed at?
Stefan: So, this was one thing that I really cared about when writing this book that once it’s out it should have some relevance in years to come. Especially with TypeScript getting four releases a year, you never know all the features and you can’t express all the features. But you can express, or explain, how the type system works. And from that on you figure out the things on your own. And this is what we do, so we give a very in depth introduction into the type system.
Stefan: First, in the first four chapters we guide you to the point where Okay, yeah, you know how to assign types, now you know how to work with types. Then there’s this water sheds chapter where we go into unit intersection types and from then on you learn about type modeling and about moving into types system. And after you read the last few chapters, we had seven chapters in total, you should know everything, to be prepared for every single TypeScript that there is. And for every new class of types they introduce and for every new class of errors they try to solve.
Stefan: And it took me quite a while to write this book to be honest, so me knowing that it didn’t have to change the table of contents and it didn’t have to introduce any new concepts over the last 1 1⁄2 years to me is proof enough that we succeeded in that. So, maybe we snuck in one or two features from TypeScript 4.0 but not all. So all the learnings that you have are still well it even though we, I designed them 1 1⁄2 years ago. So, yeah this is the main goal of the book. And it’s kind of what we see in the tag line. We want to take you from a beginner to an expert. And I hope we succeed with that. Yeah.
Drew: I certainly found reading the book though because it is broken down in, you know it’s 50 lessons so it’s all in sort of fairly bite size chunks, and I found that I was able to start using all of that straight away. You’d read about something and then you could start using it. It’s not one of those books where you have to make it all the way through to the end before you can start being productive.
Stefan: Yeah. Yep. Absolutely.
Drew: Very easy to just sort of drop in and drop out of which with many of us being so busy and under so much pressure in our jobs and things at the moment, it’s great just to be able to read a little bit and then forget about it for a while and then come back and read a bit more.
Stefan: Yep. This is also something that we take a lot of care, that we really cared about to achieve. It can be really overwhelming to learn a new language. Especially a new programming language. And so those bite sized chunks, you know you just spend about five or maybe ten minutes with one of those lessons. And you can immediately apply the learnings of those lessons to some actual code and we provide you with all the code examples online. So if you go to TypeScript-Book.com you see a list of all the code examples that there are.
Stefan: And this helps you just getting in as much as you need and as much as you like and it gives you also a lot of room to breathe and to take a break and to get your mind off of it and then revisit back later. This is also by the edit some interludes in between chapters which are mostly non-technical. They give you little bit of TypeScript culture, little bit of ideas how the TypeScript team thinks, how the community thinks, and how writing good TypeScript code because you without actually focusing on the coding aspect. And we also added those to give you a little break, a little room to breathe, to digest what you just learned because we know that this can be a lot of stuff. And, yeah, so if you just take one lesson a day, you are through with it in 50 days and are an expert in TypeScript, so.
Drew: I often find that when I’m writing about something I’ve been putting together a presentation or an article or something like that, I find that I learn new things that I didn’t appreciate before because having to explain something, you have to make sure you really understand all the details. Was there anything that you found about TypeScript in writing the book that you realized you were learning for the first time?
Stefan: So this was one thing there. I kind of lost track at some point while writing it because it was just spending two or three days within, in those lib.d.ts files and soaking up everything that they created. I even have one lesson dedicated to lib.d.ts because it was so, so surprising. And the other thing is, I guess, realizing how generics and conditional types really work under the hood.
Stefan: Because when you apply them and you work with them you just use them as much so you get the right results, but you never question what’s actually making them work and by explaining them in chapters five and six in my book I really found out there are very delicate mechanics underneath and if you understand those mechanics it gets a lot, lot easier creating conditional types, creating generic types, than it would be without just by trying to figure out things. That’s why I also have some flows of code in my book where we start with the conditional type that you write and then we go step by step evaluating what it means until we get to the result type.
Stefan: And this is something where I found some joy in it because it really made me understand what my book should be actually about. That I spend a lot of time and cared a lot about getting those examples right, so. I hope readers will find the same joy out of it because it can be very, very interesting. And, yeah, it gets a little bit nerdy, but that’s part of the fun.
Stefan: So, he spend so much time into refactoring every bit and piece of the whole website that it’s now a great learning resource and Otta also, has also written the forward to my book and were chatting about how a book on TypeScript can or should be different compared to what they provide as a learning resource. And I think they work really well together. The book gives you a very tailored and opinionated view and the learning resource that guides you step by step whereas the handbook is this big knowledge base where you get all the additional information and can dig deep into one specific scenario that wouldn’t have enough room in a book.
Drew: Stefan’s book TypeScript in 50 Lessons is available digitally from Smashing right now and it’ll be available in print from November 2020. You can find it at TypeScript-Book.com. So, I’ve been learning all about TypeScript. What have you been learning about lately Stefan?
Stefan: I’m digging into different programing languages again. I’ve been learning a little bit of Go and a little bit of Thrust and what scenarios there are for using them and it’s fun learning something entirely new. It gives you a new perspective on what you already learned so far. So, this is what I enjoy a lot at the moment.
Drew: It’s always exciting, isn’t it? Learning a new language and getting a new perspective on how other languages are structured.
Drew: If you, dear listener, would like to hear more from Stefan, you can follow him on Twitter where he’s DDPRRT and you can find his personal site at fetblog.edu. TypeScript in 50 Lessons is available now from Smashing and you can read all about it at TypeScript-Book.com. Thanks for joining us today, Stefan. Do you have any parting words?
Stefan: Thank you very much. No, well, DDPRRT is the worst Twitter handle in the entire world and if you say it very fast it’s dead parrot, and if you know Monty Python, you might know about the dead parrot. So, that’s all I can say about the worst twitter handle that there is.
Drew: He’s pining for the fjords.
Stefan: Yeah. But, seriously, I hope people enjoy working with TypeScript. I hope they enjoy my book. I’m really, really excited about feedback, so if you have any feedback hit me up on Twitter. I’m here to chat with you about all that stuff. And I’m also very happy to work with you on type programs. If you have something that you can’t quite make sense out of it just drop me a line or a Twitter direct message. I really take the time to see if we can solve the problem.