I see a lot of anti-TS arguments that amount to "it doesn't provide runtime guarantees". It's like suggesting that seatbelts are bad because they won't help if you get T-boned by a truck. The problem was not introduced the safety measures! The fact of the matter is that TypeScript moves some of the correctness-checking to compile-time instead of runtime. Maybe you wish it did more, but it is inarguably a step up from plain, untyped JavaScript. There are some mistakes that will be caught much faster with static types. If you don't see them, it's not because they're not there.
You might think it's a false sense of security, but that's user error. For external-facing code, if you're not confident that you'll get a value of a certain type, don't type it as such. Type it as any and then do your checks, which may allow TS to infer the proper types for the rest of the function. Or, next call a private/internal version that has explicit types.
So that just leaves the idea that it's too much effort for the benefit. That's primarily a matter of opinion... so I probably won't change your mind, but you'd have to do better if you cared to change my mind. (And if you don't care, why write a blog post and read/respond to its comments?) But let me back up my opinion with some ideas you might have overlooked:
TypeScript can infer a lot. You could replace const createId = (length: number = 32): string => ... with const createId = (length = 32) => ... and it would understand the types just fine. Fortunately, this works well with the internal code you don't want to write types for.
You said yourself that well-written apps are built of countless pieces. You also said types matter most at the interface. But if we connect those dots, we can conclude that the in-between makes up a significant part of the app! Combine that with #1: There's a lot of interface - where typing is agreed to be valuable - and a lot of internal code where typing takes little effort. Sounds like a win-win to me.
You've looked at programming at rest, but what about change? If you learn that createId needs to take another parameter, anything that uses it needs to change, too. TypeScript will not let you forget to update the consuming code. Or, if you decide to start using numerical Ids, things might just cascade through type inference. But, if anything relies on that id being a string, TypeScript will let you know. TypeScript requires more work in the places where things can go wrong.
There's an incredible amount of expressiveness in the type system, especially when complex structures are involved. It goes way beyond primitives, classes, and interfaces. I'd highly recommend browsing the advanced features TS offers. A favorite of mine is "Discriminated Unions".
While I think this article is extremely well written, and I do appreciate it, your comment does lay out some excellent points. First and foremost is that regardless of JS or TS you can still have runtime errors. If you get too complacent in your TS code because you think the compiler got everything, then that's on you and not the language, as is the case in any environment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I see a lot of anti-TS arguments that amount to "it doesn't provide runtime guarantees". It's like suggesting that seatbelts are bad because they won't help if you get T-boned by a truck. The problem was not introduced the safety measures! The fact of the matter is that TypeScript moves some of the correctness-checking to compile-time instead of runtime. Maybe you wish it did more, but it is inarguably a step up from plain, untyped JavaScript. There are some mistakes that will be caught much faster with static types. If you don't see them, it's not because they're not there.
You might think it's a false sense of security, but that's user error. For external-facing code, if you're not confident that you'll get a value of a certain type, don't type it as such. Type it as
anyand then do your checks, which may allow TS to infer the proper types for the rest of the function. Or, next call a private/internal version that has explicit types.So that just leaves the idea that it's too much effort for the benefit. That's primarily a matter of opinion... so I probably won't change your mind, but you'd have to do better if you cared to change my mind. (And if you don't care, why write a blog post and read/respond to its comments?) But let me back up my opinion with some ideas you might have overlooked:
const createId = (length: number = 32): string => ...withconst createId = (length = 32) => ...and it would understand the types just fine. Fortunately, this works well with the internal code you don't want to write types for.createIdneeds to take another parameter, anything that uses it needs to change, too. TypeScript will not let you forget to update the consuming code. Or, if you decide to start using numerical Ids, things might just cascade through type inference. But, if anything relies on that id being a string, TypeScript will let you know. TypeScript requires more work in the places where things can go wrong.While I think this article is extremely well written, and I do appreciate it, your comment does lay out some excellent points. First and foremost is that regardless of JS or TS you can still have runtime errors. If you get too complacent in your TS code because you think the compiler got everything, then that's on you and not the language, as is the case in any environment.