TypeScript & Flow

[00:00:00]
>> Speaker 1: So leading this entire discussion, we've been saying that we want to know our types. We want to use a coding style that makes our types more obvious. And up to this point I've been using only what we know about JavaScript to do that. I've been suggesting that we can restrict the kinds of values that can come in for type comparisons, for example.

[00:00:20]
And I think that is a valid and worthwhile approach that will improve the quality of your code. Regardless of whether you like or dislike the current trend towards these typing systems like TypeScript and Flow. And I'm gonna say in a broader category, type-aware linting. As we said earlier, linting is essentially a tool that applies an opinion about your code and gives you that opinion so that you can decide, you know what?

[00:00:47]
I agree I shouldn't do that. My linter catches all kinds of things that I don't wanna do, and I'm glad my linter catches it. I'm very much pro the idea of linting. As I said, I'm only pro linting that is configurable, however, because there is not a one size fits all.

[00:01:05]
Now, I'm not in the situation like many of you are, where you're on a team. But even with respect to making that decision, you should still be able to have the team decide democratically. Rather than the team only be able to pick what every other team in the entire world has done.

[00:01:23]
It's still better that the team could decide what works for them, and that the individual members of the team get to have a say-so in what that is. We call that style guidance. That's an old school term. Your team needs a style guide, and everybody should have a vote in the style guide.

[00:01:40]
I don't like it when I go and work with a team, and there's some benevolent dictator on the team that has made all the decisions for everybody. And people come up to me during the breaks and they're like I'm scared to try this cuz he's gonna reject my pull request.

[00:01:53]
That's not a healthy culture. Everybody should get a say-so in what works for your team, not me. You and your team members should get to say.
>> Speaker 1: So broadly speaking, I get a lot of times this question of what do you think about TypeScript?? Well, what I think about TypeScript and what I think about Flow are similar, which is I'm glad that they exist even though I don't use them.

[00:02:21]
I don't use TypeScript and I don't use Flow, and I used to tell people the reason I don't do that is because they solve problems that I don't have. I have a different perspective on that now, a perspective that has evolved recently. It is not the case that I don't use them because I don't have the same problems that they solve, that's not the appropriate way to say it.

[00:02:46]
I don't use those tools or don't prefer those tools, because they're fixing the problems in a way that I think makes my code worse. Problems exist, as I have said over and over again in this unit of our discussion, it is a problem if you are coding and not knowing anything about your types.

[00:03:02]
That is a problem and we should solve that problem. It's just that I have a different opinion on how to solve it, you with me? So before I talk to you about a solution, let's look at what TypeScript and Flow can do for us. What are their benefits, broadly speaking?

[00:03:22]
I understand that this is a very sort of reduced argument, there is a much more complex and vivid ecosystem. And I don't mean in any way to talk down about these, there's a whole course on Frontend Masters, or maybe even more than one, about TypeScript. These are great tools with fantastic, intelligent people behind them.

[00:03:41]
But just sort of broadly speaking, where do they fit within the ecosystem? What are they gonna do for us? Well, number one, they're gonna catch type-related mistakes, that's a good thing. We need help catching our type-related mistakes. I would like to have a tool that understood what I wanna do with types, and helped me figure out when I didn't do that correctly.

[00:04:01]
That would make me a better coder. Number two, they do communicate type intent, because the typing is in the code. Course they have modes where they are doing only inference. But essentially, the big selling point of TypeScript and Flow is that you can layer these type annotations directly on top of the code.

[00:04:21]
And in some respects, one of the biggest reasons why you do that is because it's gonna make your code more obvious. Well, I can clearly see that that thing is an integer, or that thing is a string, right? That's good. Number three, and I think this is often overlooked, but maybe one of the biggest things.

[00:04:38]
Is that by doing so, by choosing to opt into that system, you get an amazing amount of feedback through the tooling ecosystem that can show up live directly in your ID. It's awesome, I've seen some of the auto completing and on the fly inferences and type analysis that something like TypeScript does.

[00:04:57]
TypeScript does it a lot better than Flow at this point, but I'm sure Flow will catch up, right? I think IDE integration with TypeScript is better than any project that I've ever seen integrated in an IDE, it's fantastic. I happened to not use IDEs. So I happened to not benefit from any of that, but that doesn't mean I don't respect it, I think it's fantastic.

[00:05:18]
>> Speaker 1: There are some caveats to these tools. Number one, the inferencing that you rely upon, which you rely upon inferencing whenever you have a place where you're not gonna annotate. [LAUGH] The inferencing that you rely on really is just a best guess. It's not rock solid. We're guessing something as much as we can at compile time.

[00:05:42]
We don't really know what's actually gonna happen at run time. That flows from number two actually, because the annotations are optional. Which means the developers on your team, if they don't put an annotation on a variable, TypeScript will default to the any type unless you have that turned off.

[00:05:59]
It will default to the any type and then you're not getting any benefit out of it. So it is an opt-in system. And if you don't opt in in a particular place you're only getting a best guess. It can lead to a false sense of security if you're not being very careful about your usage of it.

[00:06:20]
>> Speaker 1: This flows from really what I've been saying the whole time. That any place that isn't typed, either in your code or things that your code touches that are not in your application. If they aren't typed there is uncertainty.