[eyerony]

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people.

As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.

[IBCNU]

My experience is by definition anecdotal, but what I've found is as the team grows more and more work seems to focus on defining the types, futzing with the types, talking about the types instead of talking about features. I come from a Clojure/script background so I suppose I'm trying to say if (in building UI's) if you bake in strong immutability and a functional approach (like re-frame... but JS) types, to me, become less and less of a concern. Of course it's highly dependent on the business requirements.