Hacker News Reader

Comment by muglug | Hacker News Reader

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.

View on HN

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 disagree. In terms of changing code, TypeScript and Flow are similar (you're just gradually adding metadata).

The differences are in tooling.

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.

[1] https://github.com/gcanti/babel-plugin-tcomb

How does flow stand now?

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.

Reply on news.ycombinator.com