TypeScript wasn't better than Flow when it gained dominance. It happened because Microsoft created an out-of-the-box experience with VS Code that worked great with TypeScript but made Flow types look broken.
More generally Microsoft treated Typescript as a product - they built it based on feedback from outside users and worked hard to make it easily adoptable and to grow a community around it. They are also "pragmatic" - willing to have weird, unsound semantics if it's needed to help people adopt Typescript and model existing JS ecosystem patterns.
Flow has always been an inwardly-focused project that is for Facebook's needs first. The Flow team at FB made an explicit decision to focus more on compiler performance improvements (what Facebook's usage needed) over outside users & community.
The way I remember, when flow was introduced, you had to do small changes to 3rd party dependencies your code might have had to make them flow-compatible.
With typescript you could just write a type definition file for any 3rd party library, so you could essentially make any 3rd party dependency "typescript compatible" without needing to change its code.
This small difference made a huge impact for adoption. Eventually flow also got that feature but by then the adoption difference was already too big.
From what I remember TypeScript was a superset of Javascript, so you could just rename your files and enable TypeScript and it all worked, and then gradually move stuff over. That probably helped a lot.
