Hacker News Reader

Comment by nathan_f77 | Hacker News Reader

Where can I find a good list of pros and cons for Flow and TypeScript?

I've been really enjoying Flow, and I have experienced all of the benefits mentioned in this article. I'm using VSCode, and the Flow integration is really good. Feels like a full IDE for Javascript, without being bloated and slow. (Startup is a little slower than Sublime, but it's very fast once everything has loaded.)

I'm wondering if I'm missing out on anything by choosing Flow instead of Typescript.

I've been developing React and React Native apps, and it seems like Flow is the default choice for that ecosystem. Has anyone switched from Flow to Typescript, and how did it go?

View on HN

We like the fact that TypeScript is a full ES.next to ES.x compiler. No need to also include Babel and a bunch of plugins in the build.

But the biggest TS advantage has to be the size of the ecosystem. There are quite a few libraries written in TypeScript, and there are type definitions for pretty much all popular JS libs (and quite a lot of obscure ones). The Flow defs ecosystem seems to be fairly anaemic by comparison.

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.

* 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.

> 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

[2]: https://github.com/styled-components/styled-components/blob/...

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

> 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.

> 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.

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

Sure! I'll just note there are more CI systems than CircleCI and TravisCI. Especially on premise and on older distros.

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.

One thing I like about Flow for small projects is that you can use the Flow 'comment syntax' so that you can start using Flow and leaning on the typechecker without adding any transpilation setup at all. Flow's inference means many type annotations can safely be omitted, too. Example: https://github.com/jsdf/they-live/blob/master/handler.js#L11...

I find this especially useful for node projects, where there is less of a case for using Babel etc (node 7 supports all the JS features I want).

Having experience with both on Node back-end projects, I can tell you than IMHO Flow is smarter, especially on union types, BUT there are way more TS community type definitions available right now.

I'd be curious in which ways flow is more intelligent than TS.

Here are some examples: TS: https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%... Flow: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmA...

With Typescript, you have to write custom Type Guards functions, whereas Flow is smart enough to infer type

If you use discriminated union types - e.g. give them both a type key which is a unique string, then you don't need type guards as typescript is smart enough to understand that checking the type key does the type discrimination.

Sure, but you don't always have control over an external module or service, and it still something flow is better at

Yeah, that's true. I don't know why you've been downvoted. You have a legitimate answer.

Me too. I don't really see how you can get any smarter with union types than with TS 2.2+

My React/Redux links list has a section of articles on static typing, which includes comparisons between Flow and TypeScript: https://github.com/markerikson/react-redux-links/blob/master... .

I've been using Flow+VSCode+React, and it's quite magical now!!!

With TS v2.2, I don't need to do any ugly hacks on TS to fit into pre-existing JS code.

Also, react support has been excellent since...TS 1.7 (or before?). TSX checks for React PropTypes <div on_click={...}> or <div onClick={someBool}> so this gets rid of most of my silly mistakes :)

I've used TypeScript, Flow and Elm for making front-end apps. My favourite of the three is by far Elm, even if that was a bit harder to get into (as it's a new language and I didn't know before how to do side-effect free programming).

Flow is definitely a better type system than TS. TS types are "strong" in the same way as Java types. Flow is basically OCaml types, so a similar type system to OCaml, Haskell or Elm (except that you can give things `any` type). I am sure I will chose Flow over TS for that reason.

A ML-type type system (Flow, OCaml, Haskell, Elm, etc) is very powerful in that you can have abstract types, which means you can do basic composition of them. Things like the Maybe or Result monad for instance, which is very useful (and simple).

Typescript on the other hand let's you use the basic JS types, but it's not as extensible.

Do you have any examples to back up your claims? I don't think Flow's type system is more advanced than TypeScript's (which is not Java-like in any way).

What do you mean by "abstract types"? TS's type system is based around structural interfaces, so you're almost always working with non-concrete types.

It also supports discriminated unions, and you can emulate nominal typing with abstract tag properties.

https://www.typescriptlang.org/docs/handbook/advanced-types.... https://basarat.gitbooks.io/typescript/docs/tips/nominalTypi...

This is completely wrong regarding TS. Check out what the last few versions have added, it's solid.

> Where can I find a good list of pros and cons for Flow and TypeScript?

Have a look here: http://djcordhose.github.io/flow-vs-typescript/flow-typescri...

PSA: That presentation is severely out of date and many of the negatives presented against Typescript don't apply anymore because of features added several releases ago.

Reply on news.ycombinator.com