Typescript also significantly reduces communication overhead and provides machine-verifiable documentation, making it way easier to figure out WTF is going on with unfamiliar or long-out-of-sight code. People who don't love TS compared with vanilla JS must work entirely differently from me—using it's the only time I've not hated writing JS. Tons of time-wasting poking about and background anxiety just gone. It's great, and costs almost nothing.

Typescript is a gamechanger with generated interfaces. We use it heavily with an RPC framework and pulling down the generated client and server packages have drastically minimized integration issues.

It just takes away the mental overhead of making something conform to a spec. It probably doesn't save us much on production bugs, but it makes development faster.

Generated interfaces are an anti-pattern. Types force tight coupling between clients and servers. What if a third-party project written in a different language wants to communicate with your server using their own client? Types will make it more difficult for them to integrate because:

1. If they're using a dynamically typed language, this gives them extra work to typecast everything back and forth whenever they need to communicate with your system.

2. Even if they use types, maybe their type system is not compatible with yours and they need to do a lot of tedious extra work to typecast everything.

Huh? Everything always has a type anyway. It's sometimes just harder to know what it is. Specifying doesn't make the types appear out of nowhere, it just documents them.

I wouldn't call that an antipattern.

I treat other systems like I do the database and enforce consistency at the API level.

I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API.

Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.

No, it makes it easier, because they have a specification to work from, and they can probably just use that spec to generate their own glue code, assuming any is necessary.

I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.

I've found it to be annoying in the other direction. A type system like protobuf isn't rich enough for the problem domain. We end up building a lot of additional validation into the servers and clients that could have been enforced by the service/types spec.

Which is why our rpc services accept json in addition to protobuf. Yay, problem solved.

what is the solution? runtime errors?

>> In Airbnb, they found out that 38% (!) of bugs could have been prevented by using TypeScript[1].

I don't buy these hypotheticals and also I don't believe in this kind of anecdotal evidence.

I think that the real root problem is that they didn't break down the code into logical components and didn't test them correctly - That was the real problem, not JavaScript.

When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-abou...

> I don't buy these hypotheticals and also I don't believe in this kind of anecdotal evidence.

The only anecdotal evidence I've linked is Stripe's experience with Sorbet. The paper linked is an actual scientific analysis with great study design. I couldn't find the Airbnb slides or talk but an engineer involved claims the study was carefully designed[1].

> When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-abou....

Go read the "study" referenced in that article. It's just blog post with a terrible methodology. It's basically

(number of issues with bug label) / (lines of code)

The author doesn't even normalize for LOC (larger codebases tend to have more bugs) or take into account project complexity.

[1]: https://twitter.com/swyx/status/1094857103863209985

EDIT: add disclaimer about airbnb talk

I would love to read the Airbnb study. Do you have a reference ?

The other study you referred to sponsored by Microsoft is very vague on the methods used to conduct the experiment. So its not repeatable. You can't say something is scientifically true unless the results are repeatable.

the problem with study like airbnb is that while tooling would have caught X% of bugs of type A, it in no way means those wouldn't just be replaced by bugs of type B.

bugs are (in part) function of code and tooling complexity, making some bugs harder to introduce doesn't reduce that complexity. risk compensation principle is another factor, and so on.

i haven't yet seen strong evidence that static typing really reduces bug density.

Eric Elliott has been making claims like these for years now. You can see the comments here taking apart the last round (which was more substantiated than the one you linked to).

https://news.ycombinator.com/item?id=18977700