Why (almost) every JavaScript developer should learn TypeScript

00:00:00: I believe that for most JavaScript

00:00:03: developers, it makes sense to learn

00:00:06: TypeScript and they probably should

00:00:09: learn TypeScript, though, of course, I'll

00:00:12: say it right away in case it isn't obvious,

00:00:15: this is just my opinion.

00:00:16: If you don't like TypeScript, you don't

00:00:18: need to use or learn it, but I think there

00:00:21: are good reasons for using or learning

00:00:23: TypeScript and this is what I'll try to

00:00:26: explain over the next minutes.

00:00:29: And if I take a look at the numbers, the

00:00:32: number of people working with

00:00:35: TypeScript in the last Stack Overflow

00:00:38: survey, for example, and the growth of

00:00:41: that number, for example, then I would

00:00:45: guess many people would agree.

00:00:47: It's probably fair to assess that

00:00:50: TypeScript is pretty popular and is

00:00:54: growing in popularity because otherwise

00:00:57: people would probably not be choosing

00:01:00: it for their projects or at least it seems to

00:01:04: offer substantial advantages.

00:01:06: Now at the same time, I'm well aware

00:01:09: that last year in 2023, we had a period in

00:01:15: that year where some big projects were

00:01:19: dropping TypeScript and we had a blog

00:01:22: post by DHH, the creator of Ruby on

00:01:26: Rails, who shared a pretty strong opinion

00:01:31: against using TypeScript and why using

00:01:34: TypeScript is bad.

00:01:36: Now just to make sure that we're all on

00:01:38: the same page, the idea behind

00:01:41: TypeScript, the main idea, the main

00:01:43: thing it brings to the table is, of course,

00:01:46: that it adds static typing to JavaScript,

00:01:50: which in the end means that when you

00:01:53: are writing JavaScript code, you can't

00:01:56: suddenly change the type of a value

00:02:00: that's stored in a variable and you can

00:02:02: also, for example, predefine the type that

00:02:05: should eventually be stored in a variable.

00:02:08: You can be clear about the type of value

00:02:11: that's expected to be returned by some

00:02:14: method or function and in general, the

00:02:18: main idea simply is that you can be

00:02:21: specific about which type of value goes

00:02:25: where in your code and that you can't

00:02:28: accidentally use the wrong type of value,

00:02:32: for example.

00:02:34: And it's not just about the wrong type,

00:02:37: like a number being used in a place

00:02:41: where a string is expected, though that

00:02:43: can also be useful.

00:02:45: It's also about the many places in

00:02:47: JavaScript where a value might be

00:02:50: undefined or null and you forgot about

00:02:54: this scenario when writing your code

00:02:56: and therefore suddenly your application,

00:02:59: your website crashes when it's running

00:03:01: in a certain scenario because such an

00:03:05: undefined or null value was received.

00:03:08: It's cases like this where TypeScript can

00:03:11: help you because it makes you aware of

00:03:14: such situations during development.

00:03:16: It tells you if you are using a value in a

00:03:20: certain place where it could potentially

00:03:22: be undefined so that you can improve

00:03:25: your code to handle that scenario where

00:03:29: a certain value might be undefined and

00:03:32: that can lead to better code, to code that

00:03:35: contains fewer bugs and that hopefully

00:03:38: doesn't crash at runtime that often.

00:03:42: So TypeScript really brings some

00:03:44: advantages to the table, at least in my

00:03:47: opinion and as it seems, as I mentioned

00:03:50: initially, also in the opinion of many

00:03:53: other developers.

00:03:55: Now at the same time we had for

00:03:57: example dhh dropping TypeScript in his

00:04:01: Turbo library because he complained

00:04:04: about unnecessary type gymnastics

00:04:07: being required when trying to write

00:04:11: correct TypeScript code because that's

00:04:14: also important.

00:04:16: You can of course, when working with

00:04:18: TypeScript, often take shortcuts and use

00:04:22: the any type or the exclamation mark to

00:04:26: tell TypeScript that you know that a

00:04:29: certain value can't be undefined in that

00:04:32: place where TypeScript thinks it could

00:04:35: be undefined.

00:04:37: You can use such shortcuts to avoid

00:04:40: writing complex types or extra checks to

00:04:45: rule out certain types.

00:04:48: And it's especially that part where you

00:04:51: sometimes might need to write complex

00:04:54: types which typically means complex

00:04:57: generic types which you really have to

00:05:00: learn to get right.

00:05:02: It's situations like this where you might

00:05:04: feel inclined to drop TypeScript because

00:05:07: yes, this can be complex and annoying

00:05:11: and introduces a new error source

00:05:16: because if you get a type wrong, you

00:05:18: might start using it incorrectly and you

00:05:20: might start using some value incorrectly

00:05:23: and in the end it does have a pretty

00:05:26: steep learning curve to be able to write

00:05:29: good generic types.

00:05:31: So yes, that can be annoying.

00:05:34: However, this is mostly a problem library

00:05:37: authors will face because if you are

00:05:40: writing a library that's meant to be used

00:05:44: by other developers in their projects, you

00:05:48: might want to use TypeScript to help

00:05:50: those developers in case they are using

00:05:53: TypeScript in their projects so that your

00:05:56: library gives them proper types and

00:05:58: works properly in their library.

00:06:01: So you might want to use TypeScript

00:06:03: when writing your library and it's indeed

00:06:05: in such situations where you often need

00:06:08: to write complex types.

00:06:10: And the reason for that is that if you're

00:06:13: working on a project, not on a library,

00:06:16: you often don't need super complex

00:06:19: types because you can often rely on type

00:06:23: inference and also because you don't

00:06:25: need to write very generic abstract

00:06:29: functions or value types that can be

00:06:32: used in a broad variety of situations.

00:06:35: Instead you often have one specific

00:06:37: situation, one specific place in your code

00:06:41: where a certain value is only used in one

00:06:44: very specific way and therefore you don't

00:06:47: need to set up a super flexible,

00:06:49: complicated type to support all other

00:06:52: kinds of value types.

00:06:54: If you're building a library on the other

00:06:56: hand, you typically need to do that

00:06:58: because you want to offer flexibility in

00:07:02: many places so that your library can be

00:07:05: used in a broad variety of different

00:07:07: projects.

00:07:09: And therefore indeed if you are writing

00:07:11: code for a library, you can have a hard

00:07:15: time from time to time when working

00:07:18: with TypeScript.

00:07:20: Now I would argue it's probably still

00:07:23: worth it because for one, your library

00:07:26: being written in TypeScript of course

00:07:28: also gets the benefits of using

00:07:31: TypeScript, which for example means

00:07:33: that certain errors can probably be

00:07:36: caught early and fixed.

00:07:38: It also means that your library might be

00:07:40: more interesting for other developers

00:07:43: who are using TypeScript in their

00:07:45: projects.

00:07:46: It might also help with collaboration and

00:07:49: finding collaborators because whilst

00:07:51: TypeScript could also be an extra hurdle,

00:07:55: it might also mean that you're getting

00:07:56: higher quality collaborators who help

00:08:00: you working on the library.

00:08:02: But of course ultimately, it is something

00:08:05: that's totally up to the library author and

00:08:08: I can fully understand if you don't feel

00:08:11: like doing all those type gymnastics.

00:08:14: Though the super important thing here

00:08:17: really is that I'm now talking about

00:08:21: libraries.

00:08:23: As I mentioned before, if you are

00:08:25: working on some project, on some web

00:08:28: application, and you're just using some

00:08:30: libraries but you're not writing one

00:08:33: yourself, then chances are pretty high

00:08:36: that you don't need to write a lot of

00:08:39: complex types.

00:08:41: You might sometimes need a bit of a

00:08:44: more complex type here and there, but

00:08:47: it's typically not too bad.

00:08:50: Of course, always depending on the

00:08:52: exact project you're working on, on the

00:08:55: size of the project and so on.

00:08:57: But chances are high that you won't

00:09:00: have a too hard time when using

00:09:03: TypeScript in such a project.

00:09:06: And that's why I believe that every

00:09:08: developer, library authors excluded to

00:09:11: some extent, should really consider

00:09:14: using TypeScript and learning

00:09:17: TypeScript therefore because there are

00:09:20: real benefits to be reaped and the price,

00:09:24: if you're not one of those library authors,

00:09:26: really isn't too high, in my opinion.

00:09:31: And indeed, the opposite is the case, I

00:09:33: would say.

00:09:34: If you know how to work with TypeScript,

00:09:38: you become more employable, both for

00:09:42: a fixed employment position but also as

00:09:46: a freelancer.

00:09:47: Because if they're not using TypeScript,

00:09:49: that's okay.

00:09:50: You do know how to work with vanilla

00:09:52: JavaScript after all, since TypeScript just

00:09:56: builds up on that.

00:09:57: But if they do use TypeScript, you have

00:10:00: an advantage compared to developers

00:10:02: who don't.

00:10:03: So from that perspective, it also makes a

00:10:06: lot of sense to learn TypeScript.

00:10:10: The question then just is how good you

00:10:13: have to become at TypeScript.

00:10:16: You can definitely try to become a

00:10:19: TypeScript master who's able to read

00:10:22: and understand and most importantly

00:10:24: write all the super complex generic

00:10:28: types you might sometimes need in

00:10:29: certain libraries.

00:10:31: But chances are that that's not

00:10:33: something you have to do because for

00:10:36: all the reasons I mentioned before,

00:10:38: where if you're not working on a library,

00:10:40: you might not need those super

00:10:43: complex generic types.

00:10:46: Now of course, using TypeScript has one

00:10:49: other disadvantage besides those

00:10:52: complex types you sometimes need to

00:10:54: write.

00:10:55: And that disadvantage is that it's not

00:10:58: running in the browser without an extra

00:11:01: compilation step.

00:11:02: So if you're writing TypeScript code, you

00:11:05: can't just take that code and upload it to

00:11:09: some server and call it a day.

00:11:12: It will not work once it's been loaded

00:11:14: into the browsers of your users.

00:11:17: And as a side note, that's a bit different if

00:11:20: you're using TypeScript for server side

00:11:23: code, for example, because indeed there

00:11:26: we have solutions like bun, which is a

00:11:29: JavaScript and TypeScript runtime or

00:11:32: extra packages that indeed do allow you

00:11:36: to execute TypeScript code just like that

00:11:39: without a compilation step.

00:11:41: But if you're writing client-side

00:11:43: JavaScript code, it won't work just like

00:11:46: that.

00:11:47: And that of course can be a

00:11:49: disadvantage if you have maybe a pretty

00:11:51: simple project, which otherwise

00:11:54: wouldn't require a compilation step and

00:11:59: wouldn't require a build tool that

00:12:01: compiles your code and optimizes your

00:12:04: code.

00:12:05: Or then you still need one because

00:12:08: you're using TypeScript.

00:12:09: So that need for that extra compilation

00:12:12: step and build step, that of course can

00:12:15: be annoying in certain situations.

00:12:18: Now again, my feeling here is, and what

00:12:22: I see out there, that for many projects,

00:12:26: probably most projects, front-end

00:12:29: JavaScript projects, you have a build tool

00:12:33: and a build step anyways.

00:12:35: You're using something like Vite or

00:12:37: Webpack anyways.

00:12:40: And then adding TypeScript shouldn't

00:12:44: be a huge deal, to be honest, because

00:12:47: you have that process anyways.

00:12:49: Why not just add in that compilation

00:12:51: step?

00:12:52: Typically it shouldn't be too complicated.

00:12:56: So that might be a reason for some

00:12:59: people.

00:13:00: For example, it was a reason for the

00:13:03: Svelte team, which also dropped

00:13:05: TypeScript and moved to JS docs, which

00:13:09: is another way of adding types that does

00:13:11: not require a build step, but also isn't as

00:13:15: ergonomic in my opinion.

00:13:17: But it's probably not an argument for

00:13:20: many other developers who have a build

00:13:22: step, who have a build tool in their

00:13:24: project anyways, because there it really

00:13:27: doesn't matter too much.

00:13:28: Typically compilation also doesn't take

00:13:30: super long.

00:13:32: And of course, as I mentioned, we also

00:13:34: have situations where you might not

00:13:36: need one at all despite using TypeScript.

00:13:39: If you are, for example, executing your

00:13:42: code with a tool or in an environment

00:13:45: that natively supports TypeScript,

00:13:48: though there you always might want to

00:13:50: at least question whether you possibly

00:13:53: could have a performance disadvantage

00:13:56: by running uncompiled TypeScript.

00:13:58: That could be a valid concern there and

00:14:00: is something you should definitely check

00:14:02: and make sure that it isn't.

00:14:05: But for all those reasons, I do believe

00:14:08: that most developers should learn and

00:14:11: use TypeScript because learning it

00:14:14: honestly isn't too complicated if you

00:14:17: don't get into those super complex

00:14:20: types, at least initially.

00:14:22: And therefore, then you just get a lot of

00:14:25: benefits, in my opinion, without too

00:14:28: much extra work.

00:14:29: And indeed, once you've worked with

00:14:32: TypeScript a bit, you will see that

00:14:35: actually you don't have to add too many

00:14:38: types in your code base because often

00:14:40: you can rely on type inference anyways,

00:14:44: and then you just get the benefits

00:14:46: almost without any additional extra

00:14:50: work.

00:14:51: And that's why I personally love

00:14:53: TypeScript and why I'm using it in

00:14:55: essentially all my projects and why I

00:14:59: recommend the same for most other

00:15:01: developers.