Why Is TypeScript So Popular? With Christian Santos

Episode Summary

Today we're talking about TypeScript with Christian Santos who is a software engineer at Facebook and co-author of the upcoming book Fullstack TypeScript. In this episode we ask, "Why is TypeScript so popular?" TypeScript is, at it's core, a productivity tool that has gained exponential adoption over the last few years, but it isn't always easy to get started. Today we'll discuss how TypeScript relates to JavaScript, What's the difference between TypeScript and Flow, and the common mistakes that beginner TypeScript developers make. So If you're wondering... - What tools should I use to get started with TypeScript - Should my team be using TypeScript in our projects? - and Is TypeScript a fad? Then keep listening. Let's get started

Episode Notes

What We Talk About

Episode Transcription

Christian Santos - TypeScript - newline Podcast

[00:00:00] Nate: [00:00:00] Christian, thanks so much, it's good to have you here. Can you tell us a little bit about your work at Facebook and what you do there? 

Christian: [00:00:06] Yeah, absolutely. So I started at Facebook almost six months ago now, but due to their onboarding process, I really didn't join a team until four months ago .And the team I ended up joining is called the performance visualization team and it's pretty cool.

It's pretty exciting. We basically build visualizations for other teams in the company. And so we help them look at their traces or make sure their apps are running in a performant way. To give you an example, it's similar to the CPU profiler that you would see in Chrome, like those Dev tools. We have a tool that is very similar to that.

Amelia: [00:00:45] Are you making one-off visualizations ever or are they usually tools or kind-of dashboards or web applications of their own?

Christian: [00:00:52] It's like a bunch of dashboards. The setup is we have a ton of different visualizations and then, depending on the customer [00:01:00] and the company, we sort of fit those visualizations to whatever they need.

So we have like tree visualizations. We have graph visualizations, for example, if you want it to look at like the relationship between different calls, like a call graph of your app to see like, okay, this function is calling this function, but over time, this function got slower. So a good way to analyze that would be like in a graph that's color-coded.

Amelia: [00:01:28] Yeah. Sounds really cool. 

Nate: [00:01:29] Is it mostly, you're profiling front end web apps like, like you are in Chrome or are you also doing backend apps. And is it just within one process, like here's the functions being called within this backend process, or are you also tracing like calls between different microservices?

Christian: [00:01:47] Yeah, the cool part is that it's anything, and so we actually have a different team that works on actually getting those traces together. So we sort of work off of that interface. And as long as you are feeding us [00:02:00] that data that conforms to the interface, we're able to show visualizations for it.

So that could be like frontend apps backend apps. It could be, like you said, how microservices are communicating with each other. So it doesn't necessarily just have to be conventional traces of of code that's running. It could even be things like error stacks or custom events that you want to attract throughout your, your service life cycle.

Amelia: [00:02:25] What does a typical project spec look like? Do you have a specific question that you want to answer or is there a category of things or is it even, "Hey, we have this data, could you visualize it for us?"

Christian: [00:02:36] Usually, the customer knows what they're looking for. So they usually come to us telling us they want to be able to trace their app to investigate performance issues or to investigate regressions, throughout different versions of their app.

But you know, it's also like a process. Like we, you know, we always sit down with them and discover, use cases, [00:03:00] make suggestions, things like that.

Amelia: [00:03:02] It sounds like they treat you like an agency.

Christian: [00:03:04] Yeah, a little bit. Yeah. 

Nate: [00:03:07] You know, something that we didn't talk about before, but maybe we could as could we talk about like the process of getting a job at Facebook?

Christian: [00:03:14] Yeah

So what did that process look like? Like how many different companies 

Nate: [00:03:18] did you apply to and how did you prepare for those interviews? 

Christian: [00:03:22] Yeah. So prior to Facebook I was at this company Jet, which is like an eCommerce company owned by Walmart labs. And around the time that I decided to leave, we were sort of being, phased out is probably not the right word, but a lot of teams were becoming Walmart Labs teams, and this is all like public information.

And around that time, like a lot of people started leaving or looking around, including myself. So I did look at various other companies, mainly like the big tech companies. So companies like any, I mean, in New York, you pretty much have all of them. Like, uh, you know, Google, Facebook, [00:04:00] Dropbox, Squarespace.

So it was looking at a few, I was preparing by looking at the classic programming sites online. So things like leet code, cracking the coding interview for, for practice, but because I was applying as a front end engineer, it's sort of, it's like you have to study all that stuff, but also you have to have a lot of domain knowledge for everything front end.

So things like web APIs and like obviously like CSS, HTML, that kind of thing. Usually not so much like framework-specific stuff. Unless like the company for whatever reason really wants that stuff. But in my experience with interviewing for, for like these big tech companies, it's, it's mainly focused on like pure JavaScript.

Amelia: [00:04:47] Which of those do you think was more important? Like the general concepts or domain knowledge?

Christian: [00:04:52] I think they were about equally important because you can't really know one and not the other and still like pass the front end [00:05:00] interview. Cause at that point you would probably like try to go through the generalist pipeline if you didn't have that domain knowledge.

So yeah, I would say like equally important.

Amelia: [00:05:10] Right. So just work on whichever one you're less strong at.

Christian: [00:05:14] Yeah, definitely. And if you don't have that domain knowledge, then I would say focus on the core CS fundamentals.

Nate: [00:05:23] So let's talk about TypeScript. So you have been using TypeScript for a couple of years and you really like it. Of course, now you're at Facebook where they use Flow, but we can get into that in a little bit. But can you talk to us a little bit about like why TypeScript is so popular? 

Christian: [00:05:37] Yeah, absolutely. So I think there's a few reasons why it's so popular. A few of them are like historical- and like marketing-related.

What I mean by that is that if you look at the history of TypeScript and you go all the way back to when it was open sourced in 2012 and then when they eventually moved to get her to 2014, it was picking up popularity, but it's still, it wasn't that popular. [00:06:00] But around the time when Angular decided it was, they were building that partnership with TypeScript, which I think was something like 2016, around that time, it really began like picking up steam. And by I think the end of 2017 it really like, like if you look at popularity graphs, you can see it really like started going up at that point. So I think part of it was just like people saying, Oh wow, like you know, it's Microsoft and Google and all these big tech companies are starting to use it. I think that was one reason. The other reason was the low barrier of entry to start using it.

So because TypeScript is a superset of JavaScript that you can adopt incrementally, it's very easy to just add it to a project and not really change anything and still see some of the benefits. And then sort of slowly over time, start adding type annotations and start using more of the, the hardcore features.

Nate: [00:06:54] When you say it's a superset of JavaScript, can you talk more about what that means to be a superset? 

Christian: [00:06:59] Yeah. The way I [00:07:00] think about it is like I visualize it being like Typescript. There's like a big circle and then JavaScript is like a little circle inside of that big circle, meaning that you have all the features of JavaScript available to you, plus more.

So that's where like the, the super, like the superset part comes in and so that extra stuff is mainly the static types that you can annotate. A few years ago, it also used to be additional features on top of JavaScript, but they've sort of moved away from any proprietary ish stuff, to just conforming to like whatever the latest ECMAScript standard is.

Amelia: [00:07:38] Do you know why they are kind of moving away from that?

Christian: [00:07:41] Yeah, so it was because it just didn't seem maintainable or like a good idea for them to be working on features that would eventually be deprecated in the spec. I think a good example of that is the private class fields where, from the beginning, like [00:08:00] when Typescript came out, they had the private keyword or a modifier that you would use in, in classes, and for a very long time, JavaScript didn't have that.

It wasn't part of the ES6 proposal and only like fairly recently that they actually publish a proposal for private class properties, and it's like a little like hash bang symbol. So there's the problem, right? You have TypeScript with this private keyword and now you have ECMAScript spec with like the hash bang in it.

And it's like, how do you marry the two? And I think eventually TypeScript will use the new syntax, but they're in this sort of weird in-between phase where they can't.

I think another good example is decorators, which are. Like they never really, they're still an under an experimental flag in TypeScript even though they're used in a lot of places in Angular.

And that's because like from the ECMAScript side, it's still hasn't been like fully adopted and it's still going [00:09:00] through that process and the way things are looking it might not be meant as a thing that people actually use. Like it might just be used for metadata for tools consuming the code. So, yeah.

So I think it just creates headaches down the line. So I think ultimately it's a good thing that they decided to just conform as much as possible to the, the standard going forward.

Amelia: [00:09:20] So when we talk about "they"... who is maintaining Typescript?

Christian: [00:09:24] So when I say they, I mainly mean the TypeScript team. So it's built by Microsoft. It's a group of like, like I think like 20 people. It might've grown a little bit since then, but I think it's something like 20-22 people. 

Nate: [00:09:37] And maybe we could take a step back a little bit to define some of the context. So when you say ECMAScript, tell me more about what you're talking about 

Christian: [00:09:45] Yeah, so ECMAScript is the standard that JavaScript is based off of. And so ever since ES6 came out. So like ever since ES2015 which is ES6, but like the proper name now is [00:10:00] ES2015, it's a spec that's published every year with new syntax or new features for the language that JavaScript is based off of and it's a multistep process. So every year when this is published, you have proposals that come in from stage zero all the way to stage four, which is when they're fully adopted and added into the standard.

So that's what I mean when I say ECMAScript, I'm referring to that standard that's probably every year ever since or ES2015.

Nate: [00:10:31] Right, and so then one of the benefits of TypeScript is they've basically hitched their wagon to ECMAScript. Anything that's valid ECMAScript. Is also valid typescript.

Christian: [00:10:45] That's true with like a little caveat, which is that, yeah, from a high level, like any ECMAScript feature that's out there is also going to be valid TypeScript. But then you like, especially for the newer stuff, you just have to be a little careful. So like we already mentioned the private [00:11:00] modifier, like if you were just coming straight off of using the latest, latest and greatest proposals with Babel, and then you started using TypeScript, you might hit, a few snags with that. Especially any proposal that's not like in the stage three or stage four area probably is not supported yet.

So there is like a little lag time between like when something's proposed or published that you might start people in the community using because they're able to with Babel, but you can't really use it with TypeScript just yet.

Nate: [00:11:34] Okay. So we've got JavaScript. Which is formally defined by ECMAScript, and then we've got this other language TypeScript, which adds features to it. What's a main feature of TypeScript? Why would you even bother using it at all? 

Christian: [00:11:48] Yeah, so I look at TypeScript mainly as a productivity tool, like that's, I think, its main benefit. I think that's its main selling point of why [00:12:00] you would want to use it. And the way it makes you more productive is through it's type checking. So it's sort of static type analysis is the biggest thing you get from it, which can either be you explicitly annotating your code. So you might say like const name : string, and that becomes like: the variable name is now type string. That's like the main feature that headline features, like the type annotations and the type checking. And the other feature is the conformance to the latest ECMAScript standards. 

Nate: [00:12:36] And just to make sure we don't leave anybody behind. Can you talk a little bit more about like what type checking is and why it's good for anybody who's maybe not familiar?

Christian: [00:12:45] Yeah, absolutely. So JavaScript is a language that is loosely typed, or dynamically typed, which means that it's not compiled ahead of time with a step that's going to check your types and make [00:13:00] sure that you have functions that expect strings and that you can only pass strings to that function. You can pass anything to anything, as you know, and you won't get any errors until you actually run the code.

So that's what we mean when we say dynamic, is that there's no ahead-of-time, before you run it, type checking in JavaScript at all. That's one problem. One problem is that you won't know the errors before they actually happen, when you were on your code. The second thing is that when you have a language that doesn't enforce types ahead of time, it's really hard to ramp up in that code base, especially when it's a code base of like, you know, like 300,000 lines of code or like 1 million lines of code because you see all these different variables, you see all these different functions, they're probably not all documented. So you just have no idea and you might have to like actually look into the function bodies to see what's going on. But with types, the cool thing is that it's solves both of those problems. The first one, it solves the problems of [00:14:00] catching your errors or a certain class of errors early on through the compilation process, before you ever run your code. And it alleviates the second problem because: now you don't have to go digging around function bodies because they have their signature and you know exactly what their input and output is supposed to be.

And then you get some like additional functionality. Like you can also make factors which are safe and guaranteed to work. And you just can't make those assumptions with vanilla JavaScript.

Amelia: [00:14:30] Right. It can be really easy to miss something that you find out a few months later is a huge bug.

Christian: [00:14:36] Yeah. When someone pages here, like during the morning or something, cause the site's down.

Nate: [00:14:41] So what are some of the drawbacks? Why wouldn't you just always add these types of your code? Why wouldn't you use TypeScript? 

Christian: [00:14:47] So some drawbacks might be if you happen to be working on a project that like. Doesn't have a compilation step or something, you are going to have to add that compilation step.

Although nowadays [00:15:00] that's pretty rare because everyone, you know, everyone's using like Babel, or some other kind of compilation step. But that's something to keep in mind is that it will add some amount of time to your build process, to your compilation flow. Another drawback might be that there is some learning curve. Even though it's built on top of JavaScript out of the box, you'll know most of its features, but not all of them, especially as you get more into the advanced features.

It's true that you can just convert like a .js file into .ts File and it'll just work and that's fine, but when you actually start like fully adopting types and fully like trying to type every little function and you start using things like, like generics or like you're working with like higher order functions, so like functions that return other functions, things like that, then it starts getting like a little more complicated and that's where the learning curve starts to kick in. 

Amelia: [00:15:58] So would it be a better [00:16:00] fit for larger projects where there are more developers working on the same projects?

Christian: [00:16:06] I think, yeah, I mean I think that's the ideal fit. Like you, I mean, I would use it for everything just cause I think it's so helpful for me personally, but I could definitely see the argument for like if you're writing like a 50 line code project, you might not need it.

But yeah, it's definitely like super, super beneficial for. For teams and for any like significantly sized code base.

Amelia: [00:16:31] What about, is it a good fit for sane, open source library or some kind of widely use API?

Christian: [00:16:38] Oh yeah, absolutely. And I think one of the biggest benefits you get from using it in open source library is the documentation aspect of it.

So types in addition to serving as error catching and productivity tools, they also help as a means of documenting your code. Yeah. I can think of like several examples where [00:17:00] you are using an API and either the documentation just is not good and like you don't really get anything out of it or you happen to find a function that is public , but isn't documented yet. Like maybe there's like a little todo comment in the documentation. So I think ,in that regard, TypeScript is like super, super beneficial and it's very flexible too. If you're working on a, on a open source library, you don't have to build your library using types.

What some projects do like, I think Webpack took the approach of. They have declaration files side by side with their code. So even though they're not writing their code with TypeScript, they still expose those types. 

Nate: [00:17:45] What's a declaration file? 

Christian: [00:17:47] So you know, you see when, when you, when you see .d.ts and it doesn't contain any runtime code, it just contains information about the types. So things like function signatures. [00:18:00] So... Here's the function name, here are its inputs, here are its output, but you don't actually define the body. 

Nate: [00:18:07] And so the benefit there is that, let's say you had an open source JavaScript library, you wrote it in JavaScript, you're not going to necessarily rewrite that whole library in TypeScript.

Christian: [00:18:16] Exactly. Yeah. And that's, that's also like the premise of why you might've heard of this huge repo on Github called definitely typed, which I think is like the, it's in the top 10 of like most popular Github repos out there. And it's this enormous collection of all these types for almost any library that you could think of.

I saw an interesting sort of like graph recently about how over time it looks like more and more projects are starting to actually build their libraries with TypeScript just built in. Even though the majority, the vast majority is something like 99% of still live in definitely typed.

It looks like it's going up [00:19:00] because more projects are choosing to, to just have types in, in their, in their code.

Amelia: [00:19:05] So there an any type, which is basically: this doesn't have a type, it can be anything. Do you consider that an anti-pattern kind of like !Important in CSS?

Christian: [00:19:15] I think it's one of those things that you have to be careful of.

Like I think if you're overusing it, it can be a pretty bad thing. Like it's always a bummer when you get excited about a project being in TypeScript, but then you go into it and you see that like 90% of it is like any typed or something. So I think, yeah, it's definitely something to be wary of, but it's also super useful as you're ramping up and as you're building your code base.

So it's one of those like necessary evil things. And I think something that can really help with it are. Some of the compiler flags that you can use in when you're setting up your TypeScript config. And specifically I'm thinking of there's something called strict mode in TypeScript, which turns on all these like [00:20:00] really useful flags, one of them being "no implicit any", which means you can't have, yeah, unless you explicitly say like this function returns "any", you can't have a function that is just inferred to return "any", and I think that that helps a lot.

Nate: [00:20:16] What is your process for adding TypeScript into like an existing project? 

Christian: [00:20:24] So, into an existing project, we did that back when I was at Jet and we were incrementally adopting it.

So first off, we add the TypeScript build step into whatever the compilation flow is in our app. We don't change all the files from .js to .ts right away because you don't have to. So you can just change them to .ts as you're going and asks you or building up the project.

So I think a good way to do it is if you touch a file and it's a .js File, convert it into .ts and try to fix as many errors [00:21:00] as you can an d , if your team is good about following that guideline, eventually you should be in in good shape. And I think it's more realistic than just saying like, okay, we have all these files. Let's take like two months to like only work on types. Cause that's not, you know, that's not realistic. So I think incrementally is the way to do it.

Amelia: [00:21:17] Have you heard of anyone going the other way? So switching from a tape script project to a JavaScript project?

Christian: [00:21:23] I have. And I think usually when I've seen that happen, it's usually because you don't have the full buy-in from the team. So you have like 50% of the developers that like it and the other 50% hate it, and they're like JavaScript purists that just want to be able to write JavaScript because then when you have a team like that, you, you usually end up with a code base like I mentioned before, where you go in and like 80% of it is typed any. So then you have to wonder like, you know, like is it worth it at that point where you're not typing anything, but you're still, you still have the compilation step [00:22:00] and you still have these confusing types.

Right, I feel like it's almost a self fulfilling cycle of people who don't like Typescript and then they make them bad Typescript project.

Exactly. Yeah. So I think team buy-in is pretty important for a successful Typescript project. 

Nate: [00:22:16] Earlier you mentioned the term generics. Can you talk a little bit about what generics are? 

Christian: [00:22:20] Yeah, so generics are really useful and really important because they let you express types that are not tied to a specific set of types. a classic example is: imagine writing any function that has to do with an array. So for example, say you were writing a function last, which just returns the last element of an array. You don't necessarily want to write a function that only works on string arrays or number arrays.

You would just want to write a generic function that will return the appropriate type for any array. So you might have an array of [00:23:00] strings, you might have an array of numbers. You might have something super complicated where it's like an array of strings or numbers or like some fancy class. And so that's why generics are really useful cause they let you write code that's not tied down to any one specific type or any specific set of types.

Nate: [00:23:17] So what are some of the mistakes that you see beginner TypeScript developers make? 

Christian: [00:23:22] So I know one mistake that I made early on was, at one point the perception of TypeScript was that it's an object oriented language. And I guess that used to be much more the case because back when it was released, it introduced classes into JavaScript, even before ES6 and before those proposals were published. So it got a rap of being almost like a replica of C# or Java or something like that. So I think that's one mistake is that you might want to like use classes everywhere. But it's good to know that TypeScript is good for any type of programming paradigm, be at like [00:24:00] functional or Object Oriented. That's one thing.

Another thing might be using the right compiler flags, so I think you're definitely gonna want to be using the strict flag that I mentioned earlier. Another thing might be, like we mentioned over-reliance on the any type. You want to make sure you're actually, as much as you can, typing your functions and your variables.

You also want to make sure that you're not using types as a replacement for unit tests. So you don't want to think "Okay, just because I have types, now I don't have to write unit tests anymore", or something like that. They're two completely different things. So I think that's something good to keep in mind.

Maybe another big one too is you should be comfortable relying on inference, which is basically when TypeScript can infer types for you, instead of you having to annotate everything. So when you first start using Typescript, you might be tempted to annotate everything, and to say,"Okay, [00:25:00] const name is string, even though you're setting it like in that same line to like "Bob" or something. For those cases, you don't really like have to annotate and especially when you have the no implicit, any flag on, you can almost assume inference until the compiler tells you, wait a minute, this was in front of any, can you add some annotations to it?

Nate: [00:25:23] And what tools do you use to make sure that the compiler is giving you those errors? Like as fast as possible.

Christian: [00:25:29] So I'm using VS Code, which I think has become like in the front end world, like it's something crazy, like 90% of the people are using it or something like, yeah. So I think that's, that's like the big one. It itself was also written in TypeScript, interestingly enough.

Amelia: [00:25:44] Are you getting these errors while you type or on save, or can you set that somewhere?

Christian: [00:25:49] It can be both. So the cool thing about an editor like vs code or pretty much like any other big editors are like WebStorm or something. They'll tell you the [00:26:00] errors right then and there. So like in real time. And that's because TypeScript has this compiler API where they run their own language server in the background and they can analyze your code as you type in a really performant way, so you normally get feedback and like hundreds of milliseconds if you make a mistake.

Amelia: [00:26:20] Do you think TypeScript will be a fad or do you see it updating as front end does?

Christian: [00:26:26] I don't think it's a fad. I, I definitely think it's here. It's gonna be around for a long time. All the benefits that it brings to projects, I don't see it going away anytime soon, especially because we won't be getting like types or type annotations as part of ECMAscript, probably ever. At least if we ever do it like not for a really long time. So you'll always have that need for adding static types to JavaScript and I think TypeScript has proven itself to be the best one out there.

Yeah. I think that the only [00:27:00] other thing that just looking way down the line, like years down the line that might win out might be just a new language entirely. That's not based off of either Typescript or or JavaScript. So something like if you look at the approach that something like Dart or like ReasonML, the approach that they took, which was instead of building something on top of JavaScript, they sort of build their own language from scratch. Which is really cool. It's pretty useful. But, obviously has like it's own challenges like learning curves and, and stuff like that.

Amelia: [00:27:39] Right, and they'll always have to compile to JavaScript.

Christian: [00:27:42] Yeah, exactly. Yeah. Although we'll see, maybe like, you know, with Web Assembly, eventually they may open the door for like other cool, interesting things. But I think as long as JavaScript is the standard on the web, which it will be for a very long time, I think TypeScript will be up there. 

Nate: [00:27:57] Typescript's main competitor for a long time was [00:28:00] Flow, which is used primarily by Facebook. I feel like a few years ago you'd hear this from people that maybe Flo was theoretically more sound than TypeScript, but TypeScript was a bit more pragmatic.

Is that true? Or what are your thoughts on that? Like what are your thoughts on TypeScript versus Flow?

Christian: [00:28:20] I think, yeah, I think that's a great way to put it. So one of Flow's or really, like their big differentiator from TypeScript was that they were, or that they are sound in terms of types. So TypeScript is unsound for a few cases, meaning it won't give you an error when it probably should give you an error. But you probably won't hit it day to day, it's for some specific use cases. So when I think about Flow versus Typescript, I think more about the pragmatic aspect of it where.

You know, you look at the two and when you're coding with both of them, they feel very, very [00:29:00] similar. So in terms of the practical difference between the two, TypeScript is much older, so it's much more mature and has a lot more community support just because so many, like so many more people are using TypeScript out there than Flow.

So I found that that Googling things for flow is like such a huge headache cause like, no one's like, not that many people are using it. Although I mean it, it definitely helps them at Facebook. And I sit close to the people that are working on Flow. But yeah, I think Typescript just makes so much sense outside of Facebook just because of the, I think honestly, just like the community support alone and the amount of content that's out there for it.

Amelia: [00:29:43] Is there any pressure at Facebook to use Flow?

Christian: [00:29:46] Well, we all use Flow cause the cause that's what the the code bases are overridden. But that's the thing too, is that they're so similar when you're [00:30:00] working with them day-to-day, like you normally are not coding and like TypeScript or Flow and thinking of like, "Oh, thank goodness, it's sound" like, you know, like it's not something you really think about. They really behave almost identically when you're working with them.

Nate: [00:30:16] So if you were going to start a new TypeScript project, what tools do you use? Are there good, like boiler plates or template projects? 

Christian: [00:30:23] And so, it actually depends. Like if when you're building an app, you normally are not just building, just a Typescript app, like you're probably building like a, like Vue or React or Angular or something. With Angular, it's pretty straight forward because that's, yeah, that's the default.

With React, it's pretty easy now because create react app now supports it out of the box. And with Vue, I'm actually not super familiar, but I would imagine it's pretty good considering: this year, I think, they rewrote Vue 3.0 with TypeScript, so I would imagine the support's pretty good.

Amelia: [00:30:57] When is the right time for a [00:31:00] developer to learn TypeScript? Like, for someone who's just starting to learn JavaScript, should they learn TypeScript now or wait until they're more comfortable? What are things that people should already know before they tackle it?

Christian: [00:31:13] I think it would help to either know JavaScript beforehand or to be learning it side-by-side just because, since type TypeScript is a superset of JavaScript , if you're going to be using TypeScript, you're going to be using JavaScript as well.

So I would say either at the same time or beforehand, but it probably we like, I don't think he can say, "Oh, like I'm going to learn TypeScript and then JavaScript" because they're so intertwined that when you learn one, you're sort of learning the other two.

Amelia: [00:31:44] Right. When you're writing JavaScript, you are also writing vaild Typescript.

Christian: [00:31:48] Exactly. So it's like just by learning JavaScript, you're, yeah. You're learning TypeScript too, in a way.

Amelia: [00:31:55] How did you personally learn TypeScript? Did you read a book [00:32:00] or jump into a project first?

Christian: [00:32:02] So when I was learning Typescript, I can't remember if there was a good book out there for TypeScript.

So this was, let's see, I was using it back in when I was working for Vitamin Shoppe. That was my first time using it, and that was like four, four or five years ago. And back then it was mostly online tutorials, documentations. It was right around the time before, even Angular 2 was announced, so like we were still working with Angular 1. But yeah, for me it was mainly like online tutorials and the documentation.

Amelia: [00:32:36] Was there something that you kept getting tripped up on or what was the hardest part about it?

Christian: [00:32:41] I think the hardest part was the really advanced like topics, because I think it's really, it's one of those things where it's really easy to jump in and just get started. But for the really advanced topics, it's actually kind of hard to find just really good content online that will [00:33:00] explain things like the utility types in TypeScript, which are like built in utilities that help you construct new types from other types.

So for example, like if you have an object type and you need to pick a type from within that object, that's a utility that lets you pick it...

Nate: [00:33:21] Like you're saying like a subset of keys from an object. 

Christian: [00:33:24] Yeah, exactly. Like if you have an object with three keys and you want the type at key A, that's a utility. Although with Typescript, you can also do it with just syntax. So maybe another, like more useful one might be like exclude, which is another one which given like a set of types exclude some type from that set.

Nate: [00:33:46] Would "partial" be another one of those?

Christian: [00:33:47] Yeah, and "partial". Yeah, that's right. And all these utilities were actually not documented for a really long time. I actually ended up writing that documentation a year ago. So really before a year ago , they just weren't documented anywhere.

[00:34:00] So I think that's the hard part is like all these little things and the more complicated things as you really start getting into it. I think that's where it'd be really useful to have , a book to learn from.

Nate: [00:34:11] Yeah. I feel like the hardest part for me in learning TypeScript was not so much like the basic types, but like using it with React in particular.

Christian: [00:34:21] Okay. Yup.  

Nate: [00:34:22] Was a big learning curve. I basically had to, I don't know, read through a bunch of other projects that were using TypeScript for their React apps to kind of get a feel for how it works. And then a next level of difficulty was trying to use TypeScript with GraphQL. 

And so, there's a lot of really interesting benefits there because you know, GraphQL is already typed and you can generate TypeScript types from your GraphQL types, but getting all those working together and then understanding really deeply how to use them properly was a learning curve for sure. 

Christian: [00:34:54] Yeah. I think you bring up a good point too, about, it's not just learning TypeScript [00:35:00] itself, but it's also learning how these other libraries are writing their types. So I know like with React I always, if I'm working on like a TypeScript, React, Redux project, I always forget how to type the Redux connections. And I always have to Google it. And I always get different answers cause it's also changing over time. And so I've found lately, one of the most useful things you can do is to go to the type definitions directly, which can be a little daunting when they're like kind of complicated, but it's the best way cause it's like the source of truth. And then you know, you're looking at the right types. Cause when you look at our blog post, it might be outdated or something.

Nate: [00:35:44] Right.

Christian: [00:35:45] Yeah. Or your code might be outdated. 

Nate: [00:35:46] Oftentimes I'll like look directly into my node modules at like what that type is exactly there. Like the exact version that I'm using. 

Amelia: [00:35:54] So you can import external libraries aren't written in Typescript.

Christian: [00:35:59] Right.

Amelia: [00:35:59] Would you [00:36:00] usually create your own types in that case?

Christian: [00:36:02] So I would say , assuming it's a popular library, someone probably already made types for it in the definitely typed repo. But, if you happen to find like a really obscure library that doesn't have types, then...

Amelia: [00:36:17] I've done it

Christian: [00:36:17] Yeah, I'm sure. Like ,there's so many things out there. Then you, you would have to write your own types. And so you can do that either with declaration files that we talked about earlier, or it might be even more exciting to create a definitely typed typing, so then you can help out other people .

Nate: [00:36:35] So you mentioned earlier that a good way to learn this stuff would be to have a book about it, and you in fact are writing a book on it! So can you tell us a little bit about that? 

Christian: [00:36:43] Yeah. I'm really excited about it. It's kind of an interesting thing to do because it's a book about TypeScript, so it's not about JavaScript.

So we don't really , teach all of the types of JavaScript fundamentals, even though we have like the Appendix and stuff, and we do talk a lot about [00:37:00] JavaScript. We don't start from from the ground up. So it's an interesting problem and I think sort of the approach that we've taken has been a project based approach where we build projects with TypeScript and we show how TypeScript can enhance how you're writing your existing code.

So for example, one of the chapters is like Object Oriented TypeScript. So if you're working with code that's Object Oriented, this chapter will help you see how TypeScript can enhance that Object Oriented code. There's also a chapter on functional TypeScript, so if you're working a lot with functional code or even with React where you have a lot of like higher order functions or components all over the place, that chapter will sort of tell you more about how ,if you add Typescript into a project like that, how it'll enhance your code and your experience. 

Nate: [00:37:56] What's some advice you can give to some folks who are just getting started with TypeScript [00:38:00] today? 

Christian: [00:38:00] I would say write something and make a project. It can be something simple, simple like a, a calculator or something. Or it can even be like a Node project, which we actually do a lot throughout the book where we don't actually build out any UIs. We just write Node code and run it using ts-node .

Nate: [00:38:20] ts-node is a utility you can use to run TypeScript code on node.js.

Christian: [00:38:25] Exactly. Yeah. Without having to compile it and cause the conventional conventional way would be , okay, write your TypeScript code, compile it to JS, run the JS code. But it's sort of like a faster way of just doing it directly from your Typescript files.

Nate: [00:38:40] And what about somebody who's trying to convince their boss that they should adopt TypeScript? What would you tell them? 

Christian: [00:38:46] Well, there's a few things actually. One that I found really helpful is to, if you have PagerDuty or on-call or something like that, and you have a list of a bugs. Go back to those bugs, or, as bugs start coming in, try to keep track [00:39:00] of them because chances are some of those bugs, definitely not all of them, but some of those bugs will be related to type errors. So I think that's something super useful. Like when you're trying to argue for bringing in TypeScript, if you have a list of like, in the past few months, like here's like, you know, 50 defects that we wouldn't have or that could have been caught at compile time.

I think that's one. And then two is just the arguments of like, productivity. It's going to make you more productive. It's going to help with the errors, it's gonna help with documentation. So very few teams out there have like perfect documentation. So one argument would be: with Typescript, you sort of get it for free. Not a complete replacement, but you sort of the first step in getting to a place where code is more documented.

Nate: [00:39:49] All right. Christian, thank you so much for sharing this with us today. Where can we find out more about you? 

Christian: [00:39:54] I am on Twitter. I will be more active this year. That's one of my new year's [00:40:00] resolutions and my Twitter handle is csantosdev. 

Nate: [00:40:05] All right. Thanks so much for being with us!

Christian: [00:40:06] Thank you so much!