Flow vs. Typescript

No matter which one you go with if you're project is going to live for any decent length of time please use one of these. Typed Javascript plugs many holes in the language and there is a qualitative positive difference in productivity.

Just go with one of them. Seriously.

I haven't used Flow (we actually couldn't get it to work with our build system in a few days and gave up, because TypeScript was easy). We integrated replaced Babel with TypeScript in about one day, and ported the entire codebase from ES6 to TS in about two or three days. The code looks almost identical except for the type annotations, which we were documenting in comments anyway. Also, you can pretty much switch right back to Babel if you want, since Babel will ignore type annotations.

Editor support for TS is amazing. Both Atom and VS Code have great autocompletion and live typechecking as you edit.

Build times with TS are okay. Our codebase rebuilds with ts-loader in webpack within something like 4 seconds upon saving. I'd prefer half a second of course.

We have had no problem using any existing JS code. You can provide type annotations or not, but you don't have to. We use React, moment.js, underscore, jQuery. All the major libraries have type bindings. We also use some internal CoffeeScript libraries and occasionally bother providing type bindings, but usually not.

In short, TypeScript is great and if you're going to adopt ES6 you might as well adopt TypeScript too.

> Flow or TS being opinionated

Neither is opinionated. They have some pretty uncontroversial (similar to other popular languages) typing on top of JS, and it's all opt-in. If there's something you don't like, you don't have to use it.

> and their impact on an established toolchain?

I don't know about Flow, but TypeScript is very easy to integrate into an existing chain. If you're using something like Gulp, there is a pure JS library that you can call to transpile your TS into JS. If you use Babel, you can simply insert the TS->JS transpilation before you call Babel.

TypeScript has an executable called tsc that you can use to transpile your TS whenever the file is changed. You can use that, and then your tool chain doesn't even have to change at all. (Automatic TypeScript transpilation is built into WebStorm and easy to add to VS Code.)

> I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms.

In my limited experience, TS is much more polished than Flow is. The tooling is mature, debugging works well, and the language is rapidly improved. It's not just MS using it -- Google also uses it, and some other larger companies.

> A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools?

Anything (and I mean anything) you do with JS, you can also do with TS. It's a superset of JS and compiles to readable, idiomatic JS.

> Are there properly working code formatters for both?

WebStorm has mature formatting for TS, but there's also tslint if you want some additional error-checking. WebStorm has first-class support for TS, including integration with tslint.

> What about editor support (Sublime)?

No idea about Sublime, but WebStorm support is absolutely fantastic. Excellent debugging, hints, linting, and completion. VS Code is great, but it lacks some of the more niche-y features of the IntelliJ platform. Some people might not care, and VS Code will do everything they want.

> no messing around in a different but similar language

TypeScript would be a disaster if it subtly changed the semantics of JavaScript. It doesn't, though. It's a superset, so it's really not a "different but similar" language. It's the same language with more features, and the compiler is a great guide to using those features.