It's a bit hard to follow what the author wants to tell us, so I might be misrepresenting below (sorry!). I don't think the assertions that (I think) they make

It's a bit hard to follow what the author wants to tell us, so I might be misrepresenting below (sorry!). I don't think the assertions that (I think) they make hold though, or are particularly useful. The author claims "functional programming, types, JavaScript: pick two". He supports that with links to a number of libraries that have incomplete type definitions, and a few patterns that are hard to express in a static type system. I don't think that assertion holds. Some JavaScript APIs are indeed written in a style that's very hard to give static types for, and some libraries have sub-par type definitions. But odd JavaScript APIs != the entirety of functional programming, and sub-par type definitions are just missing features that need to be fixed. You can write perfectly fine, statically typed, functional programming idioms within the TypeScript type system (and presumably within Flow). You can even do that within the confines of Java's type system, and that's a lot weaker than TS' or Flow's. These type systems are optional, and you can subvert them. If you use the recommended strictness flags though, it's hard to do so accidentally.