4 ms·
I've done some average sized projects in Flow and in TypeScript, and it's a lot more subtle IMO than most people would have it (especially people who only tried
by shados 10y ago
I've done some average sized projects in Flow and in TypeScript, and it's a lot more subtle IMO than most people would have it (especially people who only tried one, or only tried both cursively)
TypeScript absolutely has the better tooling. It's not even -close-. It's a little tricky though because a lot of FE devs these days use VIM or Sublime with a few plugins and a linter running in a terminal is as far as it goes, so explaining the importance of proper refactoring tool and semantic search is tough (no, using grep/ag/ack is not enough in a large code base, no matter how good you are with them).
On the other hand, the Flow checker is a lot more interesting, with more advanced call site analysis, and the type inference follows types a lot further (where you can type an entire file without any annotations, though Flow does require them on exports if you want imports in other files to be typed). That means functions with no annotations are much more frequently type checked and it's more useful during prototyping.
Flow is also a bit more careful about putting on the C#/Java lipstick (neither Flow nor TypeScript are actually java/C#-like, being much more functional and using structural typing as first class citizens, but TypeScript definitely LOOK the part to the untrained eyes, which makes developers used with those languages try to use the same patterns and heavily abuse classes instead of union types, etc. In Flow it's less of an issue).
Flow definitely causes a lot more surprises: call site analysis means error messages can be more confusing, and certain cases like inaccessible code path can cause some surprising scenarios.
flow-typed has many less type definitions, but they're generally higher quality. TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. You also have issues with useStrictNull not having been there all along causing problems. TypeScript however benefits heavily from having more libraries being native TypeScript, which is better than having good type definitions.
Finally, while TypeScript's tooling is vastly superior, Flow has the benefit of being parsable by Babel via Babylon, making large parts of the ecosystem a lot more Flow friendly. This came up recently with the amazing Prettier project being a non-starter for TypeScript users.
I've been hopping between vanilla JS, Flow and TypeScript continually...and no matter which one I use, I wish I was using another.
- anonova 10y ago> TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. I've always found it funny that DefinitelyTyped's tag line is "The repository for high quality TypeScript type definitions", but it's an absolutely disastrous system. If it's not a well-used library, definitions there will be woefully out of date. Versioning is a huge issue with it, so it's hard to figure out what definitions actually match the version library you're using. I can only admit that it's an effort that's better than nothing. The few projects I added types to, the original project owners gladly accepted them into their main repos, which is great since types will "just work" without fuddling with @types packages.
- WorldMaker 10y agoI too feel that as a types contributor I've mostly given up on trying to contribute to DefinitelyTyped and try to contribute directly to library authors. I also think that DT has grown far too big and far too hard to contribute to, especially for fixes to types to small, lesser used libraries.