One thing nobody likes to mention much is that the value of a type system also scales pretty heavily with the quality (or lack thereof) of developers using it.
For a small team full of talented engineers (e.g. a startup) it's not unreasonable at all to just... not make typing errors. I've put 5+ large apps into production in the last decade and could probably count on one hand the number of times I've really struggled with something type related.
There's certain anti-patterns that make up the majority of type-related problems in JS. Things like inconsistently mix 'n matching falsey types, adding or removing properties from objects in unpredictable ways, or leaking stringified numbers and bools everywhere.
Other classes of type problems can be solved in dynamic languages by structuring code in more self-documenting ways and properly augmenting any remaining ambiguity with comments.
If your team is naturally coding in a way that respects the dynamic typing of the language then your benefits from TS are going to be much more marginal, and that needs to be taken into account when comparing the costs and benefits of it.
My guess is that we'll see a harder split in the JS community in the next few years. Most people are going to drift towards only taking on TS or JS roles in much the same way most JS programmers wouldn't take a lisp or C# job at the moment.
For a small team full of talented engineers (e.g. a startup) it's not unreasonable at all to just... not make typing errors. I've put 5+ large apps into production in the last decade and could probably count on one hand the number of times I've really struggled with something type related.
There's certain anti-patterns that make up the majority of type-related problems in JS. Things like inconsistently mix 'n matching falsey types, adding or removing properties from objects in unpredictable ways, or leaking stringified numbers and bools everywhere.
Other classes of type problems can be solved in dynamic languages by structuring code in more self-documenting ways and properly augmenting any remaining ambiguity with comments.
If your team is naturally coding in a way that respects the dynamic typing of the language then your benefits from TS are going to be much more marginal, and that needs to be taken into account when comparing the costs and benefits of it.
My guess is that we'll see a harder split in the JS community in the next few years. Most people are going to drift towards only taking on TS or JS roles in much the same way most JS programmers wouldn't take a lisp or C# job at the moment.