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.
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.
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.
I'm curious to hear how Typescript vs Flow discussions go within Facebook, and what engineers there think of each.
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.
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.
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...
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.