TypeScript has a bunch of holes in it because it needs tight compatibility with JavaScript. While a pure functional style may be possible, it isn’t first-class or ergonomic or as expressive, and won't cut it for many. Are there first-class function composition infix operators? Is pattern matching algebraic data types often the easiest way to write code? Is IO managed? With a language like Elm and others in the ML family, functional style is the only game in town, not just the in-house convention, and it's easier to have people using a similar style if it’s ergonomic. Even if you’re willing to give up managed IO OCaml and Reason are going to suit this programmer better than TypeScript. I would not be surprised if a lot of the fp-ts crowd is merely tolerating this as a comprise.
> Now what we really need is a functional dialect which compiles to TypeScript...
Why would it be beneficial to have TS as an intermediate representation? It turns into JS anyway, and there are already statically typed functional languages that compile to JS.
It would massively simplify the job of proving the upper language more correct. It may also be possible to proxy the type system in order to make use of existing tooling.
TypeScript or Flow for that matter sucks at using functional style with immutable data types. There are ESLint plugins that allows to enforce immutability with plain JS objects, but still lack of syntactic sugar or union types makes the experience much worse then in functional languages.
Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.