| I started a core company project without types, than soon added Flow, then migrated to TypeScript. I was very active, learned a lot of the intricacies and a lot of advanced typing with Flow, did lots and lots of experimenting to cover edges. I also was very active in the "issues" section of the Github-Flow repo, reading, answering and also posting issues. I kept track of where TypeScript was though, occasionally posting issues there too. When it looked like they had feature and strictness parity, especially the latter, I switched over though. Reasons: - Flow was on a downward path, TS on an upward path. Already nr. of developers and the ecosystem was far greater for TS. - The Flow team was almost completely absent in the Github repo. There were some Facebook people but some of the active ones were not even from the Flow team. In contrast, the 2nd issue I wrote for TypeScript had a response from Anders Hejlsberg (TS inventor) himself, and his responses to issues can be found all over the place. Also, the Flow team's focus seemed to be almost completely supporting the internal use of Flow. It actually was a valid "open source" use case: "We write something for ourselves, here is the source in case you find it valuable.". Keyword being "ourselves", they did not care too much what other people wanted/needed unless it fit into their existing plans. TS was the complete opposite, it was written for others right from the start. - We have a team with quite a lot of new (out of university) developers, most of them in another country (Eastern Europe) and not our own employees. Everybody but me was very reluctant to go with Flow (I had added it to the core library, they wrote apps using it, so they did not have to use it). TypeScript adoption was much easier, also for those who don't see themselves working on our projects "forever", because it clearly is a much more valuable skill then Flow in the JS-developer market. - Strictness still was a bit more in Flow but the difference was insignificant by then. - On the other hand, I actually removed lots of (inline) type annotations, concentrating on the types only in the function headers and when TypeScript could not auto-detect it (e.g. "new Map()" - what is the key type, what is the value type?). I followed what seemed to be the preferred TS style for type annotations. I hardly gave anything up in terms of strictness, but had far less "type stuff" in the code. Okay, this is not so much "Flow vs TS" but my own choices. In TS it's actually better to have less inline types (when auto-detection works), because while Flow - after I had filed an issue that was implemented - raises an error every time there is a discrepancy between an auto-detected type and a type annotation TS silently uses the type annotation in some contexts and does not complain when it is different from the auto-detected type. That sounds worse but if there is no type annotation it's fine, so I decided to go with it and not file an issue to ask for a change. - Probably one of the most well-known TS advantages: Far better support, via the DefinitelyTyped repo, for types for all kinds of external libraries. - When converting some very complicated "dynamic" types from Flow to TS the TS version was FAR easier to write. Especially conditional types help a lot. Don't know if Flow has something like that by now, it didn't when I made the switch. As for "why types at all" raised here: I happily wrote JS code without them since JS was invented (even though I wasn't what today would be a full-time JS developer, that happened only the last five years, and also used all kinds of other languages). Especially the last ten years a number of large corporate projects too. I switched to types because, as somebody wrote here, types are there anyway, whether I annotate them or not. All input and all return values have a type even if I write plain JS. ----
Just an aside: I chose Flow at first because of - at the time - greater strictness, but mostly because it was plain JS plus JS types. TypeScript sounded like it was its own language. IT IS NOT! It took a while until I actually checked what it really is - the self-marketing is really bad in this respect. Unfortunately they bundle the "Babel" ("compilation", code transformation) aspect and the types, even though they are completely orthogonal. Apart from (unnecessary) namespaces and enums, both old features for which different pure JS (or TS-type) options exist now, TypeScript actually is 100% pure ESnext. If you strip all the type annotations and don't rewrite anything you are left with pure ECMAScript. Until they added namespace support the Babel plugin for TypeScript was very small and all it did was the same as the Babel Flow plugin: Just strip all the type stuff. No code rewriting took place. That's why until recently namespaces and enums where not supported by the Babel plugin, but those are features one can easily live without (Note: pure TS type namespaces in declaration files and as part of the types, and not of the JS code, can of course be used; I'm talking about the namespaces that are in "JS code space").
---- The great benefits of TS (first of Flow) for us: - IDE live coding help and support. If I see some function, and I encounter this a lot in 3rd party code, I often have to go to the source code to see what it#s actually doing with those parameters to understand what I have to pass in. - "Tracks" for other developers that reign in their fantasy and creativity. The types force them to stay on track with how they use some API functions of the library. That's even more important with new people. Of course, if the project is not too big and the same people have been working on it since the beginning, and very few team changes, then it matters less. - Greatly helps refactoring and rewrites. |