Why you should learn TypeScript.
Dennis: Welcome to a new podcast episode, you may already know me from previous episodes. My name is Dennis. I'm a software developer at consistec. And today, I brought you a colleague of mine, Lucas. Lucas, maybe you can introduce yourself.
Lucas: Hello, I am a software developer at consistec as well. I have been working with TypeScriptfor the past three or four years and Java before that.
Dennis: Yeah, you mentioned it already TypeScript, today's topic will be about TypeScript. That's the language that you are very passionate about. And we want to explain people today, why TypeScript? What is TypeScript and why we think it's really interesting for many software developers, and especially front end developers to learn TypeScript. Maybe you can give us a little overview of what we want to discuss today.
Dennis: So, you mean in retrospect, it can only be called with a power meter with the type integer, for example?
Lucas: Right. This means that with TypeScript, you eliminate this entire class of potential sources of mistakes, these type related mistakes, you get it at compile time instead of runtime. You don't have to spend any effort looking after them if the compiler just tells you straight away where the mistake is.
Dennis: So, in a sense, it's basically just another tool for the developer, this old typing syntax. It helps you to write code in the future, because it gives you this early feedback: okay, you call the function here with parameter values. They don't fit into the type definition of the function.
Lucas: Yes, exactly. TypeScript doesn't actually have any effect on runtime. So, it's purely for the developer, right. Allows you to see how things are supposed to be used.
Lucas: Correct. That's the biggest advantage of typed languages, you eliminate a whole class of potential errors. Like you catch them at compile time, you've been told where they are, instead of having to find them at runtime, which is a lot more laborious. Whereas the disadvantage you could call it is that it is more effort to actually define types of everything, the movables, right.
Dennis: Yeah. And in a sense, the language gives you a little bit earlier feedback about mistakes that you potentially made, but just mistakes that you did in regards to the type. So, you can still write program code that doesn't work for a million other reasons. But at least your language compiler can tell you, okay, you use the types correctly. So you told me, this is the type definition of a person, this person has an attribute name, last name, it has to have this method. And now, the compiler can check for me, if I use this persons object instance answers correctly in my code, or if I calleda method that doesn't exist on a person object instance.
Lucas: Correct. The more potential mistakes the compiler eliminates for you, the less you have to deal with, right? So, in the long term, it saves you time. It is particularly helpful when you are refactoring code, right. You have existing non typed code that you want to change, particularly if you're changing the signatures of functions or changing the types of anything. If the language you're using is not typed, you have to basically check every single usage of whatever you changed in the entire project, right, to make sure that it still fits everywhere.
Dennis: Yeah. It's an interesting idea. Another thing that I like about type languages is that it's also partially self-documenting. If I, for example, write a function that gets a parameter who is called person, in a dynamic type language like Python, I might not know is this the name of the person
or is this really an object instance of type person in a typed language like TypeScript? I can see this on the function header because it tells me the parameter person is of type person, or for example, of type string. So, that kind of takes away the responsibility to also document what it actually is this parameter, right? It makes it easier for me, I don't have to encode this into the parameter name or write it in a doc string.
Lucas: Absolutely. The less explicit documentation, you need to actually be able to understand code, the better, right? It makes it more obvious. For instance, when you see a function that takes some type of furniture and gives it another type of parameter what is happening inside there, what transformations are happening to the data you're giving it?
Dennis: Yeah, I think so too. I think it's always better to write more explicit code and less documentation. Because at the end, the interpreter or compiler doesn't make sure that your documentation is correct, right. You can not change the function header, but forget to change the documentation that tells you this parameter has this type. That's typically something that happens often in Python, where you have a certain syntax on how you can document the types of parameters of functions in the doc string. And then you change the parameter type, but you forget to change the doc string, and then people believe, ah okay, it gets called with this type, but it actually isn't. And it's pretty tricky in practice, and happens quite fast.
Lucas: And so with docstrings, you always have to keep in mind to always edit both in parallel, right, if you make a change to one, you have to update the other, you have to manually keep that in sync. Whereas with types, there is no way to not do that, right, it’s basically just one, you cannot change one but not change the other.
Lucas: In my opinion, that's one of the biggest advantages of TypeScript. It makes it very easy to express all sorts of types, right. And sure you could do the verbose Java way to define a class with all its fields and methods and implementations. Or we could just define an interface or the fields and just types. Or you could just say, define a type as a combination with operations of some other types, like say, type A and a subset of the fields of type B, for example.
Dennis: So, the strength is basically in TypeScript, the reusability of the types that you define, which you of course, have in some sort in Java too but TypeScript gives you just a huge toolset of reusing and composing and combining types that you already have. And that's really nice because you end up writing less interface code. And actually more code that actually gets the thing done. So, we already talked about a bunch of things in the typing system. Another thing that I find really nice and that I would like to talk about is optional types. Maybe you can explain a bit to the listeners what undefined types means and what optional types really are.
Lucas: Alright. Preface that by pointing out that in Java, every type is nullable, right? If you have a parameter of type foo, it actually check that is actually defined to not know, right, you cannot actually tell the compiler that this is always going to be defined. Whereas in TypeScript, by default, nothing is knowable, right? If it's defined that a parameter has type x, it's always x, it cannot be null. But you can also define the other type is x or undefined, which means that you can define x if you want to, you don't have to. Or you can say it's null, which most people take to mean that it is defined to have no value, right? It's a very subtle difference, but very useful in practice.
Dennis: So, you have this differentiation. So, in Java, the null value for some object or variable could mean that someone didn't specify a real value or that the real value is basically the empty value, the null value? And then TypeScript is separated. So, you have the type undefined which says, okay, here, someone really didn't specify a value for the parameter. And you have the value null, which really says, that's the empty value. And it's quite interesting and it's also interesting how TypeScript incorporates that into the language. So, you have this question mark operator, so you write a function and you have a parameter foo. And if you put behind the name foo, a question mark, you basically told the TypeScript compiler, that the value for foo can be a real value, or it can be undefined. And that has also implications on your code. So, you can select an option in TypeScript that is called strict null checking, which means when you deal with parameters or variables that can be undefined, you need to explicitly check whether the value is currently undefined when you want to do something with that. And it's really interesting, because it eliminates a big problem that we have in programming languages, where you get a null pointer exceptions because you access some value that was null but you didn't expect that that's typically happening in Java a lot, because how reduced they used the null value for everything. And TypeScript is very explicit, and can tell you, okay, here, this value can really be undefined, you need to make sure that it's not undefined null.
Lucas: Exactly. That once again, eliminates an entire class of potential problems, right? If you receive in your function a, any parameter of type X, you know, that it's always actually doing, you don’t have to actually check that it's defined. And the interesting thing is that allowing a type to be undefined is nothing more than just a type union of whatever type is specified and undefined, which in and of itself, is also a type in TypeScript.
Dennis: So, you could, instead of writing this question mark operator, which is a kind of syntactic sugar of the TypeScript language, you could explicitly write it is the real type of the parameter for example, string, or undefined.
Lucas: Yes, it is almost the same thing. In the newest versions of TypeScript, there is a small differentiation. The question mark, means that the parameter is optional, meaning it may or may not be in the object, whereas type or undefined means it can be in the object with the value undefined. Small difference, but it can be relevant sometimes.
Dennis: So Lucas, so we talked now a lot about the TypeScript language features. Last thing that I would like to briefly discuss, we already talked about about a bit, district nine checking is, that you actually can configure the TypeScript compiler to your use case.
Dennis: So, it won't say, hey, I declared a variable. And if I don't write any type behind it, it's implicitly any note when I set it to false, then I really have to give a type to everything. And I have to explicitly say it. And the first one was that when I have this question mark behind the parameter, and it can be undefined and I really am forced by the TypeScript compiler to really check if the value was undefined before I can do something with it. Yeah, and that's something that is really special, I think, because in languages like Java, you typically can't configure the compiler to your needs, which you can do with TypeScript. And I think this really adds a nice touch to it, nice touch of flexibility.
Lucas: Well, that is again because the types only exist in development time. So, we don't really have restrictions as to what-, in what ways we can transform the types before they get compiled, because they don't get compiled at all. So, you can-, you have basically no restrictions, or you can just do-, you can just have them do what you want them to do, however you find them most comfortable.
Lucas: Yeah, exactly.
Dennis: So, now we have a really good look at TypeScript. Now, I really want to ask you, would you use TypeScript for any project or for which projects would you use it?
Lucas: I personally would, except for the smallest of approaches, I would always use TypeScript. To me the advantage of having typing always outweighs additional effort of firstly, having to transpile this code and to have specify types. To me, that is just a massive plus.
Lucas: TypeScript is already very widespread these days. I do not remember the last time I wanted to use a library that do not already have some types for me. But even in this case, it's pretty trivial to define the types yourself, right? Can you just make a .dts file with all the types as they are using a library.
Dennis: Yeah, it was really interesting with you, Lucas, I think we really dove quite deep into TypeScript. And I think we could give people like some insight, why we really appreciate TypeScript, like to use it in our front end projects. And what the benefit of using it for us as an organization but also as developers actually is. Okay,Lucas, we are already at the end of our podcast, almost. Maybe you can just summarize for our listeners what we talked about today .
TypeScript. It becomes quite seamless to write TypeScript.
Dennis: Yes. So, thank you for being a guest on our podcast.
Lucas: Thank you for having me.
That's all for today. We hope you enjoyed this episode, and that you now have an idea on how to integrate TypeScript into your developing process. Further links are in our show notes. And if you're interested in the wonderful world of software development, we would be happy if you subscribe. We will be back with another interesting topic on June the second. Take care until then, and stay healthy.