It is a shame that so few React-based libraries are on DefinitelyTyped. As the project I've been building had quite a short timeline, I've just been creating "a

It is a shame that so few React-based libraries are on DefinitelyTyped. As the project I've been building had quite a short timeline, I've just been creating "any" type definitions for libraries which don't have definitions (in an ideal world, I'd like to create and share a proper definition), which works but you lose type safety and auto-complete for these libraries. Not the end of the world but it allows more runtime errors to creep in. On the Flow vs Typescript thing, I evaluated both for this project, and almost went with Flow primarily because at the time, I liked that Flow felt lighter weight (it is truly "opt in" unlike TS, and getting the TS setup right was quite hard work), and I was also put off by the overhead of having to write .d.ts files (now I can create an "any" definition for a library in a few seconds, but at the time found it all quite time consuming). However, I persevered with Typescript in the end, as I felt that some of the features it offered over Flow were worth the extra effort - specifically, the editor/IDE support (Atom with Nuclide for Flow was really unstable for me and the autocomplete still didn't compare to TS) and the fact that Typescript does a full compile of your code, so will pick up on things like mis-spelled imports, which Flow didn't seem to. Also, I found documentation for Flow (beyond the basics) to be quite lacking, and there didn't seem to be as much community around it - for example, I just couldn't work out how to get it to check React propTypes, which was a pretty important feature for me. Bit of a shame, as its type system actually seems more fully featured than Typescript's (e.g. types are non-nullable by default), but TS's type system is certainly good enough. I'd say go Typescript at the minute if it's a reasonably large greenfield project, but Flow might suit your needs if it's something smaller (whether that's in amount of code or in team size), or if you prefer the lighter touch/opt-in approach - for example, if you want to introduce it to an existing JS code base. I would definitely say it is worth the effort to go with one or the other, I'm not looking forward to going back to writing plain JS - having the compile stage makes refactoring in particular trivial, without the overhead of having to write loads of unit tests. In TS I'll refactor constantly as I go whereas in a large JS app, it's tempting to put off refactoring as you might miss somewhere and not know until it is QA tested (or the customer spots it is broken...).