

Exploring Flow, Facebook's Type Checker for JavaScript - frostmatthew
http://www.crmarsh.com/flow/

======
czarlos
Here's a quick link to the project page itself:
[http://flowtype.org/](http://flowtype.org/)

------
xjia
What is the difference between recently announced Flow and TypeScript?
[http://www.reddit.com/r/javascript/comments/2mrngf/what_is_t...](http://www.reddit.com/r/javascript/comments/2mrngf/what_is_the_difference_between_recently_announced/)

~~~
antiuniverse
After spending a few minutes bouncing around to other discussions trying to
figure this out, the answer seems to be something like "Use Flow if you: 1)
use JSX, or 2) can't be bothered to annotate your code but want a chance of
maybe catching some classes of error anyway."

Regarding #1, I don't personally like JSX, but a lot of people do, so maybe
they should use Flow. It seems likely the TypeScript compiler would barf on
code that employs JSX.

Regarding #2, I can't see how that will drive any appreciable adoption of this
tool. If you care enough to statically analyze your code, you probably care
enough to annotate it to get the much stronger safety guarantees that will
provide (not to mention other benefits, like "free" self-documentation, and
enabling more sophisticated tooling, that have been discussed elsewhere at
length).

Maybe I've missed an important use case here, but that's what I've been able
to piece together since I skimmed the article. And since the author was
recently interning on a large React codebase and never mentions TypeScript in
the article, I have a feeling he falls into use case #1 above.

~~~
yazaddaruvala
I mean you seem to discredit "incrementally adding annotations" as a feature.

You're correct that anyone that would like to statically analyze a part of
their code would want all of it analyzed. However, you're totally disregarding
the biggest problem. Large existing code bases.

I'm not sure if you've ever had to deal with a large, deployed to production
code base, but it doesn't seem like you have. I can tell you there is no way
to refactor all of it at once.

The only realistic way forward is to refactor a single function, perhaps full
file, one at a time.

~~~
antiuniverse
Like skybrian's reply mentioned, I don't think this is actually an area where
Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla
JavaScript should also readily compile as TypeScript.

In my mind the difference is that TypeScript doesn't purport to analyze the
correctness of regions of code that lack type annotations. Meanwhile, Facebook
claims that "Flow understands the control flow through the program."[0] That's
great in theory, and maybe their control flow analysis is really quite
sophisticated, but ultimately isn't this isomorphic to the halting problem?

[0]: [https://code.facebook.com/posts/1505962329687926/flow-a-
new-...](https://code.facebook.com/posts/1505962329687926/flow-a-new-static-
type-checker-for-javascript/)

~~~
xjia
> but ultimately isn't this isomorphic to the halting problem?

Take a look at [http://matt.might.net/articles/intro-static-
analysis/](http://matt.might.net/articles/intro-static-analysis/)

~~~
antiuniverse
Well, it's kind of uncanny how precisely that article addresses my
misconceptions at the outset. Thanks for an awesome link (and the related
k-CFA article at the bottom).

------
mot0rola
How well does flow play with third party libraries? ie. TypeScript has type
definitions that are pretty well established for most commonly used 3rd party
libs. I'm wondering if there is a similar project for Flow?

------
jimmyhmiller
I found one other way to use types across modules.

    
    
        /* @flow */  
        var Person;  
        type Person = {name: {first: string; last: string;}; isActive: boolean;}  
        module.exports.Person = Person
    

Just by writing that var you can use the type across modules.

------
igl
The maybe types `?string` really annoy me.

I will rather wait until TypeScript pleases me with union types and proper es6
alignment.

~~~
spion
Really? Why are they annoying?

~~~
igl
Optional parameters have ? as postfix too. Resulting code like: function
foo(x?:?string):?string { return x; }

I would much rather like a null type, or even better: have null be declared as
void too.

------
fintler
This looks similar to the type checking in Google's Closure compiler.

[https://developers.google.com/closure/compiler/docs/js-
for-c...](https://developers.google.com/closure/compiler/docs/js-for-
compiler#types)

~~~
rfb
Why has this been downvoted? is the type checking in Google Closure not a good
option?

~~~
fintler
I've had much success with it on a rather large project. _shrug_

