Comment by chris_armstrong
15 hours ago
Many of the highlighted problems come from TypeScript allowing such complex type definitions in the first place, which in turn stems from JavaScript allowing such an open and untyped (and yet convenient) compositional model.
The expressiveness of JavaScript is a curse upon every library author who (in vain) may try to design an interface with a simpler subset of types, but is undone by the temptation and pressure to use the flexibility of the language beneath.
The author's instincts are right though - target a simpler subset of TypeScript, combine code generation with simpler helper libraries to ease the understandability of the underlying code, and where a simpler JavaScript idiom beckons, use runtime safety checks and simpler types like `unknown`.
Might I add - this isn't limited to languages like TypeScript which simply try and make underlying untyped languages (like JavaScript) safer. It affects well-designed strongly-and-statically-typed-from-the-ground-up languages which have expressive type-constructs (Rust, anything ML-based, etc.) used to reduce repetition and code-generation steps.
This is true to some degree, but something about javascript/TS seem to lead to just incomprehensible typings. Imo any types where you start having to look at the keys of some map is going to lead to pain, but most other languages don't let you do that.
Javascript is not untyped; it's dynamically typed.