Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Launches Flow, Static Type Checker for JavaScript

code.prod.facebook.com

Post reply on HN
Print view View original

41–50 of 282 posts

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#41

Post by drderidder »

inglor wrote: post #29
drderidder wrote: post #11

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,…

This is a form of cross-compilation kind of like how TypeScript is cross compilation. It does require a build step to produce JavaScript - you will not be able to enjoy fiddles as easily and so on. Then again their rationale is very clear and pretty good: You need builds if you're using Facebook's stack anyway (for JSX) so this should not interfere with your current build - which you have to do anyway.

Really? It appears to be much more of a static analysis tool than a cross-compiled psuedo-syntax. Here's what it outputs:

   flow examples/01_HelloWorld/hello.js
   /hello.js:7:5,19: string
   This type is incompatible with hello.js:4:10,13: number

   Found 1 error

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#42

Post by jackweirdy »

stiff wrote: post #40
drderidder wrote: post #11

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,…

JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of NaN many common coding mistakes end up producing mysterious errors pointing somewhere far away from the place in the code that actually produced the problem in the first place. Basically JavaScript continues propagating null/undefined/NaN in many situations w…

Really? I find it happens as often as NullPointerExceptions. Viva la Maybe type

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#43

Post by slashnull »

slashnull wrote: post #31

At last! This all seem extremely cool. I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I'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/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Ei…

Wow!

I missed the part about sum types!

My god this is perfect

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#44

Post by inglor »

slashnull wrote: post #31

At last! This all seem extremely cool. I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I'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/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Ei…

Strongly typed JS is actually pretty hard - probably not by Haskell and Scala standards - but if you take promises for example the signature of `then` is:

Promise -> ((A -> (Promise | B)),(E -> (Promise | C))) -> Promise

That is - a promise's then - takes the promise (as this) and executes either a `.then` fulfillment handler or a catch handler.

If the `fulfill` handler executes the value is unwrapped and either a new value, or a Promise over a new value and its own type of error is returned.

Now, if the `reject` handler is executed the error is unwrapped and either a new value, or a promise over a new value or a new error is returned.

This is quite simple and easy to use because it behaves like try/catch in the dynamic type system of JS with recursive unwrapping - however it is challenging to reason about when you're starting to type code and you want to actually have correct type information with promises.

Static languages generally approach these problems with pattern matching on the type - in JS that's not common nor is it feasible at runtime - you just expect a value of a certain type. When I implemented promises in another language (swift) this was a lot of fun to work through and not very trivial - if their compiler cna do this I'd be very impressed.

Promises are just one example.

Anyway - this looks cool. I definitely agree that full sum types would've made more sense - having explicit nullables is usually a smell (like in C#).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#45

Post by inglor »

drderidder wrote: post #41
inglor wrote: post #29

Earlier quoted context omitted.

This is a form of cross-compilation kind of like how TypeScript is cross compilation. It does require a build step to produce JavaScript - you will not be able to enjoy fiddles as easily and so on. Then again their rationale is very clear and pretty good: You need builds if you're using Facebook's stack anyway (for JSX) so this should not interfere with your current build - which you have to do anyway.

Really? It appears to be much more of a static analysis tool than a cross-compiled psuedo-syntax. Here's what it outputs: flow examples/01_HelloWorld/hello.js /hello.js:7:5,19: string This type is incompatible with hello.js:4:10,13: number Found 1 error

EDIT: looks like it supports type annotations similar to closure compiler's (in docs) https://github.com/facebook/flow/blob/master/tests/docblock/...

Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'.

If the code requires transformation by a compiler aware of the language semantics and syntax - it's transpiling in my book. Just like TypeScript is a superset of ECMAScript - so is Flow (in a much lighter, closer to source sense it seems).

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#46

Post by inglor »

DigitalSea wrote: post #39

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 & 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…

It's hard for me to give appreciation but while Google have traditionally been tech leaders in web technologies: Facebook are doing really awesome stuff lately. It's not just React and this - it's also FLUX, HHVM, Hack, Haxl (Their Haskell libraries), contributing to writing a spec for PHP and other ventures.

I'm interested in who is the driving force behind this open source change in Facebook, I don't recall facebook in behaving these way 4 years ago.

Can anyone find anything on a policy change that happened? They really turned around.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#47

Post by drderidder »

stiff wrote: post #40
drderidder wrote: post #11

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,…

JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of NaN many common coding mistakes end up producing mysterious errors pointing somewhere far away from the place in the code that actually produced the problem in the first place. Basically JavaScript continues propagating null/undefined/NaN in many situations w…

Yeah, that can be confusing. On the other hand, if you write unit / functional tests then testing for invalid inputs one of the first things you'll probably do. Your comment makes me think a fuzzer to test all those falsey values could be useful.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#48

Post by inglor »

drapper wrote: post #10

How 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…

Some comments on that:

- Has other comments have said: TypeScript is getting (already in master branch) union types.

- Support for JSX isn't really a huge deal.

- Windows support will probably come - it's an open source library. I hope it's not the OCAML tooling.

You make some great points about generics and using their own type system instead of TS, especially since TS has investments from both Microsoft and Google (with AtScript which supersets it).

They state they use a model like Hack - and the repo also looks this way but I'm also curious, it looks like a very peculiar choice.

Re: Facebook Launches Flow, Static Type Checker for JavaScript

#49

Post by derek »

skybrian wrote: post #35

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

It's certainly possible that these could be used in combination. GCC optimizations aren't significantly enhanced by JSDoc annotations, so presumably this could generate code for GCC to optimize without losing major benefits on either side.

The React.js team has been explicit about the library being GCC advanced mode compatible, so they certainly have awareness of its capabilities. Whether they are using them together internally or they use a different solution for tree shaking et al is another question.

Post reply on HN