It does care about prototypes. So it checks for inconsistencies between methods added to a prototype and their uses. The tradeoff is that for dynamically added properties, it doesn't always remember where they are defined and where they remain undefined (it knows they are defined "somewhere").
If you can feed inferred static types to something like Google Closure Compiler, you do get performance benefits.
Also, if you're code is implicitly statically typed (as checked by Flow) you will likely hit all the right optimizations in the underlying JavaScript VM.
Yes, so the conclusion one might draw is that if your code is implicitly typed, it will run fast as well as probably do well when run through a static type checker.
One obvious thing to try is to use Flow's type inference to emit GCC annotations and see whether those optimizations kick in. (Of course, Flow can also try to replicate whatever GCC does, but that will take some time. No reason not to, though.)
Yes, it does. You can define object types like { x: number; y: string }, tuple types like [number, string], function types like (x:number) => string, etc.
We actually built this because we write a lot of JavaScript at Facebook, and we need a tool like Flow. So yes, we worked on it full-time, with "funding": our developers like to move fast, Flow helps them do that.
(It's a different matter that we would have done this on our free time anyway, because it's so much fun!)
We have some basic editor support, more is coming soon. Flow exposes several commands that are useful through an editor, like type-at-pos (give it a position, it gives you back the inferred type), suggest (give it a file, it dumps out an annotated file), autocomplete (gives you suggestions at a given position), etc. Also, we require annotations at module boundaries, so you're modules are going to have well-typed interfaces that serve well for both documentation and stability.
I strongly agree with module typing (and being more relaxed within). Because of caller dependence on modules, the difficulty of changing static types becomes a benefit. Plus, they need to be documented anyway; and tooling support helps use they as if they were primitives.
As others have said, I love the approach of inference giving static type benefits, for free. If you get tooling support, at no extra work, why not adopt it?
But static types can be a hard sell for JS programmers. What sort of reception has it gotten inside facebook?
Still early days but the reception has been strongly positive. We may be a biased bunch but we like our code mostly statically typed with the flexibility provided by dynamically typed languages. A large part of this culture is due to the immense internal success of Hack (http://hacklang.org/).
