I've also created a fairly comprehensive zero to nuts TypeScript + Redux tutorial that could be added to this list at:
I'd say go with TypeScript if you're looking for a type system closer to C# or Java (including extensive OOP features), and go with Flow if you're looking for a type system closer to F# or Scala (including things like type inference and disjoint unions), although Flow supports ES6 classes, too. In my opinion, the Flow approach is a more natural fit for JavaScript.
That's not to say that either project can actually achieve the coherence and completeness of any language designed to be statically-typed from the start, but those are kind of the the type system ideals that each project seems to lean toward.
Also, Flow is fully integrated into the React ecosystem, since it's built by Facebook. TypeScript can work with React, too, but TypeScript also tries to give first-class support to many other frameworks.
TypeScript is undoubtedly the more mature of the two projects (Flow is much newer), but I'm very happy that both exist since they're taking pretty difference approaches to the "JS problem".
I also wouldn't say TypeScript strives to focus on OO features - we try to be a type system that works well for JavaScript programming as it exists, while paving the way for the future. We don't even use classes in the compiler!
Also like you mentioned, we try hard to work well with many other frameworks and I think that will show. Angular 2, Dojo, Ionic, RxJS, and others are even written in TypeScript and provide a pretty great experience.
If you mean give TypeScript a try, I have! In production. And it was very solid. I haven't yet tried the JSX tooling, since that's a somewhat recent development and predates my last serious use of TypeScript.
> I also wouldn't say TypeScript strives to focus on OO features
Every single tutorial and howto I've ever read for TypeScript, official or otherwise, has emphasized the OO capabilities of TypeScript. And for good reason, TypeScript adds multiple OO features, and features associated with OO languages like Java and C#. I've heard more than one C# dev say that it feels almost like programming in C#. So I don't think I'm off base here.
That said, it's great that you're looking to emphasize your support for more traditional/idiomatic JS as well, as well as your support for React. (and I admit I'm surprised you don't use any classes in the compiler. Every TypeScript project of significant size I've ever seen uses lots of OOP. But I'm sure you're aware of many that don't.)
I do wish that TypeScript had disjoint union/sum types like Flow does, but I just checked and it looks like you might be seriously considering it! That's great.
Actually, it looks like you're getting closer to the behavior I'd like with your recent string literal type PR. If you add some nice to use type guards, I could program in TypeScript in somewhat approximating the style I've come to love with Rust/Ocaml/Elm/Scala.
There's no way you could encode exhaustivity checks to that, is there? I'm pretty sure that would require true disjoint unions, right?
In any case, I'll have to take another look at TypeScript, I'm glad to see you're pushing things forward. I'll keep my fingers crossed that you'll end up adding disjoint unions as well.
TypeScript + JSPM really provides a nice productive and enjoyable dev experience vs regular ES5 - it's definitely my choice power combo going forward.
We could drop hot reload but it is occasionally nice
The TypeScript tools for Visual Studio automatically regenerates the .js file every time you save its TypeScript file so it works statically without needing any background process to monitor for changes. So my JSPM doesn't know about TypeScript, it's just loading the pre-generated .js files every time I hit refresh.
If you've configured React Routing and are saving/reloading Redux state in localStorage on change it's a pretty good dev experience as most of the time a refresh brings you back to where you left off.