3 ms·

Isn't typescript better than flow? In what ways is flow better?

0xfffafaCrash 4y ago
Yeah, TS isn’t just better than Flow. It’s vastly better in almost any way one can think of. One of the few cases where the answer isn’t even “it depends.” I have to imagine swyx is either trolling here or has some very special contrarian opinion to almost anyone who has used these two technologies.
xwx 4y ago
The main advantage Flow has over Typescript is soundness. Neither language is sound, but Flow tries a bit harder, and so there are fewer cases where you write bugs that 'should' be caught by the type checker. Here are a few examples of unsoundness in TS: https://www.typescriptlang.org/play?strictFunctionTypes=false#example/soundness https://www.typescriptlang.org/play?strictFunctionTypes=fals... https://flow.org/en/docs/lang/types-and-expressions/#toc-soundness-and-completeness https://flow.org/en/docs/lang/types-and-expressions/#toc-sou...
sequoia 4y ago
Flow is not better than typescript. People who say it’s “better”, what they mean is it’s more strict, which really means more rigid. The rigidity is a complete pain in the ass that’s not well suited to web UI development and leads to all kinds of convolution. To take one example: I use a Graphql to flow type generator for query fragment. That tool generates inexact types. So I’ll end up with an array of values of this type from a Graphql query, data objects with 10 keys for example. Then I want to pass this to a charting library, but I need to add a “color” property to each data object for the charting library. This is not possible with flow. My options are: - create a new type with color property and spread the existing type: this is not possible because the existing type is inexact and I have no way to convince flow it doesn’t already have a color property - just add a color property: this won’t work because I get a flow error later when I try to read the property, plus I don’t get the type check I’d like - create a new type plucking every other field from the existing type 1x1, then create a mapping function moving every property to the new type 1x1 - use $FlowFixMe to disable type checking altogether The only options that work are the last two, and they either break typing altogether or require dozens of additional lines of code that serve no purpose but satisfying Flow. And or course you need a comment to explain why the hell you’re mapping properties over one by one. I don’t need a type system that’s this “correct.” I’m not writing mathematical proofs, I’m writing web UIs, and this level of rigidity just gets in the way and leads to weird, overly verbose code.

Yeah, TS isn’t just better than Flow. It’s vastly better in almost any way one can think of. One of the few cases where the answer isn’t even “it depends.” I have to imagine swyx is either trolling here or has some very special contrarian opinion to almost anyone who has used these two technologies.

xwx 4y ago

The main advantage Flow has over Typescript is soundness. Neither language is sound, but Flow tries a bit harder, and so there are fewer cases where you write bugs that 'should' be caught by the type checker. Here are a few examples of unsoundness in TS: https://www.typescriptlang.org/play?strictFunctionTypes=false#example/soundness https://www.typescriptlang.org/play?strictFunctionTypes=fals... https://flow.org/en/docs/lang/types-and-expressions/#toc-soundness-and-completeness https://flow.org/en/docs/lang/types-and-expressions/#toc-sou...

sequoia 4y ago

Flow is not better than typescript. People who say it’s “better”, what they mean is it’s more strict, which really means more rigid. The rigidity is a complete pain in the ass that’s not well suited to web UI development and leads to all kinds of convolution. To take one example: I use a Graphql to flow type generator for query fragment. That tool generates inexact types. So I’ll end up with an array of values of this type from a Graphql query, data objects with 10 keys for example. Then I want to pass this to a charting library, but I need to add a “color” property to each data object for the charting library. This is not possible with flow. My options are: - create a new type with color property and spread the existing type: this is not possible because the existing type is inexact and I have no way to convince flow it doesn’t already have a color property - just add a color property: this won’t work because I get a flow error later when I try to read the property, plus I don’t get the type check I’d like - create a new type plucking every other field from the existing type 1x1, then create a mapping function moving every property to the new type 1x1 - use $FlowFixMe to disable type checking altogether The only options that work are the last two, and they either break typing altogether or require dozens of additional lines of code that serve no purpose but satisfying Flow. And or course you need a comment to explain why the hell you’re mapping properties over one by one. I don’t need a type system that’s this “correct.” I’m not writing mathematical proofs, I’m writing web UIs, and this level of rigidity just gets in the way and leads to weird, overly verbose code.