Deep JavaScript Foundations, v3

Static Typing Cons

Kyle Simpson

Kyle Simpson

You Don't Know JS
Deep JavaScript Foundations, v3

Check out a free preview of the full Deep JavaScript Foundations, v3 course

The "Static Typing Cons" Lesson is part of the full, Deep JavaScript Foundations, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle discusses the drawbacks of static typing.


Transcript from the "Static Typing Cons" Lesson

>> Kyle Simpson: I guess my biggest negative is that they chose to use a syntax that they had to layer on top of JavaScript. And some day, maybe JavaScript standardizes this syntax in it. What they've had to do is essentially go and define an external standard for it. It's not that there is no spec, but it's an external standard, not a JavaScript standard.

And there's certainly no guarantee or even likelihood at this point that we see in TypeScript or Flow is exactly what might end up in some hypothetical JavaScript. But it is years away, it's not like we have a stage three proposal to add typing to JavaScript at any point soon.

This is way far out if it ever happens. And I think it creates a sort of ecosystem lock-in whenever you choose a particular syntax and a particular kind of tooling that isn't portable, because it isn't the same as what JavaScript is. JavaScript won because it's so ubiquitous, but then now we're locking ourselves into this ecosystems that even though it's popular, is not necessarily as ubiquitous.

And so I guess that's one of my biggest frustrations or my biggest hesitations. Now, it is true that I was actually very pleased when I saw that these tools came out with a way that you can do their typing annotations using only code comments. So at least in that scenario, you haven't locked yourself into if I don't use this tool this code literally can't run, all right?

That's sort of an escape valve if you will, and that's a good thing, but almost nobody's using the code comments. Everybody's using the inline syntax annotations. And so there is a lot of lock-in that happens and I guess I've been around long enough to be wary of those sorts of lock-ins.

Another thing, and I've got an asterisk here on purpose, but essentially using those tools requires a build process which kinda raises the barrier to entry. And the only reason that you wouldn't be required to have the build process is if you did that code comments approach and then got no benefit from the system whatsoever.

So nobody would do that. Nobody would go to all the trouble to write all those code comments and then not use the tool at all in the compiler and then ship it directly. So they're essentially requiring this build process. And build processes are definitely common these days, but again as an old schooler it's nice to just be able to write a JavaScript file and load it directly into a page without having the complexity of a dozen tools in some particular pipeline.

And so I'm not a big fan of us saying to future developers that wanna learn JavaScript, by the way, you also have to learn all this DevOps and stuff just to write your first line of JavaScript. If TypeScript represented what I hope the future of JavaScript would be, what bothers me is that TypeScript is done in such a way that they're gonna be locked into that build process forever.

And I don't think that's great as a barrier to entry.
>> Kyle Simpson: Kind of flowing from that same discussion would be that there is a trade-off when you make really sophisticated tools, is that you create a surface area which gets complex very quickly. The difference between the examples that I've showed, which were just some sort of basic layered-on types, and when you start layering in things like generics and interfaces and other things like that, you rapidly, rapidly get to a style of code that doesn't look even remotely like JavaScript.

It looks like Haskel, in my estimation. And I don't mean that in a sort of, I don't mean that in a way to say, TypeScript's bad because that's the case but that is very intimidating. I mean I'm spending time and lots of mental effort here trying in the research for this course trying to figure this stuff out, and I start reading through some of the advanced features of this.

And I just got completely lost with all these angles brackets nested all over the place and stuff. The syntax explodes exponentially in complexity. And I think if anyone were using those sophisticated features, I cannot imagine them hiring a developer on that was not already very, very strong TypeScript developer, them having any clue what to do with the code base.

So again, that barrier to entry ramps up very, very quickly as your start to use more and more of that tool. And I guess maybe the final frustration that I have or the difference that I share with these tools is that I don't think it's in the DNA of JavaScript to consider the idea of static typing.

That is that containers, things like variables and parameters and returns and properties, that they necessarily must only have one type always and forever. There can be some places where that's beneficial like the return type-over function but variables, I guess, specifically, I don't think that's within the DNA to type our variables.

If you think of what JavaScript really is and in fact any dynamic language it's a language that is value typing, not variable typing. And so this feels like the wrong thing foisted on top of JavaScript. It feels fundamentally to me like it's not, it's a betrayal, it's not respecting the way JavaScript works.

It's trying to make it into something different. And some people are trying to make it into something different because they think what JavaScript currently is, is insufficient. That it's broken, that it's not good enough. I think JavaScript is fantastic. So I don't think we need to fix JavaScript.

That I think is probably one of the strongest callings. So there's a big divide there, between the great things that this tooling can do for the ecosystem, and for the teams that are using it, and I think some really strong downsides, and there should be more options in between.

And it's why I started this discussion by saying I wanna broaden the discussion from just specifically these two trademarks like TypeScript and Flow to a larger discussion about the idea of type aware linting. The type aware linting as an idea is useful and important. And TypeScript and Flow are two particular ways of doing it, but not the only ways of doing it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now