[speedgoose]

Instead of writing types, you write tests.

[curryst]

You need rigorous tests though. At some point you end up with a hacked on version of typing. I appreciate that Typescript will tell me "this value might be null, and that function doesn't handle null" rather than writing a bunch of runtime checks to make sure the value isn't something invalid, and then writing tests to make sure those work.

[speedgoose]

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.

[clusterfish]

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.

[speedgoose]

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.

[clusterfish]

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.

[myvoiceismypass]

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

[karatestomp]

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.

[speedgoose]

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

[actsasbuffoon]

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.