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'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.
Facebook Launches Flow, Static Type Checker for JavaScript
11–20 of 282 posts
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#12Looks nice. Is it written in ML?
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#13Looks nice. Is it written in ML?
Yes, OCaml.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#14From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with
tsc --noImplicitAny hello.tsc
hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type.
[1]: http://flowtype.org
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#15From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org
No, instead of complaining about 'x' having the 'any' type, Flow will actually try to infer a static type for 'x'. So in the best case there would be no errors (and in the worst case there would be actual errors to fix).
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#16Very nice. I wonder how hard this would be to throw into Jasmine/QUnit type scenarios.
If you're using karma to run your jasmine specs, then I'd let karma-bro to run the files through browserify transform.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#17Found a nice comparison of the various "things"(?) adding static typing to JS: http://www.2ality.com/2014/10/typed-javascript.html
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#18From my perspective, the static type checking is more or less the same as TypeScript's `--noImplicitAny` option as the first example on flowtype [1] shows, the same can be achieved with tsc --noImplicitAny hello.tsc which will result in hello.ts(2,14): error TS7006: Parameter 'x' implicitly has an 'any' type. I do not see much difference. [1]: http://flowtype.org
One major difference is the null checking. From what it looks like, they've added an additional type, "maybe", that represents a possibly-null object.
TypeScript doesn't have that concept, although it's been suggested by the community more than once.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#19Who writes JS these days? Will it go with Angular/jQuery?
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#20How this compares to TypeScript? At the quick glance I noted: - more powerful type system (union types, hurray) - support for JSX - no windows binaries - supports more of ES6 stuff - ...but has no support for modules yet - no generics (??) How about performance? and workflow? Didn't yet find this: does it use a normal "write then compile" model like TS or has something like Hack (if I'm not mistaken it has a daemon r…
There is indeed generics in Flow
http://flowtype.org/docs/classes.html#polymorphic-classes
http://flowtype.org/docs/functions.html#polymorphic-function...