Does it support structural typing? That seems to be the strongest advantage of TypeScript.
Facebook Launches Flow, Static Type Checker for JavaScript
81–90 of 282 posts
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#82What 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 faceboo…
As kmavm said, thanks for saying so on behalf of the people who have been working on open sourcing things (I haven't as yet).
I don't think there's been any policy changes. I think the policy has always been that we're open to open sourcing stuff, so long as it is useful to others (ie, not just a code drop that nobody can use) and someone signs up for the work and there isn't something important that's being dropped in the process.
The difference I think is people, energy, and momentum.
We've been able to find people (many already at the company) genuinely interested in some of the less glamorous parts of building a scalable program to open source things - things like sync processes and pull request management and UIs for ACLs and CLAs and so forth.
We've had people who, often due to the availability of these tools, have developed an internal energy to want to put in the extra effort to make their project ready to be open sourced (like making sure all dependencies are available already, or scoping out or stubbing out things that are Facebook-specific (our asset management flow, for example) while still keeping the software useful, and so forth.
The momentum has also made the idea of open sourcing code more top-of-mind to people, which helps to get people to rewrite their changes to accommodate a nascent open sourcing effort on a piece of code, or to get more discretionary time to investigate or work on making something open source. Or even just moral support from your team and colleagues.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#83This is HUGE!
Thanks to everyone at Facebook who worked on this. You guys are awesome.
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.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#84Best tech news I've seen this year, in terms of potential to directly improve my workflow and my clients' applications.
I'm surprised I didn't hear more about this before since it was apparently unveiled at the "Flow" conference. Wasn't at the conference and somehow I missed any prior mention of it.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#85This 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)?
[1] http://flowtype.org/docs/react-example.html#general-annotati...
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#86Earlier quoted context omitted.
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 faceboo…
As kmavm said, thanks for saying so on behalf of the people who have been working on open sourcing things (I haven't as yet). I don't think there's been any policy changes. I think the policy has always been that we're open to open sourcing stuff, so long as it is useful to others (ie, not just a code drop that nobody can use) and someone signs up for the work and there isn't something important that's being dropped…
Well, regardless of root cause, you all are racking up some amazing open source accomplishments. Big props to everyone working on open source at Facebook.
And I think these efforts will pay off in spades for Facebook, in terms of attracting top talent and in terms of the expertise that results from having the some of the best dev tools available being developed in-house.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#87Earlier quoted context omitted.
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.
In general, this argument is self-defeating: "I don't need a type checker because I write unit tests." Obviously that means you need a type checker, because then you don't have to write 70-90% of your unit tests. Unit tests require time and energy to produce, run, and maintain. A type-checking compiler can remove much of this burden from the developer.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#88Static 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…
I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#89This 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. That said, I am curious what solutions this solves that isn't already solved by enforcing good code…
This feels like saying airbags and seatbelts add nothing to cars assuming good driving practices.
It solves not having to write a bunch of tests that can trivially be caught by a program and never having to update or maintain those tests. It hits every code path automatically, you don't have to think of cases to try to hit edge cases.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#90Earlier quoted context omitted.
> Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. Of course not, but the point was that it's not a different language, it simply adds type annotations. If you strip out the type annotations, it should be a valid JS file.
This is also true for TypeScript though. The only thing that's not directly JS in TypeScript is shims for new JS features (from ES6) not yet implemented.
> This is also true for TypeScript though.
AFAIK none of these are valid javascript, event assuming ES6:
* class-level variables (resolved as instance variables)
* field visibility
* initializer constructors (constructor without a body automatically assigning to a field)
* enum types
That is, you can't remove type annotations (and `interface` declarations which can probably get a pass) and end up with valid JS, which seems to be what flow yields.