> Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but y

> Unless you're working with a strict sound type system, you only have a little more information: you know the properties and methods of what is returned, but you don't know what state its in. So you won't typo a method name, but you still might be dealing with errors from shit that cost cast incorrectly, nulls (even with strict null, since it wasn't there from the start you will still deal with it), arrays not containing what you thought they did, etc. You're throwing out (or, rather considering the tricks you can pull in Typescript, hugely reducing) entire classes of issues when using a simple type system. > I've worked on multi million line mono-repo pure javascript with zero tests with hundreds of devs working on it, and it worked fine (in fact, we were moving more stuff from the Java/C# code into JavaScript to reduce overhead and friction). If you have tests on top, or if your devs are actually good, its just easier/better. I've worked on a huge PHP codebase once, with 10 developers working on it and no tests. I would have given somebody else's right hand to have a type system back then. > Now, I'm not saying a proper type system doesn't add value. Thats a whole different argument. But any team who can build good software in a static type language can do so in a dynamic one. Its just a different set of tradeoffs. The point is, the cost of adopting Typescript is frankly, very low, from my point of view, considering the huge benefits it has over raw JS, it's all win.