You need rigorous tests anyway. Typescript is checking types only at compile time if I'm not mistaken and what it detects is only a set of problems. Yes it's nice that you can detect some types errors thanks to typescript, but is the development overhead worth it? With eslint, sonarqube, and tests, I think typescript is not that useful and annoying to use.

For example I contributed to Typescript's definitely typed project in the past. To make typescript more useful. But I ended up spending so much time writing type definitions. After all, I rather have some NaN or "undefined is not a function" exceptions during development.

You need less tests in a type safe language. Especially in a good one like reason / scala.js / elm. Typescript is just not very safe, its type system is unsound by design because compatibility with JS is their #1 priority.

Yes, you have the illusion of type safety but all you need is a slightly different JSON from an API to realize that typescript isn't that interesting.

All you need is a bug in your tests or mocks or fixtures to realize that tests aren't 100% foolproof either. Nothing is, we all know that.

That said, in proper type safe development at least your own API comms should be type safe. It's easy if you use the same language on client and backend, which is possible with Typescript, Reason/Ocaml, Scala, Rust, etc.

The problem with Typescript is that it's half assing type safety in the language itself and people generally half ass type safety in other aspects of development too. You just can't expect to reap the benefits of real type safety with such an approach.

That’s where you use something like https://github.com/gcanti/io-ts to enforce types on unknown data at runtime.

TypeScript is better at documenting intent for other developers (where "other developers" includes your future self) than either tests or comments/readmes. It just about entirely takes care of the "what" so comments and docs can be reserved for the "why". It's an outstanding communication tool and recording what it does, at function/method boundaries at least, is something you should be doing anyway, so might as well let a machine verify you've gotten it right.

I agree it's important to document. But if you need types to understand what's the code doing, there is a problem.

It's less "need" and "does the same thing but far more efficiently and can't rot because a machine makes sure it's correct".

I like letting my tools do stuff for me. If a tool can go look up what arguments this function expects, and their types, and tell me that, rather than my having to go check, and then also warn me if I typo one of them, then also take me straight to the definition of the function if I decide I want to read it, without my having to go hunt it down manually, all at zero cost (again, these things should be documented anyway), then why the hell not?

[EDIT] I guess I just don't understand why people consider it burdensome. You probably ought to know your function's going to take a string. Is it that hard to type "string" in the signature? You're gonna have to figure out what it's supposed to return—when you do, write it down. It's a little more work for more complex structures but it still amounts to typing out things you already have to think through anyway, and the more complex the more important it'd be to record that somewhere, so may as well be machine-readable type information. In return, when you accidentally try to treat your string like a number you'll immediately know you've missed a step, you'll get comprehensive autocomplete on hashes and classes and such, jump-to-definition, instant typo-spotting, automatic refactoring, and so on, and you can hand it over to someone else and they'll get those same things, instantly. The payoff is 10x, at least.

There are libraries that will help you do runtime checks to ensure that your JSON matches the shape of your schema. It’s a bit tedious, but it works.