Episode 20

Why you should learn TypeScript.

"Thats the biggest advantage of strongly typed languages, you eliminate a whole class of potential errors."


Note: This Podcast is avaliable in english. 

Hello, and welcome back to our podcast: "Developers explain the world". Since we also have international employees at consistec, we had an idea to record an episode in English. So, today our developers, Lucas and Dennis will explain why you should learn TypeScript. What is TypeScript? And what's so special about it? When do you use it? And what brings JavaScript and TypeScript together?

Enjoy the episode.






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.

Lucas: Yes, I would like to convince the listeners that TypeScript is definitely worth the effort of learning. If you already know JavaScript, it's super easy and brings massive benefits.

Dennis: Yeah and to explain some of the uniqueness of TypeScript as a language, a strongly typed language. And we will also explain later what that means. We want to discuss today and explain people why it is interesting to invest the time and not only learn JavaScript, but also TypeScript. So, maybe we start and explain what is TypeScript? And what is it compared to, for example, JavaScript?

Lucas: Right. I think anyone who has ever written JavaScript can relate to me when I say that it's very uncomfortable. In JavaScript, whenever you want to use any existing code, so you call an existing function, you have to go on the code and check what the parameters are, how many of them there are, what they're supposed to look like, or when you're refactoring an existing code base. Now to make sure that everything works by checking all these ages or whatever you changed. TypeScript solves that by introducing typing, strong typing. This is all because JavaScript is not a typed language. It doesn't have types at all. So what TypeScript does, it adds types to JavaScript. And TypeScript is simply a superset of JavaScript. Meaning it does everything JavaScript does, and allows you to define types. So, you can add constraints to your code, saying this function can only be called with these particular kinds of things, whereas in JavaScript, you cannot do it that way.

Dennis: So, you mean in retrospect, it can only be called with a power meter with the type integer, for example?

Lucas: Exactly. You can define that the function must be codes with an object that has these particular fields, right. So, you can always immediately see that if you see this function, you want to use it, what you need to give it, unlike in JavaScript where you don't have to actually look at the implementation.

Dennis: JavaScript, you could just fill in anything. And then at runtime, it either works or it doesn't work. So, I will just find out later, if what I wrote actually fits.

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.

Dennis: Maybe you can also explain a bit how that works. So, everyone heard JavaScript and TypeScript, we all have an idea that it's about front end development, it's kind of the face of the website. But where does TypeScript fit into this whole concept, what do we do with it?

Lucas: Right. Browsers only run JavaScript. That's an undeniable fact, we cannot change that. But if we want to use TypeScript and all these typings, that means we need to transpile TypeScript into JavaScript before we can actually run it in the browser.

Dennis: So, transpilation for our listeners means to translate from one programming language into another programming language of the same level. So, if you have a high level programming language like TypeScript and to transpile into JavaScript, you transpile into a language that has the same level. So, it's not a low level programming language like C, for example.

Lucas: Right. You're basically just translating code. And when you're transpiling TypeScript into JavaScript, all of these nice typing features are gone. So, the stuff only exists in development time.

Dennis: So, we basically end up with JavaScript code.

Lucas: Exactly, just pure JavaScript.

Dennis: So basically it extends just a JavaScript to some syntax where you can define types. And that's also something that we want to explain now, but as a typing system and a programming language, maybe you can explain in a simple phrase, what that actually means. What does it encompass to have a strongly typed language?

Lucas: Right. A strongly typed language is a language where everything you do has to be explicitly allowed by the types that you're using. So in a language like JavaScript, you have no type setup.

Dennis: So, JavaScript would be a dynamic type language, we say the type checking happens at runtime, and not at compile time, like with the type language, right?

Lucas: Yes, right. Like, in practice, like when you're developing JavaScript doesn't have any typing at all, you didn't write anything and you didn't need to compile all of their ages, find out if it works or not, at runtime. Whereas with a compiled language, a strongly typed language like Java, the compiler makes sure that everything you do is actually allowed with the types that you're using.

Dennis: So, in practice, this means when I open up my IDE or my VS code and I want to program a program dynamic type language like JavaScript or Pytho,  then I will just figure out if that what I wrote works, if that object has the method that I called at runtime when I execute the code. Whereas when I code TypeScript, for example or Java, which are statically typed languages, I will already figure it out at compile time. So, I will immediately get told by my IDE, hey, you try to execute the method greetings at object instance of a person and this person doesn't have this method. So, you cannot do that.

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.

Dennis: So, now we kind of already explained what are the advantages or the motivation between typing and how TypeScript comes together with JavaScript that is basically an extension. And another thing that I would like to talk about with you is that TypeScript is actually very special in the way how it implements typings. So, you could argue that TypeScript can be a dynamic typed language, and aesthetic type language at the same way, it's kind of like a hybrid. You can, for example, use the keyword "any" in TypeScript to tell the compiler, I have, for example, a variable or parameter here, whose type I only don't know, but I also want you to completely disregard it. So, this becomes basically like a parameter that is not typed at all. I can do whatever I want with it, like I could do in JavaScript, for example.

Lucas: Right. Well, the thing is types in TypeScript are basically just an illusion, because they only exist in development time, right? In the end, you cannot use TypeScript directly, because the browser will not run anything from the JavaScript. So, you have to transpile it into JavaScripts. And through by that the types will be eliminated, right. So, they're only helpful for the developer during the development.

Dennis: They’re actually just like a tool, that the TypeScript compiler uses to make the type checking. But afterwards, they're just gone. Because as you said, we translate into JavaScript. Another thing that I really like about TypeScript, so we both-, we worked with Java and Java is quite verbose. It's very strongly typed, and very opinionated and how you can do certain things. So, everything has to have some type. And in TypeScript, you're more flexible. So, you have the option to say, hey, I used "any" keyword and say, okay, the type of this object instance or of this parameter is not interesting. We don't want to enforce any typing on that. But you can do that with the types because they get defined in TypeScript separately, you can combine them. So, you can create something that we call intersection and union types. So you could, for example, say, this parameter that I have, this parameter foo, could be a person, it could be an accountant. So, it could be multiple things, which we call union types. And on the other hand, you could say this parameter foo is a person and accountant at the same time. And then that means it needs to have all the attributes of the person and all the attributes of the accountant. And that gives you a lot of flexibility in other languages like Java, you would have to create a new class to describe this new type. Whereas in types of geo very flexible, you can compose these interfaces.

Lucas: Right. As I said before, types in TypeScript do not exist in runtime, right, only in development time. And this, first of all, allows you to choose just how strongly typed your code is. You don't have to choose either non type like JavaScript or completely typed like Java, but you can choose what exactly you want to be typed, what should behave like JavaScript, how strict your type definitions are. And second of all, it also allows you to do all kinds of interesting things with types, all kinds of operations with types you cannot do with other languages, because they still would exist in runtime, right? So, you can have as you said, union types, where you have two types and so you make an object that contains all the fields of both types, you still-, you actually have a way of expressing that new time, like A and B, right? One of my favorite features, to be honest, is tuples, in JavaScript or TypeScript which is basically expressed as a simple array. But we first of all know the length of this array. It's an array, and we know the type of each element in the array, right? And in the last few versions, TypeScript, you can also assign a name. So, that was a very useful way of just dynamically making tuples without having to explicitly define types, in a verbose way like you would have to do in Java.

Dennis: Yeah, it kind of combines the best of two worlds. So, JavaScript is a language that gives you a lot of flexibility. For example, in Java, I can create any object, I just open block quotes, and I created an object and I can give any attributes. And now with TypeScript, I can define an interface. And not just attach a type through the interface on that object that I created and it gives me a tremendous amount of flexibility. And that also helps me to write less code as strange as it sounds because in languages like Java, the typing system is very verbose, you need to write a lot of what we call boilerplate code. Mandatory code that you have to write to achieve certain goals. And in languages like Python, for example, which is a dynamic type language, I can do a lot of things with less code and in Java. And now the cool thing is about TypeScript. TypeScript goes into this corner, it is still a strongly typed language, but eliminates a lot of the boiler plate code, because you still have the flexibility of JavaScript. And that's what I really like about it.

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.

Lucas: Right. You can have these two flags in the configuration, an implicit any and strict null checking with which you can physically configure whether you want this strict null checking thing or if you want it to behave like Java, right, without the guarantee that the types are always nonnullable. And the no implicit any that would forbid you from having any parameters, without any type annotations that are any by default. So, that will be the JavaScript behavior.

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.

Dennis: Yeah, because at the end, it will become JavaScript code somehow. And that's the job of the TypeScript compiler or gives you the power to implement such configuration and adjust it to your needs.

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.

Dennis: Yeah,me too. Especially you start a project today, you don't know how big it will become that time. And in the long run, it pays always off to have this type information, it makes working with code in the future easier. And you typically, you know, you just write the code once, but you will have to maintain and work with it ideally, forever, or let's say, like, a couple of years, right? So, in the long run, it's like an investment in your programming code to use a type language. I think one thing that we should mention is, is it for everyone, should everyone just know, start his front end project with TypeScript? And I think what people should understand is, you should learn JavaScript first, because TypeScript as he said, is a superset of JavaScript. So, it adds more syntax to JavaScript. And it makes sense to learn the fundamentals of JavaScript first and once you are comfortable with this, you can learn the typing system of TypeScript and then you basically extend your tool belt and then you can write TypeScript code and have the benefits of-, the flexibility of JavaScript, but also the typing of TypeScript.

Lucas: Right. First, back to your first point. TypeScript is specifically designed that it does not take much effort at all to use it in an existing JavaScript project. So, you can start a small project with JavaScript, no problem. And then you can just, if you decide to later on just insert TypeScript in there. You don't have to apply types, right? It's not a package, they have to acceptother ones.

Dennis: That's an interesting idea. So, you basically can start with JavaScript and you can evolve the project into TypeScript.

Lucas: Yeah, you can just introduce it whenever you like, as I said before, simply renaming a JavaScript file from Js to .ts makes it already valid TypeScript. It's very easy to get.

Dennis: It's quite interesting. What I think is also interesting to know is that in TypeScript, you can use any JavaScript library, right? So, you don't have to differentiate between this is a library that's written in TypeScript, this is a library that's written in JavaScript. And I can just use the one in TypeScript and you can use any JavaScript library, which is really powerful, because JavaScript is still the standard for front end development and there's a lot of open source projects for it.

Lucas: Yes, correct. You can continue using any JavaScript libraries exactly as you would in JavaScript, the same syntax. It just changes if you switch to using typed libraries, right? Libraries that have natural published typings file, then you can actually import the specific exported members from the library.

Dennis: So, when you have a JavaScript library that doesn't have a specific typed part of the library for TypeScript, then the consequence is that when you use TypeScript, and you import the JavaScript library, all the types in the JavaScript library are any. So, we just don't know the types and the TypeScript compiler cannot do some type check on it. But you still can use the libraries, the methods and everything that's in there.

Lucas: Correct. And that point is just simple JavaScript. TypeScript will just do nothing with that.

Dennis: Yeah. But many libraries nowadays already have this separate library with the types for the main project. So, you can have the real time information when you work with libraries. And it's also quite easy to generate separately, a library with the type information next to an existing JavaScript project. It is really very flexibly designed, how it comes together.

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 .

Lucas: Right. My conclusion would be if you already know JavaScript, it is definitely worth the effort to learn TypeScript. It offers you huge benefits, it makes development a lot more effortless in many ways, especially when you're refactoring your code, and especially in very large code bases, where you just cannot keep track of other types. If you don't have JavaScript yet, you have to manage TypeScript, is basically just an extension of JavaScript. And the extra effort involved in using TypeScript in your project, at least to me personally is always worth it.

Dennis: It comes with the experience once you are familiar with the concept of both JavaScript and

TypeScript. It becomes quite seamless to write TypeScript.

Lucas: Basically just JavaScript++.

Dennis: Yes. So, thank you for being a guest on our podcast.

Lucas: Thank you for having me.

Dennis: Goodbye.

Lucas: Goodbye.


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.


Your cookie settings

Technically necessary (essential) cookies

Information on the individual cookies

  • Show more

    Technically necessary (essential) cookies

    Necessary cookies help to make a website usable by enabling basic functions such as page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

    Name fe_typo_user
    Supplier consistec.de
    Purpose Secures anti-spam measures when using the contact form
    Expiration Session
    Type HTTP
    Name conCookieSettings
    Supplier consistec.de
    Purpose Saves the consent to cookies
    Expiration 30 days
    Type HTTP
    Name mtm_consent_removed
    Supplier consistec.de
    Purpose Used by Piwik Analytics Platform (matomo) to determine that the tracking has been contradicted
    Expiration 1 month
    Type HTTP
  • Show more


    Statistics cookies help website owners understand how visitors interact with websites by collecting and reporting information anonymously.

    Name matomo.php
    Supplier consistec.de
    Purpose Records statistics about the user's visits to the website, such as the number of visits, average time spent on the website and which pages were read.
    Expiration Session
    Type HTTP
    Name _pk_id#
    Supplier consistec.de
    Purpose Records statistics about user visits to the site, such as the number of visits, average time spent on the site and which pages were read.
    Expiration 1 year
    Type HTTP
    Name _pk_ses#
    Supplier consistec.de
    Purpose Is used by the Piwik Analytics Platform (matomo) to track page requests of the visitor during the session.
    Expiration 1 day
    Type HTTP
    Name _pk_testcookie..undefined
    Supplier consistec.de
    Purpose Is used by Piwik Analytics Platform (matomo) to check whether the browser used supports cookies.
    Expiration Session
    Type HTTP
    Name _pk_testcookie.#
    Supplier consistec.de
    Purpose Is used by Piwik Analytics Platform (matomo) to check whether the browser used supports cookies.
    Expiration Session
    Type HTTP