Eh... people say this, and in theory it should be true.
If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful.
For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch.
You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down.
The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.
If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful.
For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch.
You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down.
The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.