The cost benefit of typescript is a range. The benefit is that you have some greater chance that your code does not suffer from passing bad parameters. Bad para

The cost benefit of typescript is a range. The benefit is that you have some greater chance that your code does not suffer from passing bad parameters. Bad parameters have some characteristics: missing, too many, too few, wrong types and bad values at least. It is important to understand that you are not "using typescript". You are in fact adding a layer of code on top of javascript. This layer is a variant of javascript, adds tooling and requires additional effort. One overlooked aspect of typescript is that it requires of typescript to read it. If you publish your typescript code, for example in an open source project, it is less accessible to javascript programmers. The tradeoff between these two is something that is use case dependent. As a sole developer, after a couple of attempts I am adopting option #3. Instead of `function dosomething(params) { console.log("%s, %s",params.duck, params.dog)}` I now write ` function dosomething({duck, dog}) { console.log("%s, %s", duck, dog)} ` I find this gets me at least 50% of type problems that I usually miss, and the cost is extremely low. As a sole developer who needs to be extremely productive I simply can't afford typescript. I can afford this. And maybe there are other easier-to-use ways to catch other type problems?