7 ms·

What is the status of Flow in the JS ecosystem?

ssalka 8y ago
Everyone I know who uses it wishes they had gone with TypeScript. Anecdotal for sure, but I wouldn't be surprised if most Flow users felt this way - TS is winning in basically every way.
root_axis 8y ago
Flow offers a more sophisticated type system that is designed to express types that correspond with the sort of idioms you see in JavaScript in the wild. TypeScript is simpler and less flexible, but that simplicity can translate into increased productivity since there are less foot-guns and also less bugs. Strange/buggy behavior and odd performances issues are not totally uncommon with Flow whereas TypeScript doesn't seem to suffer from this as much. Since TypeScript is much more popular, IDE support tends to be a lot better out of the box, but the flow-langauge-server gives you all the same IDE-like features (intelligent autocomplete, jump-to-def, module resolution etc). Personally, I like Flow more, and I also think its easier to integrate into an existing codebase (either as comment annotations or gradually via per-file flow comment header), but at the end of the day, not choosing TypeScript amounts to swimming against the current without much justification.
- paavohtl 8y ago
  >Flow offers a more sophisticated type system that is designed to express types that correspond with the sort of idioms you see in JavaScript in the wild. TypeScript is simpler and less flexible, but that simplicity can translate into increased productivity since there are less foot-guns and also less bugs. Source? That's the primary design principle behind TypeScript too. TypeScript's type system is powerful enough to practically do arbitrary type-level transformation of data structures, and even do some crazy recursive pure functional type level programming. The only things I'm missing from TypeScript are variadic generics (which can be emulated quite well with TS 3.0) and higher kinded types - and I don't think Flow supports them either.
  - root_axis 8y ago
    https://flow.org/en/docs/types/utilities/ https://flow.org/en/docs/types/utilities/ Most of that can't be achieved out of the box with TypeScript. TypeScript was designed as a language that would bridge the quality of life gap between es5 and more modern languages, Flow was designed exclusively as a type system for annotating standards compliant JS.
    - ng12 8y ago
      Not true, most of that can be done with TypeScript. $Values might be the only one missing.
      - WorldMaker 8y ago
        $Values should be possible with Typescript 3.0+ conditional infer types, presumably something very similar to the built-in ReturnType<T> conditional infer type. Untested and off the top my head but maybe something like: type Values<T> = T extends { [K keyof T]: infer R } ? R : any
        wyze 8y ago
        It works, just need to add `in` in-between `K` and `keyof`.
      - wyze 8y ago
        Looks like $Values can be written as follows in TypeScript: type Props = { age: number name: number } type Values = Props[keyof Props]
    - paavohtl 8y ago
      Are you aware the TypeScript has mapped types and conditional types[1]? The vast majority of Flow's type utils can be implemented in TypeScript, and many of them are included by default[2]. As far as I can tell all of Flow's utility types are compiler built-ins[3], but TypeScript's built-ins are declared using the type system itself (or are just natural parts of the syntax): type Keys<T> = keyof T type Values<T> = T[keyof T] type Readonly_<T> = Readonly<T> type Shape<T> = Partial<T> type NonMaybeType<T> = NonNullable<T> // Exact<T> cannot be implemented because TS doesn't have exact types as a separate concept, // It should be noted that object literals are exact by-default if there's a type annotation // Issue: https://github.com/Microsoft/TypeScript/issues/12936 type Diff<A, B> = Pick<A, Exclude<keyof A, keyof B>> // Rest<T> should be equal to Diff, because TS doesn't have exact types type ElementType<T, K extends keyof T> = T[K] // PropertyType in unnecessary, because T[K] works for everything // Note that this is variadic - "Args" is an array of arguments type Call<F, Args extends any[]> = F extends (...args: Args) => infer B ? B : never // This works for both objects and tuples. type ObjMap<T, F> = { [K in keyof T]: Call<F, [T[K]]> } // I couldn't figure out how to implement Class<T>, but you can access the type of a class instance with // typeof ClassName.prototype // $SuperType and $Subtype are not documented, so I can't try to replicate them. // TypeScript doesn't have existential types, but you can emulate them within the type system, or avoid them using e.g "infer" // Discussion and encoding https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331 I don't agree with your statement about TypeScript's design. Before ES6 TypeScript _was_ quite different from JS, but for the past 3 or 4 years it has followed modern JS very closely. The flavor of JS it supports is fully compliant with ES2018, and the ONLY feature with codegen impact it has in addition to modern JS and JSX are enums - which compile down to simple object literals. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Utility%20Types.md https://github.com/Microsoft/TypeScript-Handbook/blob/master... [3] https://github.com/facebook/flow/blob/cf03c08109014c4503a392705b7dacb7dd827a0b/src/typing/type_annotation.ml https://github.com/facebook/flow/blob/cf03c08109014c4503a392...
- ng12 8y ago
  Does Flow still run as a separate process? That is a non-starter for me.
  - root_axis 8y ago
    A separate process from what? The IDE? Why would that be a bad thing?
    - ng12 8y ago
      The last time I used Flow it was intended to be used a daemon constantly watching your code. This made it really difficult to use with tools like Webpack which are built for "atomic" operations like tsc.
- WorldMaker 8y ago
  > Personally, I like Flow more, and I also think its easier to integrate into an existing codebase (either as comment annotations or gradually via per-file flow comment header) For several versions now, Typescript also supports type annotations in JS comments and an allowJS mode for mixing TS and JS in the same project, or using only JS and JS comment type annotations.

Everyone I know who uses it wishes they had gone with TypeScript. Anecdotal for sure, but I wouldn't be surprised if most Flow users felt this way - TS is winning in basically every way.

root_axis 8y ago

Flow offers a more sophisticated type system that is designed to express types that correspond with the sort of idioms you see in JavaScript in the wild. TypeScript is simpler and less flexible, but that simplicity can translate into increased productivity since there are less foot-guns and also less bugs. Strange/buggy behavior and odd performances issues are not totally uncommon with Flow whereas TypeScript doesn't seem to suffer from this as much. Since TypeScript is much more popular, IDE support tends to be a lot better out of the box, but the flow-langauge-server gives you all the same IDE-like features (intelligent autocomplete, jump-to-def, module resolution etc). Personally, I like Flow more, and I also think its easier to integrate into an existing codebase (either as comment annotations or gradually via per-file flow comment header), but at the end of the day, not choosing TypeScript amounts to swimming against the current without much justification.

paavohtl 8y ago
>Flow offers a more sophisticated type system that is designed to express types that correspond with the sort of idioms you see in JavaScript in the wild. TypeScript is simpler and less flexible, but that simplicity can translate into increased productivity since there are less foot-guns and also less bugs. Source? That's the primary design principle behind TypeScript too. TypeScript's type system is powerful enough to practically do arbitrary type-level transformation of data structures, and even do some crazy recursive pure functional type level programming. The only things I'm missing from TypeScript are variadic generics (which can be emulated quite well with TS 3.0) and higher kinded types - and I don't think Flow supports them either.
- root_axis 8y ago
  https://flow.org/en/docs/types/utilities/ https://flow.org/en/docs/types/utilities/ Most of that can't be achieved out of the box with TypeScript. TypeScript was designed as a language that would bridge the quality of life gap between es5 and more modern languages, Flow was designed exclusively as a type system for annotating standards compliant JS.
  - ng12 8y ago
    Not true, most of that can be done with TypeScript. $Values might be the only one missing.
    - WorldMaker 8y ago
      $Values should be possible with Typescript 3.0+ conditional infer types, presumably something very similar to the built-in ReturnType<T> conditional infer type. Untested and off the top my head but maybe something like: type Values<T> = T extends { [K keyof T]: infer R } ? R : any
      - wyze 8y ago
        It works, just need to add `in` in-between `K` and `keyof`.
    - wyze 8y ago
      Looks like $Values can be written as follows in TypeScript: type Props = { age: number name: number } type Values = Props[keyof Props]
  - paavohtl 8y ago
    Are you aware the TypeScript has mapped types and conditional types[1]? The vast majority of Flow's type utils can be implemented in TypeScript, and many of them are included by default[2]. As far as I can tell all of Flow's utility types are compiler built-ins[3], but TypeScript's built-ins are declared using the type system itself (or are just natural parts of the syntax): type Keys<T> = keyof T type Values<T> = T[keyof T] type Readonly_<T> = Readonly<T> type Shape<T> = Partial<T> type NonMaybeType<T> = NonNullable<T> // Exact<T> cannot be implemented because TS doesn't have exact types as a separate concept, // It should be noted that object literals are exact by-default if there's a type annotation // Issue: https://github.com/Microsoft/TypeScript/issues/12936 type Diff<A, B> = Pick<A, Exclude<keyof A, keyof B>> // Rest<T> should be equal to Diff, because TS doesn't have exact types type ElementType<T, K extends keyof T> = T[K] // PropertyType in unnecessary, because T[K] works for everything // Note that this is variadic - "Args" is an array of arguments type Call<F, Args extends any[]> = F extends (...args: Args) => infer B ? B : never // This works for both objects and tuples. type ObjMap<T, F> = { [K in keyof T]: Call<F, [T[K]]> } // I couldn't figure out how to implement Class<T>, but you can access the type of a class instance with // typeof ClassName.prototype // $SuperType and $Subtype are not documented, so I can't try to replicate them. // TypeScript doesn't have existential types, but you can emulate them within the type system, or avoid them using e.g "infer" // Discussion and encoding https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331 I don't agree with your statement about TypeScript's design. Before ES6 TypeScript _was_ quite different from JS, but for the past 3 or 4 years it has followed modern JS very closely. The flavor of JS it supports is fully compliant with ES2018, and the ONLY feature with codegen impact it has in addition to modern JS and JSX are enums - which compile down to simple object literals. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Utility%20Types.md https://github.com/Microsoft/TypeScript-Handbook/blob/master... [3] https://github.com/facebook/flow/blob/cf03c08109014c4503a392705b7dacb7dd827a0b/src/typing/type_annotation.ml https://github.com/facebook/flow/blob/cf03c08109014c4503a392...
ng12 8y ago
Does Flow still run as a separate process? That is a non-starter for me.
- root_axis 8y ago
  A separate process from what? The IDE? Why would that be a bad thing?
  - ng12 8y ago
    The last time I used Flow it was intended to be used a daemon constantly watching your code. This made it really difficult to use with tools like Webpack which are built for "atomic" operations like tsc.
WorldMaker 8y ago
> Personally, I like Flow more, and I also think its easier to integrate into an existing codebase (either as comment annotations or gradually via per-file flow comment header) For several versions now, Typescript also supports type annotations in JS comments and an allowJS mode for mixing TS and JS in the same project, or using only JS and JS comment type annotations.