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.
>Being presented with lots of double colons, <T> when I'm not sure what T refers to, a wall of interfaces and more is an upfront cost on me, the reader.
I find this an odd point to be arguing given that in a dynamically typed language you have no idea what _anything_ refers to.
Java-like generated docs can be great or terrible. (I remember to old AWT in Java which had an invalidate() method which was documented to “invalidate the component” which did not at all tell you when you were supposed to use it. Today those docs do explain that.
> 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.