I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase.<p>Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fast-moving, with bugs fixed and features added at a high rate, and the quality of discussion on the issue tracker is high. Flow, in comparison, was not evolving as fast.<p>Flow touts global inference, which I think means better types when you don't necessarily have annotations on module boundaries, but I mostly care about what's possible in a greenfield or well-annotated codebase.<p>Flow deserves a ton of credit, and Microsoft probably studied it in detail, but I think the advantages are overblown at this point. Take the soundness thing. TypeScript added null-strictness a while ago, and recently they improved function type polymorphism. The reality is that both type systems have limits and you sometimes need to type something imperfectly or use an escape valve ("any"). In most cases, however, TypeScript gives you more sophisticated tools to construct the types you want, so you actually get better types. Maybe TypeScript lacks a theoretical underpinning for soundness, but there's no reason it can't continue to get "more and more sound," with it harder and harder to find good examples of unsoundness.
Flow capitalizes on its soundness, but its not as useful when the error messages are so cryptic. We tried adopting Flow at a company I worked at, but dealing with gibberish errors and the huge meaningless stack traces was a productivity sink.<p>We migrated to Typescript. Error messages are more understandable and unlike flow include line numbers and the column. Add huge number of typings, and ts definitely wins.<p>There are many gripes we've had with typescript too, but at least we didn't spend hours trying to understand error messages.
I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly laid to rest with the introduction of the official ES modules spec (at least from the perspective of the application developer when it comes to module code they actually write), and I'm hoping an official type annotation spec can do the same for the JS static type checking landscape.<p>Flow has already long-since demonstrated that it's perfectly possible to introduce useful type annotations to JS code without changing any runtime behavior whatsoever, and Flow and TypeScript have mostly converged on similar syntax and semantics when it comes to the type annotations. Given all this, I'd have thought that the standardization process would be pretty far along by now. Maybe someone more familiar with these matters can offer some insight on the seeming lack of progress?
I thought this was a new thing, but it turns out it's facebook's flow. <a href="https://flow.org" rel="nofollow">https://flow.org</a>
Both flow and typescript are great tools. Typescript has much better tooling and great IDE integration, using typescript is a no-brainer for new projects. Flow's soundness does shine though once your codebase (and your team) becomes very big, as any unsafe cast can be reliably treated as error. I use flow at work, and so far my experience is that unsafe cast in flow always indicates a bad design or actual bug.
I've always wondered if you could let the engine do the type checking or create type definition files for you, maybe an optional v8 flag?<p>This would be best case scenario so we could get rid of the tedious work that one has to put in to make an older library have type checking.