5 ms·
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
by nathan_f77 10y ago
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?
- vanwalj 10y agoHaving 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.
- johnfn 10y agoI'd be curious in which ways flow is more intelligent than TS.
- boubiyeah 10y agoMe too. I don't really see how you can get any smarter with union types than with TS 2.2+
- vanwalj 10y agoHere are some examples: TS: https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%7B%0D%0A%20%20%20%20valA%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TB%20%3D%20%7B%0D%0A%20%20%20%20valB%3A%20string%0D%0A%7D%0D%0A%0D%0Atype%20TAorTB%20%3D%20TA%20%7C%20TB%0D%0A%0D%0Afunction%20isTA(x%3A%20any)%3A%20x%20is%20TA%20%7B%0D%0A%20%20%20%20return%20x.valA%0D%0A%7D%0D%0A%0D%0Afunction%20func%20(param%3A%20TAorTB)%20%7B%0D%0A%20%20%20%20if%20(isTA(param))%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IA')%0D%0A%20%20%20%20%7D%20else%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log('This%20is%20IB')%0D%0A%20%20%20%20%7D%0D%0A%7D https://www.typescriptlang.org/play/#src=type%20TA%20%3D%20%... Flow: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmALxgDeqYtYAbgIYzEBcYAzhgE4CWAdgHNUAX3TZ8RAELkqNOkxhT2XPkNHjcBYnG4yKJMAB9p6KAFd+AYwy84-MBetgAFDkbdGAW3Y69ASjk6MF4oV3dPLwA6RWJA6mDgq3sOOBg8KPhBFwByABUAC14OEJKSHP95WhEwPBgOAgTE2mT+VPTMuGz8opLi6QqqsDExIA https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCSAgmA... With Typescript, you have to write custom Type Guards functions, whereas Flow is smart enough to infer type
- johnfn 10y agoIf 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.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- bpizzi 10y ago> 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-typescript-2.html#/ http://djcordhose.github.io/flow-vs-typescript/flow-typescri...
- whatever_dude 10y agoPSA: 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.
- ash 10y agoI 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 agoAh, 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
- devdoomari 10y agoI'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 :)
- yjgyhj 10y agoI'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.
- boubiyeah 10y agoThis is completely wrong regarding TS. Check out what the last few versions have added, it's solid.
- deleted 10y ago[deleted]
- paavohtl 10y agoDo 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.html https://www.typescriptlang.org/docs/handbook/advanced-types.... https://basarat.gitbooks.io/typescript/docs/tips/nominalTyping.html https://basarat.gitbooks.io/typescript/docs/tips/nominalTypi...
- stupidcar 10y agoWe 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.
- acemarke 10y agoMy 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/static-typing.md https://github.com/markerikson/react-redux-links/blob/master... .
- mambodog 10y agoOne 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-L14 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).