3 ms·
I remember doing a head to head comparison between Flow and Typescript back in 2015 or sometime around then, and flow came out top at the time. Main pull for fl
by a_humean 4y ago
I remember doing a head to head comparison between Flow and Typescript back in 2015 or sometime around then, and flow came out top at the time. Main pull for flow for me was strict null checking and disjoint unions, which typescript lacked at the time.
About a year later typescript got strict null checks and discriminated unions, and from that point on typescript just kept improving, the community type defintiions kept getting better, and flow felt like it was stagnating and had lots of performance issues (esp on windows machines).
Flow actually still has a few notable features that typescript still lacks but are often asked for. For example, flow as `Exact` types that ensures that an object doesn't have excess properties throughout its lifetime - ergonomics are a bit awkward though.
- WorldMaker 4y agoTypescript in strict mode doesn't allow excess properties in an increasing number of situations. Typescript is still more structurally typed than nominally typed so there's no easy way to opt-in a specific type to stronger checks than average. The ergonomics are obviously different between Typescript and Flow. There are existing practical workarounds today to get more "nominally exact" types in Typescript such as using "brands" of various sorts (the most common is adding a private unique symbol to a type), though the ergonomics of using such branded types is also its own sort of awkward.
- a_humean 4y agoThose excessive property checks are pretty limited to basically the construction of object literals, and it does it because its normally an error if you have a very explict type but your literal expression doesn't match it. Typescript really does nothing to enforce anything around excess properties except for that narrow case. Branding doesn't really enforce anything except what the user asserts is the case. Its not the same thing.