My take away from this: If you don't have the discipline on your team to enforce good structural standards for your code, TypeScript may not help as much as you

My take away from this: If you don't have the discipline on your team to enforce good structural standards for your code, TypeScript may not help as much as you think. In my very much opinionated opinion, all the issues highlighted in this article, are avoidable with: 1. Don't use the `any` type (I'm actually pretty shocked this article doesn't talk about using `unknown` instead of `any`. I have found `unknown` can be used where `any` tends to be used, most of the time, if not all the time, and it comes with the benefits of things like assertion control & tsc's type interference (it acts almost as a marker, in some ways, basically, for the type that gets fed through. It also forces you to think about validating the input) 2. Enforcement of strict options for the compiler A non-goal to me is using TypeScript to avoid writing tests. This should never be someone's idea in adopting any typed language. I think this is a smell of a bigger problem. Types or no types, it does not influence why or how many tests I write, as testing is about validating your programs ability to handle its inputs & the correctness of its outputs (your testing algorithms, at the end of the day), so I do not see how this factors testing at all. Types also do not negate the fact you need to do validation (beyond perhaps, trivial validation of arguments at the call site, if your codebase is actually following good structural patterns) Is TypeScript perfect? No. Should you use it? I think you should probably make that decision after a careful reading of the documentation & discussing it with your team. Do I personally think this article has a strong case against TypeScript? No, as its (to me) very trivial to avoid any of these problems. You know what would likely be more effective with most code bases I've seen though? Good documentation & comments, with explanations of what things do if it isn't obvious enough to pick up in a second or less glance. Preferably following the JSDoc standard.