[scambier]

I've been writing TypeScript for at least 6 years now, and I couldn't go back to JavaScript. I understand the arguments of those who don't like it, but ultimately they all boil down to either "writing types is tedious" or "I know better than the compiler".

> I spend more time trying to resolve TypeScript complaints than I do adding code

Those complaints from the compiler are the main feature of any statically typed language! In TypeScript, they're here to tell you that something is potentially wrong with your code, and it might break in runtime.

"I spend more time trying to resolve [typing errors] than I do adding code" is something you'll hear from anyone that is not used to statically typed languages. _Any_ language, not just TypeScript. And it's an issue that quickly goes away by itself once you learn the language.

> Our team has lost hours on TypeScript exceptions in staging and production builds (but oddly not offline/local) where some external type was missing or incompatible, another one being that the local environment passes linting but CI doesn't, it shouldn't be so hard

That one is probably a simple configuration issue, not TypeScript's fault.

> Having to rewrite correctly and infallible JavaScript so that it was friendly enough for TypeScript to understand

This one I can get behind, but I'd put it in the same bag as the first point. I'm sometimes tempted to use things like non-null assertions (like in the example with the .filter().map()) but I'd say that 99.9% of the time the compiler is right, and it's safer to right one more line than a `!`. But you don't do it to make TypeScript happy, you do it to rule out a potential edge case, and avoid a runtime crash.

[tipiirai]

I hear you, but I think the author has a point. I also want to spend more time on coding than trying to resolve TypeScript complaints.