I'm about halfway through migrating a ~30kloc ES5 codebase to ES6 with a transpiler (Babel), linter (ESLint), and fast test suite (Mocha) [1]. Once all files are going through the transpiler I'll probably add TypeScript or Flow. We already had RequireJS in place so the conversion from AMD to ES6 module format has been pretty straightforward, but I'm continually amazed with every file I convert I usually find a couple real bugs with the linter. The most common have been:
* Undefined variables referenced in a seldom-traveled conditional branch.
* Leaked globals due to missing `var` keyword.
Every bug I find is immediate feedback that this is a worthwhile use of our time.
I can't recommend flow highly enough for gradually typing existing code (as it requires far fewer code changes than TypeScript). Not sure what your timelines are like, but it takes no time at all to set flow up, and you might find it makes the task of migrating a little more varied.
The main blocker and main reason why I don't recommend flow when entering a new team, is that they don't provide windows binaries: https://github.com/facebook/flow/issues/6
The fact that I can add TypeScript to any project's workflow by simply `npm install --save-dev typescript typings` is a massive advantage. The tooling around typescript is much better as well (typings + definitely typed for example). With TypeScript 2.0, I'm not sure I'll have any reason to use Flow anymore...
I think the main differences are in the type engines. From what I have seen, Flow can infer much more informations about a program, even on unannotated JavaScript. As a result, with the same amount of annotations, it seems to me that you can find more bugs using Flow than using TypeScript.
TypeScript recently added an allowJS mode which makes it much easier to convert JS to TS a file at a time and Typescript will infer what it can from the unannotated JS files. From what I hear it's not quite as much as Flow picks up, but it is getting better, especially because it's also doing double duty as the new JS IntelliSense language service (codename "Salsa") for VS Code and intended to eventually replace Visual Studio's IntelliSense language service for JS as well.
I find typescript pays off with the excellent intellisense and refactoring in editor support. They did a great job of having the language service and compiler use same core code base.
I'm working on a babel plugin [1] that should make the migration even more gradual. At the end of the process you get both static and runtime type safety.
I have tried to use it ~6 months ago and the tooling felt kind-of wonky and I didn't feel like maintaining the interface files if so much of it seemed to be in flux.
Based on a quick play recently, I'd say still slightly wonky. Nuclide has improved a lot but autocomplete etc. is noticeably sluggish compared to the atom-typescript plugin. On my travel 12" Macbook, Atom with Nuclide it's too slow to comfortably use and the Sublime plugin for Flow seems to be quite buggy, whereas the Sublime TS plugin is pretty solid.
In terms of type definitions available for third party libraries, Typescript is way ahead. I also think the documentation and community around Typescript is stronger, and will only get more so with the move to use TS as the default in Angular 2. Also the stability is great and the roadmap looks promising.
Nothing against Flow, I think it is great and definitely has some advantages (and anything which adds types to JS is a winner in my book!), but it feels slightly more like an internal Facebook tool that happens to be released to the public versus Typescript, which is more of a release quality product.
But yeah, either is great improvement over plain JS and I'd definitely consider Flow for a personal project, but in a bigger company/team environment I think the stability, tooling and community of Typescript would make me push for that.
Works for me! Some of the non-affiliated tooling (e.g. the Sublime Linter plugin) can be a little difficult to use, but the command-line tool is pretty clear.
Refining the .flowconfig so it worked universally also took a bit of time, but that's more due to our very large codebase than flow.
I'm working on a real time (as you type) JS static analyzer witch will hopefully detect these errors. So I'm interested in what sort of bugs is common.
I believe that types don't belong in a high level programming language like JS, where the JS engine decides the best type to use and optimize things like string concatenation. A good static analyzer and tests should cover most of the advantages of a strictly typed compiled language.
Don't confuse types with the implementation. Regardless of how the string concatenation works, you'll still need to make sure that you get something that sort of looks and behaves like a string. That's where the static typing comes in.
It's in an early stage and doesn't do much ATM that can't be accomplished with something like "Tern". If you drop your e-mail in your profile, I'll send you a link when I got something to show.
We're using a variant of Airbnb's config, it disallows `var` in favor of `let` or `const`. We're a Java shop and people get tripped up by hoisting issues pretty often.
* Undefined variables referenced in a seldom-traveled conditional branch.
* Leaked globals due to missing `var` keyword.
Every bug I find is immediate feedback that this is a worthwhile use of our time.
[1] https://medium.com/@kevanahlquist/evolution-of-javascript-at...