[celestialjeu]

Have you used flow at all in the past? If so what would you say the major differences are/how difficult was any process to convert over? I'm a huge fan of having the types defined just from a documentation perspective nevermind bug catching and debugging and all that. I feel relatively agnostic about the particular thing we use to do it so I'm curious as to what the differences are.

But yeah it really has improved my day to day immensely and I really feel the difference when I'm working in legacy portions of our apps that pre-date the flow adoption.

[jameslk]

I have used both TypeScript (for multiple projects) and Flow (at Facebook). TypeScript is much more feature-rich and looser in strictness. In practice, this looseness has been preferable, as I've seen many of my colleagues fighting Flow's type system vs TypeScript (prior to FB). In theory, perhaps Flow's type system prevents more bugs, but I've sometimes seen it circumvented with hacks just to get past its strictness. TypeScript's ability to infer types seems much smarter than Flow's as well.

Besides that, TypeScript has much wider adoption and community support. Most issues I have with TypeScript I can find others who have had similar issues on the web, where as I can't say the same about Flow.

[lhorie]

There's been a lot of doubt cast on Flow outside of Facebook when Jest announced it was moving to TS.

I'm curious to hear how Typescript vs Flow discussions go within Facebook, and what engineers there think of each.

[ajbogh]

I would also like to know how many projects within Facebook, if any, use Typescript. I'd be interested in the growth rate as well (how many projects over time).

[_robbywashere]

I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript.

So I would say if you're interested pick one and dive in.

Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped

And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor)

Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?...

This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.

[AgentME]

I've used Flow very heavily and TypeScript a reasonable amount. They're pretty similar really, but I'd recommend TypeScript for its better tooling and larger available set of type definitions.

Flow doesn't seem to be built with the (non-Facebook) developer experience in mind. It very frequently has breaking changes. The tooling is worse. There's no good official way to publish a package to npm with Flow type definitions included. Its alternative to DefinitelyTyped requires using their own CLI tool instead of copying DefinitelyTyped's simple npm-based strategy.

There a few things Flow does better. Functions internal to a file often don't need their parameters to be typed because Flow infers their types, but honestly I don't think that's a very killer feature. I often type them anyway just to be explicit. Flow does model type variance better (a Promise<{a:string,b:string}> can be cast to Promise<{a:string}>, but not vice versa, and you can't do the same with mutable arrays, etc.) but variance doesn't come up often and you can always use the any-type escape hatch in TypeScript to make it through those uncommon situations. I do hope TypeScript gets better about that though.

Flow isn't bad; a Flow codebase is still much better than an untyped Javascript codebase. But if you're starting a new project and have the choice, pick TypeScript.

[williamdclt]

Agree on 100% of this.

Also errors in Flow are often very esoteric. The "smarter inference" sometimes made type errors appear in the callee rather than the caller (having an error on React's component type definition is not helpful). The wording isn't user-friendly if you're not familiar with typing theory.

Inference is not that much of a killer feature I feel: I don't want the type to be inferred based on how I use a variable, I want to check that I don't misuse the variable based on its type. Obviously there's use for inference too, but in the general case...

[chrisweekly]

Also, if you're looking to introduce types to an extant Javascript project, there's a good chance you're already using babel. That used to be a (slight) point in flow's favor, but as of Babel 7, you can opt to have Babel transpile your TypeScript. Not that there's anything wrong with tsc. :)

[ng12]

Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.

[AgentME]

Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.

[ng12]

> The Flow daemon executable was just to provide type checking.

This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.

[AgentME]

I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.

[ng12]

Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.

[williamdclt]

Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")

[AgentME]

I don't really feel strongly about it, though sometimes Flow takes 10+ seconds to re-check a large project I work on after changes, and I wouldn't want building to have to wait on that. (I've never worked on a similarly-sized project in TypeScript, but I expect it's about the same situation.) I usually use a CI system (CircleCI) which sends me an email if any of my commits don't pass type checking or unit tests, and it flags any PRs on Github that fail too.

[root_axis]

Only in CI, not during development. IDE warnings are enough.

[4lejandrito]

I found this post quite interesting. These guys migrated a big codebase from flow to typescript. https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...

[PhineasRex]

I've deployed flow extensively and the biggest difference is that flow is horribly buggy (lots of false negatives) while typescript is mature. In theory flow's type system is stronger but it's so unreliable that 99% of the time I'd rather use typescript.

[fibo]

The main issue I found with flow is importing type packages.