3 ms·

I haven't tried Flow. But there were a couple of practical things that influenced my decision when choosing between Flow and TypeScript: * TypeScript has large

by ash 10y ago

I haven't tried Flow. But there were a couple of practical things that influenced my decision when choosing between Flow and TypeScript: * TypeScript has larger community. * Flow requires Babel. TypeScript doesn't. One less dependency to worry about. And in my experience TypeScript compiler produces better JavaScript than Babel. * Flow is written in OCaml. It could probably make it more difficult to install than TypeScript. P.S. React works fine with TypeScript. I haven't played with React Native though.

nathan_f77 10y ago
* TypeScript has larger community. That's a very good reason. I wish there were more community-provided types for flow. I think Immutable.js has only just fixed the last issues, but that's really been bugging me for the last few months. ("no default export" and "isEquals".) * Flow requires Babel. Not a huge deal for me, since React Native already requires Babel, and I personally like working with Babel. I use a number of Babel plugins, such as "transform-decorators-legacy" and "module-resolver". * Flow is written in OCaml. It could probably make it more difficult to install than TypeScript. Not at all, installation was very quick and easy. You can use either npm or Homebrew.
- ash 10y ago
  > React Native already requires Babel. Could you elaborate on that please? Is it impossible to skip Babel when using React Native? > Not at all. Installation is very fast and easy. (Last time I checked Flow npm package gives you binaries.) I'm sure Flow installs fine in "standard" environments, like an OSX laptop. I was thinking about more weird places, like CI servers where you can't fully control the environment. I was burned enough about stuff like that in the past.
  - nathan_f77 10y ago
    Ah, I see. Well, I'm sure it's common enough that you would have no problems getting it running on CircleCI and TravisCI. Here's the only issue I found, which is now closed: https://github.com/flowtype/flow-typed/issues/247 https://github.com/flowtype/flow-typed/issues/247
    - ash 10y ago
      Sure! I'll just note there are more CI systems than CircleCI and TravisCI. Especially on premise and on older distros.
  - nathan_f77 10y ago
    > Could you elaborate on that please? Is it impossible to skip Babel when using React Native? Yes, the React Native packager depends on Babel, and uses a react-native preset. When you start a new project, you get this default .babelrc: { "presets": [ "react-native-stage-0" ] } They basically wrote their own version of webpack, to solve some performance problems and make development as fast as possible.
- denisw 10y ago
  > I wish there were more community-provided types for flow. One technical limitation that complicate contributions to the flow-typed repository is that there is no way of writing typings that depend on other libraries' types [1]. For instance, flow-typed has a library definition for `rxjs`, but it is not possible to e.g. add a definition for `redux-observable` that reuses the RxJS `Observable<T>` type, because there is no way to express that the typings of `redux-observable` neeed the ones of `rxjs` to function. So typings for such closely related libraries tend to not exist in flow-typed. To work around this problem, some libraries like styled-components require you to manually include the library definition files it requires in your `.flowconfig` [2], but this is a rather hacky workaround. [1]: https://github.com/flowtype/flow-typed/issues/16 https://github.com/flowtype/flow-typed/issues/16 [2]: https://github.com/styled-components/styled-components/blob/master/docs/flow-support.md https://github.com/styled-components/styled-components/blob/...
  - nathan_f77 10y ago
    Oh, that's a shame. I've spent the last few hours reading up on RxJS, and I just finished watching this talk on redux-observable [1], so I'm totally ready to dive in and rewrite some parts of my app. I was actually about to rewrite it with redux-saga, but I've decided that redux-observable and RxJS is far more awesome. So are you saying that there are no flow types for redux-observable? I guess that's not a deal-breaker, since flow-typed will just generate stubs. Also, it looks like react-observable is a super high level abstraction, so I'm not even going to be writing that much code. [1] https://www.youtube.com/watch?v=AslncyG8whg&feature=youtu.be https://www.youtube.com/watch?v=AslncyG8whg&feature=youtu.be
whatever_dude 10y ago
My $0.02, as someone who loves TS: > TypeScript has larger community. It kind of depends. In some circles Flow is bigger. Mind that it is heavily entrenched in everything Facebook does, so it's treated as a built-in, first-class citizen in many circles (e.g. React Native). > Flow requires Babel. TypeScript doesn't. I'm not sure I agree. Objectively, depending on the kind of Flow you write, you don't really require any transpilation step. Plus, subjectively, using Babel with TypeScript should not be frowned upon - there's a lot of advantages that Babel can provide that are outside of the scope of what TypeScript tries to do. Personally I use it to provide shims (via babel-preset-env) so I can target older browsers based on version configurations.

by ash 10y ago

nathan_f77 10y ago

* TypeScript has larger community. That's a very good reason. I wish there were more community-provided types for flow. I think Immutable.js has only just fixed the last issues, but that's really been bugging me for the last few months. ("no default export" and "isEquals".) * Flow requires Babel. Not a huge deal for me, since React Native already requires Babel, and I personally like working with Babel. I use a number of Babel plugins, such as "transform-decorators-legacy" and "module-resolver". * Flow is written in OCaml. It could probably make it more difficult to install than TypeScript. Not at all, installation was very quick and easy. You can use either npm or Homebrew.

ash 10y ago
> React Native already requires Babel. Could you elaborate on that please? Is it impossible to skip Babel when using React Native? > Not at all. Installation is very fast and easy. (Last time I checked Flow npm package gives you binaries.) I'm sure Flow installs fine in "standard" environments, like an OSX laptop. I was thinking about more weird places, like CI servers where you can't fully control the environment. I was burned enough about stuff like that in the past.
- nathan_f77 10y ago
  Ah, I see. Well, I'm sure it's common enough that you would have no problems getting it running on CircleCI and TravisCI. Here's the only issue I found, which is now closed: https://github.com/flowtype/flow-typed/issues/247 https://github.com/flowtype/flow-typed/issues/247
  - ash 10y ago
    Sure! I'll just note there are more CI systems than CircleCI and TravisCI. Especially on premise and on older distros.
- nathan_f77 10y ago
  > Could you elaborate on that please? Is it impossible to skip Babel when using React Native? Yes, the React Native packager depends on Babel, and uses a react-native preset. When you start a new project, you get this default .babelrc: { "presets": [ "react-native-stage-0" ] } They basically wrote their own version of webpack, to solve some performance problems and make development as fast as possible.
denisw 10y ago
> I wish there were more community-provided types for flow. One technical limitation that complicate contributions to the flow-typed repository is that there is no way of writing typings that depend on other libraries' types [1]. For instance, flow-typed has a library definition for `rxjs`, but it is not possible to e.g. add a definition for `redux-observable` that reuses the RxJS `Observable<T>` type, because there is no way to express that the typings of `redux-observable` neeed the ones of `rxjs` to function. So typings for such closely related libraries tend to not exist in flow-typed. To work around this problem, some libraries like styled-components require you to manually include the library definition files it requires in your `.flowconfig` [2], but this is a rather hacky workaround. [1]: https://github.com/flowtype/flow-typed/issues/16 https://github.com/flowtype/flow-typed/issues/16 [2]: https://github.com/styled-components/styled-components/blob/master/docs/flow-support.md https://github.com/styled-components/styled-components/blob/...
- nathan_f77 10y ago
  Oh, that's a shame. I've spent the last few hours reading up on RxJS, and I just finished watching this talk on redux-observable [1], so I'm totally ready to dive in and rewrite some parts of my app. I was actually about to rewrite it with redux-saga, but I've decided that redux-observable and RxJS is far more awesome. So are you saying that there are no flow types for redux-observable? I guess that's not a deal-breaker, since flow-typed will just generate stubs. Also, it looks like react-observable is a super high level abstraction, so I'm not even going to be writing that much code. [1] https://www.youtube.com/watch?v=AslncyG8whg&feature=youtu.be https://www.youtube.com/watch?v=AslncyG8whg&feature=youtu.be

whatever_dude 10y ago

My $0.02, as someone who loves TS: > TypeScript has larger community. It kind of depends. In some circles Flow is bigger. Mind that it is heavily entrenched in everything Facebook does, so it's treated as a built-in, first-class citizen in many circles (e.g. React Native). > Flow requires Babel. TypeScript doesn't. I'm not sure I agree. Objectively, depending on the kind of Flow you write, you don't really require any transpilation step. Plus, subjectively, using Babel with TypeScript should not be frowned upon - there's a lot of advantages that Babel can provide that are outside of the scope of what TypeScript tries to do. Personally I use it to provide shims (via babel-preset-env) so I can target older browsers based on version configurations.