Facebook Launches Flow, Static Type Checker for JavaScript

What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook &amp; Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React.js and JSX).<p>Good job Facebook.

This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language.<p>That said, I am curious what solutions this solves that isn&#x27;t already solved by enforcing good code coverage. Full disclaimer, the largest js projects I&#x27;ve worked on were in the tens of thousands of lines, not hundreds of thousands, but type checking just seemed completely unnecessary provided a good coding guide and test coverage were maintained and enforced.

Another comment that just occurred to me: JavaScript becoming gradually typed is an interesting reflection of the recent history of the optimization of JavaScript interpreters, which consist of deducing where semantically dynamic objects behave like static class instances, then inlining the accessors and where beneficial, the &quot;class methods&quot;, and specializing &amp;&amp; JITing the semantically dynamic functions that almost always take as argument &quot;instances&quot; of this &quot;class&quot;.<p>(ref this absolutely fascinating paper<p><a href="http://bibliography.selflanguage.org/_static/implementation.pdf" rel="nofollow">http:&#x2F;&#x2F;bibliography.selflanguage.org&#x2F;_static&#x2F;implementation....</a><p>and this piece of V8 dox quoting the aforementioned paper<p><a href="https://developers.google.com/v8/design" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;v8&#x2F;design</a>)<p>It seems that adding a type system to a dynamic language has little real drawbacks compared to designing language and type system at the same time, for both performance and type safety considerations.

At last!<p>This all seem extremely cool.<p>I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I&#x27;ve always found that my code, and a lot of good libraries I read, naturally emulate something close to Hindley-Milner typing, by using objects as tuples&#x2F;records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Either types.<p>I&#x27;m definitely pleased to see that the designers of this library have also realized that strongly-typed javascript was just a few annotations and a type inference algorithm away.<p>I&#x27;m just wondering why are nullable types inmplemented as such and not as a natural consequence of full sum types, which are inexplicably absent.

Similar to the Google Closure Compiler (<a href="https://developers.google.com/closure/compiler/" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;closure&#x2F;compiler&#x2F;</a>), which has been around for years, just with fewer features.<p>It has static type checking with optional type annotations and type inference.<p>It doesn&#x27;t have compiler-time constants, dead code removal, inlining, or other optimizations.<p>But....still really cool.

How this compares to TypeScript? At the quick glance I noted:<p>- more powerful type system (union types, hurray)<p>- support for JSX<p>- no windows binaries<p>- supports more of ES6 stuff<p>- ...but has no support for modules yet<p>- no generics (??)<p>How about performance? and workflow? Didn&#x27;t yet find this: does it use a normal &quot;write then compile&quot; model like TS or has something like Hack (if I&#x27;m not mistaken it has a daemon running in the background, checking the code as you write it).<p>Wonder why FB decided to roll this on instead of using TS.

Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I&#x27;m sure static type checking can benefit some organizations, but in my experience, type related errors are usually easy to find and fix and have rarely if ever been the root cause of our most difficult problems. Dynamic type checking and implicit conversion is one of the more powerful features of JavaScript and certainly no less prone to error or counter-productive than type-casting, making variadic functions or class templates are in other languages.

From my perspective, the static type checking is more or less the same as TypeScript&#x27;s `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with<p><pre><code> tsc --noImplicitAny hello.tsc </code></pre> which will result in<p><pre><code> hello.ts(2,14): error TS7006: Parameter &#x27;x&#x27; implicitly has an &#x27;any&#x27; type. </code></pre> I do not see much difference.<p>[1]: <a href="http://flowtype.org" rel="nofollow">http:&#x2F;&#x2F;flowtype.org</a>

Make sure to checkout <a href="http://ternjs.net/" rel="nofollow">http:&#x2F;&#x2F;ternjs.net&#x2F;</a> too. It does not have types validation I believe, but it does many other things and in combination with eslint allows catching most errors before packaging.<p>Tern.js actually detect types, and may be it would be possible for eslint to incorporate it somehow to detect invalid use of types.<p>One big ternjs plus for me is the fact that tern.js knows about require.js modules and can look in other require&#x27;d files.

This is HUGE!<p>Thanks to everyone at Facebook who worked on this. You guys are awesome.<p>Also: The fact that this is written primarily in OCaml (as opposed to JS) is an excellent example of people choosing the right tool for the job.

Found a nice comparison of the various &quot;things&quot;(?) adding static typing to JS: <a href="http://www.2ality.com/2014/10/typed-javascript.html" rel="nofollow">http:&#x2F;&#x2F;www.2ality.com&#x2F;2014&#x2F;10&#x2F;typed-javascript.html</a>

I really like how Facebook went about getting as much information about types as possible without the coderess, not forcing her to do unnecessary stuff. Behavior design on the code level at its finest.<p>And on the side note, I bet Facebook did this just to make nerds install OCaml and show them the light :)

Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get &#x27;funded&#x27;?

Flow seems to be close to a true application of type theory and is written in OCaml. Well done Facebook.

Just tried it. Not good for projects depending heavily on 3rd party libs. I have to define all the interfaces in a &#x27;interface file&#x27; to keep &#x27;flow&#x27; silent. This seems an impossible job for our project.

I know it&#x27;s very early, but just curious if anyone is working on a node binding for this, or if one exists already? Would love to try it out in our stack, but it would require a javascript interface.

Question, in the doc it shows a code snipped that has the functioned defined as such &quot;function foo(x: string)&quot;<p>What mechanism ensures this becomes valid javascript? does the code need to be compiled?

There&#x27;s some tremendous effort being poured into making a crippled language like javascript usable, but when talking about solutions for maintainable frontend code, I&#x27;m more excited about compile-to-js languages like haxe [0], purescript [1] or ceylon [2].<p>The caveats I heard about transpilers often boil down to difficulty of debugging and lack of libraries. But with the amazing browser dev tools we have, debugging potential issues is not that painful. Every language compiling to js provides FFI and&#x2F;or some escape hatch so you can write javascript manually, for performance tuning or for using 3rd party libs.<p>Even if you do write &quot;raw&quot; javascript, some sort of compile step is unavoidable, for running jshint, concatenating, minifying, etc. Why not walk the extra mile and use a better language?<p>BTW, I&#x27;m not saying a tool like this is not super-useful, specially if you already have thousands of lines of js code that you can&#x27;t get rid of. Congrats to the Facebook team for the release!<p>0: <a href="http://haxe.org/" rel="nofollow">http:&#x2F;&#x2F;haxe.org&#x2F;</a><p>1: <a href="http://purescript.org/" rel="nofollow">http:&#x2F;&#x2F;purescript.org&#x2F;</a><p>2: <a href="http://ceylon-lang.org/" rel="nofollow">http:&#x2F;&#x2F;ceylon-lang.org&#x2F;</a>

Does it support structural typing? That seems to be the strongest advantage of TypeScript.

Whatever people&#x27;s thoughts on the language itself, JavaScript has built itself into a juggernaut in the amount of tooling available that fit into various opinions that developers can choose from. The number of large frameworks (in terms of popularity and usage) is not really found elsewhere. The number of smaller plugins are vast.<p>It helps that companies like Google and Facebook have invested a significant amount of research power into designing frameworks and tooling around it. Just from there two companies alone, we have tools like React, Angular, Karma, JSX, Jest, and now Flow. Tooling that involves the browser more include Polymer and Traceur (ES6 to ES5 transpiler).<p>To contrast this, I have been doing development with Cordova the past week &amp; writing Cordova plugins to fill in missing functionality - the plugin ecosystem with Cordova is horrid, and the documentation is often awful. To compound it, Android developers don&#x27;t seem to believe in documenting their libraries well.<p>I will take the JS ecosystem any day when confronted with a choice like that.

Great work, no doubt.<p>My personal preference is to have annotations because it helps future readers and maintainers understand the code better. Instead of looking through the function to see that the variable is in-fact a number, I&#x27;d rather just read &quot;@param x {number}&quot;. And at that point, one may as well as use closure.

This is really cool. Does anyone have pointers to relevant papers that inspired&#x2F;influenced their type system?

This is what I wished Typescript was.<p>Looks really handy.

If you are interested in learning more about Flow check out the docs [1] and github repo [2].<p>[1] - <a href="http://flowtype.org/" rel="nofollow">http:&#x2F;&#x2F;flowtype.org&#x2F;</a><p>[2] - <a href="https://github.com/facebook/flow" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;flow</a>

Apparently this is just type checking. It&#x27;s not going to do any dead code removal like Closure Compiler in advanced mode or provide a better syntax like TypeScript. Whether that&#x27;s good or bad depends on what you&#x27;re looking for.

I wonder, how does this compare to Google&#x27;s Dart.js? Like Dart, it introduces a type system into JS and like Dart, it requires a compile step between Flow code and JS that will run in a browser. What does Flow do differently than Dart?

Static types without performance benefits. So far, all <i>popular</i> static type systems have had the performance benefits, so it&#x27;s unclear how much people value the other benefits (quality and documentation).<p>I wonder which will have the most impact: code quality or types as documentation (esp for tooling)?<p>They are adapting to common idioms, rather than designing it from the ground up. This ad hoc approach is a great way to build useful tools (and startups), but it&#x27;s also usually a <i>mess</i>. Like NN4. But, they seem to be type experts - plus they&#x27;re using ocaml. Maybe <i>ad hoc</i> by experts <i>is</i> the way to get these ideas adopted?

Even without the flow analysis and better typing, incremental compilation is a huge improvement over TypeScript, which re-parses type declarations on every compilation. That quickly leads to large compile times when you have type definitions for third-party components (even though you may only be using one definition in the file, the entire definition is parsed).<p>The existing available definitions from the DefinitelyTyped project is a huge productivity booster. Apparently Flow also has similar .d.flow files, but it will probably be a while until they exist for common projects.

This looks great, in typesystem&#x2F;tooling&#x2F;presentation, and sounds perfect for facebook; but for mainstream adoption, it needs to meet (or be closer to) the ideal of <i>free-benefits</i>:<p>(1) zero-work: works instantly with existing code and esp third party libraries; and<p>(2) instant-benefit: provides <i>some</i> compelling benefit in that zero-work case above (of course, it&#x27;s OK if it provides more benefit if you do more work, adding type annotations etc).

This might be a stupid question, but is there a way to leverage object annotations [1] for runtime checks of data coming from e.g. an API or FFI call (node.js module calling C++ code)?<p>[1] <a href="http://flowtype.org/docs/react-example.html#general-annotation-strategy" rel="nofollow">http:&#x2F;&#x2F;flowtype.org&#x2F;docs&#x2F;react-example.html#general-annotati...</a>

Is the type syntax friendly with CoffeeScript?

Best tech news I&#x27;ve seen this year, in terms of potential to directly improve my workflow and my clients&#x27; applications.<p>I&#x27;m surprised I didn&#x27;t hear more about this before since it was apparently unveiled at the &quot;Flow&quot; conference. Wasn&#x27;t at the conference and somehow I missed any prior mention of it.

One of the authors of Flow offered to answer questions, but their comment is greyed out as a dupe (and it isn&#x27;t a dupe - something went wrong):<p><a href="https://news.ycombinator.com/item?id=8625406" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8625406</a>

How does static checking work with dynamic types? Can the type checker figure out if a field&#x2F;method exists on a type given that it can be added dynamically?<p>Edit: I assume it just checks bool&#x2F;number&#x2F;string and doesn&#x27;t care about prototypes?

That is quite impressive. No type annotations needed, and control flow is taken intro consideration (hence the name I guess).<p>If I am not mistaken, this tech could be used to build IDEs roughly similar to whats available for Java, couldn&#x27;t it?

Looks like a great tool. The documentation at <a href="http://flowtype.org/" rel="nofollow">http:&#x2F;&#x2F;flowtype.org&#x2F;</a> is excellent. Should be easy to add it to a Gulp&#x2F;Grunt workflow.

In terms of layering a static type system on top of JavaScript, how does this interact with Coffeescript and other languages that compile to JavaScript?

Can someone explain in simple words what is the problem that this would fix? I&#x27;ve never felt the need for this, why should I care?

I&#x27;m really curious about the accuarcy of that tool,really really curious given how javascript &quot;types&quot; work.

Hi, I&#x27;m Avik Chaudhuri, I&#x27;m one of the authors of Flow, and I&#x27;ll be happy to answer questions.

Awesome. FYI, the Language Reference Next&#x2F;Back links don&#x27;t match the order in the left navbar.

Or you can just use GWT which saves you from having to use javascript at all, and lets you write java (along with all its IDEs, type checking, code structure, and other benefits) which is compiled to highly efficient javascript: <a href="http://www.gwtproject.org/learnmore-sdk.html" rel="nofollow">http:&#x2F;&#x2F;www.gwtproject.org&#x2F;learnmore-sdk.html</a>

Looks nice. Is it written in ML?

Has any one tried to make it work with a google closure code base? I am still trying.

<a href="http://flowtype.org/" rel="nofollow">http:&#x2F;&#x2F;flowtype.org&#x2F;</a><p>Direct link

Static? I use my own type-checking&#x2F;enforcing lib as a base for everything I write in JS or CS (<a href="https://github.com/phazelift/types.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;phazelift&#x2F;types.js</a>). It&#x27;s only 1.8kb, dynamic and never fails on me.

Waiting for more ES6 support! I am spoiled by 6to5.

Man, I really want to work at Facebook. If only they didn&#x27;t require relocation.

Very nice. I wonder how hard this would be to throw into Jasmine&#x2F;QUnit type scenarios.

Who writes JS these days? Will it go with Angular&#x2F;jQuery?