Static Types does matter
Static types does matter, they reduce bugs and there are a lot of examples.
A quick example is the story of the angular team at google. They say (over and over) that adopting TypeScript helped them find a lot of bugs, bugs they never saw. This is on a strict, full cover, end to end TDD project with code reviews.
Static types leads to better code, less bugs, self documented project, and superior productivity.
In every team the level of developers differs and Types help bridge the gap by preventing a lot of mistakes and boosting self learning.
As for class hierarchies, I fail to understand the argument. OOP and the class paradigm is probably the most efficient way for the human brain to understand hierarchies, schema and flow. The human brain understands objects and when they are grouped (class) they are easily categorised.
I agree that complex class hierarchies are problematic and might cause dead ends in some complex scenarios but this is a result of OOP abuse and poor design, keeping it simple is the rule of thumb and that’s true for every paradigm one chooses.
Inheritance mass is a result of OOP abuse and poor design, period. That’s not a reason nor an argument for choosing OOP over Composition, it’s like saying car’s cause accidents, don’t use cars.
Composition is a good paradigm and allows great flexibility but it also difficult to reason about once things get complex, it’s hard to track.
I’m not saying composition is bad, as i’m not saying OOP is the best. You can enjoy both worlds. Start with classes, keep them simple. Once things get complex apply composition — they work great together.
With a tool like TypeScript composition get’s super easy to reason about, yes you’ll have the overhead of interface boilerplate but the end result is a well defined contract that keep’s you on track and eliminates misunderstandings. This means less bugs, when you have a clear path governed by a static type system you have less chances to get wrong, thats a fact.
A TypeScript project without TDD is far more understandable then vanilla JavaScript project with TDD. This doesn’t reduce the importance of TDD a bit, but TypeScript with TDD, that’s code heaven.
As an example, from my past experience, leaning the source code of Angular.js was harder then understanding Angular (2), this is only because of types, classes and the easy to follow path they create.
This is not the full story, a type system and a proper IDE support is a game changer. Refactoring in JavaScript is a big issue, without a type system its a guessing game, inference hell. On the other hand, a solid type system provides deterministic refactoring, there are zero mistakes. In an Agile managed project this is a life saver, and I have experience it multiple times. Need a change? no problem, refactoring to the rescue. I agree that with composition and pure functional approach Refactoring is also easy but not as easy as static type refactoring.
There are lot’s of advantages gained with a type system and a lot of restrictions, I agree. This is where TypeScript excels, you enjoy both worlds. You can do static when you want and how much you want. This is not like C# or JAVA where you must type everything.
To sum it up, typed languages are widely used and heavily adopted, for a reason. We just need to take a quick look at the adoption rate of TypeScript and decline of Babel (ES6) to understand what most developers prefer.
Wisdom of the crowd is not something we can ignore, if people prefer TypeScript it’s because it providers them something, probably better coding experience and better understanding of their projects, that’s not something one should dismiss or overlook.