Hacker News Reader

Comment by pcx | Hacker News Reader

We faced a similar situation in our project and went with Flow instead. We found a TS + Webpack setup too unreliable. There are couple of popular Webpack loaders (ts-loader and at-loader), and both kept crashing the Node process every other build. Build times were pretty high. We could not find any documentation on how to fix these problems, except for a few open GitHub issues.

We then tried Flow. Oh dear god, has it been a blessing.

Pros:

* It's seamless to integrate with Webpack, ESLint & Babel.

* It's crazy fast

* Has great support for React

* Fits in perfectly with Redux

* Dead easy for beginners to learn

* Has an amazing Type system. My major experience with types has been Java, and Flowtype just blew my mind with - non-nullable types, subtyping and type refining.

* Documentation is great

* Community is very active

Cons:

* About 1/3rd of the time error messages are not intuitive. But nothing you can not figure out. And it's getting better.

View on HN

It's interesting to learn that the two sibling comments here (at the time of writing) both misunderstood the parent. Both in exactly the same way, too.

In the parent post, pcx shares his experience with trying to make TypeScript work, concludes that he wasn't able to make it work, then says he was able to make Flow work and lists ways in which Flow made his life easier.

Not even a word in the post suggests that the parent intended his "pros" list to be a comparison between TS and Flow. It's just a list of things Flow does for him. Not even one mention of TS on that list!

I don't quite understand why would one misinterpret a list of good things about one tool to be also, implicitly, a list of bad things about another tool. It's not politics, we don't need such polarization in technical discussions, saying that Flow has great docs is not the same as saying TS has bad docs.

But the real problem is that, by choosing to get offended by something entirely unrelated, the sibling commenters missed the one direct comparison between TS and Flow and a real TS criticism: parent says it's easier to setup Flow compared to TS. It would be better to discuss this point - I'm not qualified to do so myself, unfortunately - instead of focusing on statements the parent never wrote.

Let me add a few cons then

- Saying the error messages are "not intuitive" is a bit of an understatement. Most memorably, this was an actual message I was presented with after upgrading to Flow v0.53 - https://imgur.com/UseQxEz.png

- Flow's goal appears to be ensuring correctness rather than being useful. Object.value produces an array of mixed, effectively erasing their type (https://github.com/facebook/flow/issues/2174). document.body is a Maybe (https://github.com/facebook/flow/issues/4783). All use of getters and setters are marked as unsafe, with no way to selectively opt in or out (https://github.com/facebook/flow/issues/2826). These are pedantic to the point of uselessness.

- When a function call's parameter type disagrees with the function signature, Flow flips a coin and marks one of them as incorrect. GitHub issue from Oct 2016 - https://github.com/facebook/flow/issues/2587 (issue is closed because they're 'working on it', not because it's actually resolved)

- Flow's libdef is a fraction of TypeScript's. I frequently convert TypeScript libdefs to Flow libdefs. I have yet to see a library that has Flow libdef but not TypeScript libdefs.

What is your threshold for too long of a build time? I recently converted a typescript (angular 1.x) project from jspm to webpack. The front end build time went from 3 minutes to 30 seconds, but I don't know if that's still "too long" as I have no basis for comparison.

In my experience, a fast build is one that finishes before I can tab back to my browser. Compilers that can incrementally build my project are all I prefer to use.

I set up webpack-dev-server for that case. Saving a file refreshes the page in about 1 second (after 30 second initial build on dev-server start). Full build still takes 30, which is tolerable but I can't shake the feeling that there's another 2-4X speedup still to be made.

What about flow gives it better support for React than TS (other than it being built into the CLI)? Why does it fit more perfectly with Redux than TS? Why is it easier to learn than TS? Why does it have a more amazing type system than TS?

I also take issue with some of OP's unsubstantiated claims, but I'd like to add my own piece of anecdotal experience:

The experience I've had around typing higher-order components in general, and specifically with the recompose library (https://github.com/acdlite/recompose), which I use heavily in just about every React project, has been much better in Flow than in TypeScript. Now this is not completely fair to TypeScript since the recompose types for it were still a work in progress last time I tried it, but recompose is a central building block in most of the codebases I work with on a day-to-day basis, so good typing around it is a vital consideration for me, and possibly others who prefer to work with React components using functional composition.

As I mentioned we couldn't get TS + Webpack to work properly. I am not dishing TS, I just couldn't evaluate it all that well. To expand more on your points:

- Flow has more & better type definitions for React than TS. I think it's because a lot more React devs use/develop Flow and also both are FB projects.

- For our Redux + Flow setup, we export an ActionCreator type that is a union of all action creators we've defined. This union gets refined by the switch statements in reducers, allowing us access to well typed action creators in reducers, without having to deal with import/export of individual types.

- The docs are pretty good. Several of my colleagues are new to static typing, and have picked Flow up easily because of the docs. I also heard some interest in providing video courses like Egghead.

- Flow has an amazing type system compared to Java. Except for enums though. Java Enums are much much better.

Flow bakes React libdefs right into the binary https://github.com/facebook/flow/blob/master/lib/react.js - so yes, Flow damn well have good React support, because the React libdef is given the same level of importance as Node and DOM APIs.

Of course it also means you can't upgrade React without upgrading Flow, and you can't target a specific (older) version of React without downgrading Flow.

> For our Redux + Flow setup, we export an ActionCreator type that is a union of all action creators we've defined. This union gets refined by the switch statements in reducers, allowing us access to well typed action creators in reducers, without having to deal with import/export of individual types.

What's stopping you from doing this in Typescipt?

I downvoted since a majority of these things are valid for Typescript as well.

How is that a good enough reason to downvote? I haven't said they don't apply for TS. I am specifically speaking about my experience trying both TS and Flow.

I think your pros read as pros against TypeScript, when many of them apply both tools.

Well yes, and you list a bunch of things as pros that are true for both tools but for one which makes it appear like Flow would have these features and not Typescript.

Reply on news.ycombinator.com