11 ms·

Facebook Launches Flow, Static Type Checker for JavaScript

• UnixHakr 12y ago
  Very nice. I wonder how hard this would be to throw into Jasmine/QUnit type scenarios.
  • petrbela 12y ago
    If you're using karma to run your jasmine specs, then I'd let karma-bro to run the files through browserify transform.
  • Joeri 12y ago
    I'm wondering whether I can add it into my team's svn pre-commit hook that already does jshint checking. It's remarkable what a difference in runtime js errors and overall code quality that pre-commit hook made for us.
• kaonashi 12y ago
  This is what I wished Typescript was. Looks really handy.
• antoinelyset 12y ago
  Flow seems to be close to a true application of type theory and is written in OCaml. Well done Facebook.
• davemo 12y ago
  If you are interested in learning more about Flow check out the docs [1] and github repo [2]. [1] - http://flowtype.org/ http://flowtype.org/ [2] - https://github.com/facebook/flow https://github.com/facebook/flow
• elwell 12y ago
  Is the type syntax friendly with CoffeeScript?
  • jbaudanza 12y ago
    It looks like Flow should work to the extent that it can infer types from your CS output, but it will be tricky to embed explicit types into your CoffeeScript source. You can probably hack it using the backtick operator though. `function foo(x: string, y: number): string {` x.length * y `}`
  • inglor 12y ago
    Looking at the source - it looks like it's not friendly with CoffeeScript in particular at the moment. It'd be quite possible to add the ability to output these annotations to the CoffeeScript compiler itself though. Could be an interesting fork.
• avik 12y ago
  Hi, I'm Avik Chaudhuri, I'm one of the authors of Flow, and I'll be happy to answer questions.
• MrBuddyCasino 12y ago
  That is quite impressive. No type annotations needed, and control flow is taken intro consideration (hence the name I guess). If I am not mistaken, this tech could be used to build IDEs roughly similar to whats available for Java, couldn't it?
  • jspdown 12y ago
    There are ambiguous case where you need to specify a type to obtain the expected error.
  • bri3d 12y ago
    It looks like it's designed for the IDE use case - on cursory inspection of the code, it contains an autocomplete database and a client-server architecture designed for editor plugins (with useful interfaces like "type at character index"). I'm surprised that they don't seem to have launched with a public editor plugin and that the documentation doesn't seem to mention it.
    • fredemmott 12y ago
      Here's one :) https://github.com/facebook/vim-flow/ https://github.com/facebook/vim-flow/
    • avik 12y ago
      The source also has an emacs plugin, named flow-types.el
• jenius 12y ago
  I know it'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.
• drapper 12y ago
  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 running in the background, checking the code as you write it). Wonder why FB decided to roll this on instead of using TS.
  • jimarcey 12y ago
    There is indeed generics in Flow http://flowtype.org/docs/classes.html#polymorphic-classes http://flowtype.org/docs/classes.html#polymorphic-classes http://flowtype.org/docs/functions.html#polymorphic-functions http://flowtype.org/docs/functions.html#polymorphic-function...
  • Arnavion 12y ago
    >...but has no support for modules yet I see some mentions of import in the tests and the grammar: https://github.com/facebook/flow/search?utf8=%E2%9C%93&q=import&type=Code https://github.com/facebook/flow/search?utf8=%E2%9C%93&q=imp...
  • jimarcey 12y ago
    There is no real compile time step with respect to type checking. Flow (like Hack) analyzes and type checks in the background, realtime. For workflow, check out: http://flowtype.org/docs/getting-started.html#_ http://flowtype.org/docs/getting-started.html#_
  • inglor 12y ago
    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.
• drderidder 12y ago
  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.
  • inglor 12y ago
    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.
    • slashnull 12y ago
      If only to remove syntactically invalid type annotations, I guess. Strong typing is not incompatible with the absence of run-time typing information, due to the magic of type erasure.
      • ufo 12y ago
        Type erasure is only safe if the whole program is statically typed though - you are still going to need to use runtime checks if you want to interface with dynamic code.
        • slashnull 12y ago
          Well yeah nobody talked about removing JS's duck typing algo.
• dgreensp 12y ago
  Looks nice. Is it written in ML?
  • avik 12y ago
    Yes, OCaml.
• fdomig 12y ago
  From 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 http://flowtype.org
  • avik 12y ago
    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).
  • judah 12y ago
    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.
    • inglor 12y ago
      Here is some interesting discussion on that aspect of the typesystem: https://github.com/Microsoft/TypeScript/issues/14 https://github.com/Microsoft/TypeScript/issues/14 It also discusses Flow from 2 months ago (from a now removed video)
  • masklinn 12y ago
    TS bolts on a straightforward nominative type system without type unions (or non-nullable types), so it can't handle a variable typed as `number | string`, it'll immediately drop down to `any`. That is, flow aims to remain useful in the face of more JS idioms. It won't make a difference between nullable and non-nullable either, so AFAIK function length(x) { return x.length; } length(null); can never be a compile-time error in typescript.
    • 12y ago
• chrisan 12y ago
  Found a nice comparison of the various "things"(?) adding static typing to JS: http://www.2ality.com/2014/10/typed-javascript.html http://www.2ality.com/2014/10/typed-javascript.html
• noobplusplus 12y ago
  Who writes JS these days? Will it go with Angular/jQuery?
  • pswilson14 12y ago
    Angular and jQuery ARE JavaScript.
    • edwintorok 12y ago
      It probably doesn't typecheck yet though. Will future versions of popular javascript libraries typecheck with flow, or will there be a repository of interface files so at least code using these frameworks can typecheck?
  • qgmr101 12y ago
    You got downvoted by people with broken sarcasm detectors...
    • noobplusplus 12y ago
      This gives me a feeling.The quality of folks lurking on HN has gone down. I mean, people could not get this saarcaaasm!
    • noobplusplus 12y ago
      This gives me a feeling.The quality of folks lurking on HN has gone down. I mean, people could not get this saarcaaasm! This makes me sad!
    • aflinik 12y ago
      Poe's law doesn't make it very easy.
• swalsh 12y ago
  Question, in the doc it shows a code snipped that has the functioned defined as such "function foo(x: string)" What mechanism ensures this becomes valid javascript? does the code need to be compiled?
  • jimarcey 12y ago
    These should hopefully help you out. http://flowtype.org/docs/existing.html#_ http://flowtype.org/docs/existing.html#_ http://flowtype.org/docs/running.html#_ http://flowtype.org/docs/running.html#_
  • jspdown 12y ago
    It's ensured by a compilation step. From their website: "Typed Flow code easily transforms down to regular JavaScript"
  • inglor 12y ago
    This is _not_ valid JavaScript. The code has a build step - yes. You will not be able to run this code without a step. It could be awesome if they allowed annotations in comments like other tools do - there is a GH issue on that and it looks like it should be possible https://github.com/facebook/flow/blob/master/src/typing/comments_js.ml https://github.com/facebook/flow/blob/master/src/typing/comm...
• slashnull 12y ago
  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 Either types. I'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. I'm just wondering why are nullable types inmplemented as such and not as a natural consequence of full sum types, which are inexplicably absent.
  • slashnull 12y ago
    Wow! I missed the part about sum types! My god this is perfect
  • inglor 12y ago
    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,E> -> ((A -> (Promise<B,F> | B)),(E -> (Promise<C,G> | C))) -> Promise<B|C,E|G|C> 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#).
• skybrian 12y ago
  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.
  • derek 12y ago
    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.
• DigitalSea 12y ago
  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.js and JSX). Good job Facebook.
  • inglor 12y ago
    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.
    • kmavm 12y ago
      Thanks for the kind words. For context, I'm an HHVM alum who has been at Facebook for almost six years now (wow time flies). From my point of view, most of what has changed is resources and the immediacy of our survival-level concerns. Four years ago Google had declared nuclear war on us, we had far fewer users, we were not profitable, there were constant fires to put out with basic production operations stuff we've gotten better at, and we were enormously more under-staffed. I was working on HHVM already, but it was in a million little pieces spread across Drew's, Jason's, and my desks. The tools we're open sourcing over the last two years mostly did not yet exist, and if they existed, it was in some primordial form. We also have gotten much, much better imho at being good stewards of our open source projects; HHVM's predecessor system, the HipHop compiler, was also open source, but we people were spread way too thin to be able to respond to bug reports, pull requests, get FB's latest code into public hands, build binary packages for popular distros, etc. on a timely basis. Huge props are due to all of the technical people on our open source teams.
• void_star 12y ago
  This is really cool. Does anyone have pointers to relevant papers that inspired/influenced their type system?
  • slashnull 12y ago
    It's pretty much a bastardized form of HM typing, like Haskell, OCaml and ML has. http://learnyouahaskell.com/ http://learnyouahaskell.com/
  • avik 12y ago
    The implementation is heavily influenced by Pottier's work on subtyping + inference. https://hal.inria.fr/file/index/docid/73205/filename/RR-3483.pdf https://hal.inria.fr/file/index/docid/73205/filename/RR-3483... Also, some techniques from Typed Racket (occurrence typing): http://www.ccs.neu.edu/racket/pubs/popl08-thf.pdf http://www.ccs.neu.edu/racket/pubs/popl08-thf.pdf Many other papers have influenced the design in some way or the other. For example, Abadi/Cardelli's theory of objects.
• alkonaut 12y ago
  How does static checking work with dynamic types? Can the type checker figure out if a field/method exists on a type given that it can be added dynamically? Edit: I assume it just checks bool/number/string and doesn't care about prototypes?
  • avik 12y ago
    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").
• ep103 12y ago
  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. That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. Full disclaimer, the largest js projects I'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.
  • slashnull 12y ago
    So what's wrong with having a tool to automate those practices ; )
    • ep103 12y ago
      This is a bit off topic, but I digress.... I specifically didn't send this tool to the team I work on, because my team lead is a sql / java / c# guy who loves static languages, and only touches the front end with a stick if he has to, and then only some basic jQuery or angular. I've sold him on jasmine and requiring front end test coverage, recently. But right before I hit the send button I realized that if I sent him this tool, I'd never be allowed to use dynamic typing or non annotated functions/arguments in js ever again. Hence my question : /
      • a-saleh 12y ago
        Try to sell him on type-inference first?
  • dested 12y ago
    How does optional typing weaken javascript?
    • slashnull 12y ago
      I suppose he was talking about TypeScript and CoffeeScript.
• lechevalierd3on 12y ago
  Has any one tried to make it work with a google closure code base? I am still trying.
• szx 12y ago
  Awesome. FYI, the Language Reference Next/Back links don't match the order in the left navbar.
• pspeter3 12y ago
  Does it support structural typing? That seems to be the strongest advantage of TypeScript.
  • avik 12y ago
    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.
• mjackson 12y ago
  This 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.
  • nevir 12y ago
    IMO OCaml is the wrong tool for the job in this case (even if it is a better language for this sort of tool). JavaScript has a weird ecosystem where it is extremely helpful to have all of your tools in the same language. browser-based IDEs, Node, portability, etc, and just one fewer runtime to juggle. Same reasons why closure is awkward as a Java program.
    • lpw25 12y ago
      OCaml has excellent compile-to-JavaScript support. Facebook use this to compile their Hack type-checker for an in-browser IDE. I imagine they do something similar for Flow.
      • avsm 12y ago
        They do indeed use js_of_ocaml in the Flow test suite to compile the full Flow parser to JavaScript and then test that. See the related discussion on packaging it in the OPAM pull request: https://github.com/ocaml/opam-repository/pull/3083 https://github.com/ocaml/opam-repository/pull/3083
  • uxwtf 12y ago
    OCaml was used for implementation of the Opa framework some years ago https://github.com/MLstate/opalang https://github.com/MLstate/opalang
• eric_bullington 12y ago
  Best 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.
• szx 12y ago
  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)? [1] http://flowtype.org/docs/react-example.html#general-annotation-strategy http://flowtype.org/docs/react-example.html#general-annotati...
• applecore 12y ago
  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?
  • inglor 12y ago
    It doesn't, at least not any more than TypeScript or other compile-to-js languages interact with each other. If CoffeeScript is to support these annotations one day - it would require the CoffeeScript compiler to support them itself in order to generate correct annotated JavaScript for Flow.
• pgroves 12y ago
  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 'funded'?
  • nbm 12y ago
    That is a surprisingly hard question to answer. I think the key is that these projects actually provide value - they make things faster, more reliable, more scalable - whether that's the code's execution or the people writing the code (or debugging issues, or whatever). They generally aren't solutions seeking problems - they are responses to problems that exist. Engineers generally don't build things like this on the weekend - unless they like to structure their time like that, I guess. It may or may not be a full-time job, but the job whatever it is isn't some search for abstract perfection, it is again to solve real problems encountered by others in the company. Often it is a part-time component built as part of trying to solve some more direct goal - like fighting spam, or serving bits, or whatever. Often it is something the engineers just do - it makes sense to break things up into libraries, or services, or whatever, and they do that, and then that library or service is usable/useful elsewhere, and that's it. Other times they may suggest and motivate it as a goal-in-itself in a team goal setting situation. I doubt that's a particularly useful answer, but maybe with further questions I can make it more useful to you?
    • logicalmind 12y ago
      I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help the competition. It does raise the interesting question of whether facebook employees are doing this work just to avoid the work that is the "core competency" of the company. Especially given the fact they don't gain a competitive advantage from releasing the work that facebook paid for into the wild. By this I mean, the company benefit would seem to be attract other talent. And the personal benefit for the devs is to get their name out there are something cool and interesting. Certainly, working on the best way to advertise to users is a lot less exciting/sexy than working on static type checking for javascript.
• quest88 12y ago
  Great work, no doubt. 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'd rather just read "@param x {number}". And at that point, one may as well as use closure.
• slackstation 12y ago
  I wonder, how does this compare to Google'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?
  • dangoor 12y ago
    Dart is a different language with different semantics. It is not the same as JS. Flow starts with JS and adds a static type system (with attempts to infer types directly from the code). With the exception of the type annotations, Flow is JavaScript. Dart is not JavaScript.
  • Havvy 12y ago
    Flow doesn't have any semantic changes from JS, only semantic restrictions. For anything that is not types, Flow defers to JS. Dart defers to it's own specification.
• poxrud 12y ago
  Looks like a great tool. The documentation at http://flowtype.org/ http://flowtype.org/ is excellent. Should be easy to add it to a Gulp/Grunt workflow.
  • SloopJon 12y ago
    I'm confused by the usage of the utility itself. I ran it on the hello.js, and it reported the expected type mismatch. I then tried to run it on the file in the answer sub-directory, but it kept telling me about the previous file.
    • poxrud 12y ago
      That's because it checks every file that has /* @flow */. I'm guessing you're not running it on a specific file but instead on all files in the current dir and sub directories.
• slashnull 12y ago
  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 "class methods", and specializing && JITing the semantically dynamic functions that almost always take as argument "instances" of this "class". (ref this absolutely fascinating paper http://bibliography.selflanguage.org/_static/implementation.pdf http://bibliography.selflanguage.org/_static/implementation.... and this piece of V8 dox quoting the aforementioned paper https://developers.google.com/v8/design https://developers.google.com/v8/design) 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.
  • discreteevent 12y ago
    That's the basic principle Dart is founded on. (hardly surprising when the Dart authors are the same people who did V8)
  • avik 12y ago
    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.
• aliakhtar 12y ago
  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: http://www.gwtproject.org/learnmore-sdk.html http://www.gwtproject.org/learnmore-sdk.html
  • krapp 12y ago
    "Java" which "compiles" to javascript is not Java. It's javascript with a ludicrous amount of syntactic sugar applied.
    • aliakhtar 12y ago
      All the language features of java: generics, inheritance, type safety, interfaces, and soon to come: lambdas and other Java 8 features, are all supported. Plus your code is organized in java packages. So, I'm not sure you've ever tried GWT. Things like multi threading which aren't possible in javascript aren't supported, but a lot of the JRE which is used in most code, does come out of the box. Its a huge improvement over regular javascript, anyway. And client + server code can be shared.
      • krapp 12y ago
        Those are features of the IDE, and of Java, certainly. But type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different. What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't really implement it. I'm not saying it isn't a useful tool, or that the javascript it generates isn't far, far superior to anything I could roll on my own - but... >Things like multi threading which aren't possible in javascript aren't supported ...it isn't Java.
        • aliakhtar 12y ago
          >type safety doesn't really exist in javascript. Structures like interfaces and classes don't really exist. Inheritance is different. Scope is different. You are not coding in javascript. You are coding in java, and the code is then converted into highly efficient javascript by a compiler. > What you have is a javascript framework which emulates the behavior of Java to the degree that javascript permits, but can't really implement it. Absolutely not. You are actually coding in java, and its then compiled to javascript. Have you ever used GWT?
• hippich 12y ago
  Make sure to checkout http://ternjs.net/ http://ternjs.net/ 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. Tern.js actually detect types, and may be it would be possible for eslint to incorporate it somehow to detect invalid use of types. One big ternjs plus for me is the fact that tern.js knows about require.js modules and can look in other require'd files.
  • nilliams 12y ago
    Thanks, I remember seeing this a while back but didn't realise it was RequireJS-aware. The demo is pretty great.
• aikah 12y ago
  I'm really curious about the accuarcy of that tool,really really curious given how javascript "types" work.
  • slashnull 12y ago
    JavaScript actually has a pretty small number of type primitives; I'd say that the bad rap about JS's typing is due to the absolutely mind-boggling type conversion rules (which are nevertheless part of the specification). Even if that wasn't the case, their design just avoids the issue by not trying to do any typecast, ever.
• debacle 12y ago
  Man, I really want to work at Facebook. If only they didn't require relocation.
• gregwebs 12y ago
  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). 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.
  • McKayDavis 12y ago
    I was going to comment that this sounds like an opportunity to get mileage out of the huge amount of typeinfo already provided by DefinitelyTyped by building a tool to convert .d.ts into .d.flow files. After investigating this thought, it looks like this already at the top of the list for future plans for Flow: http://flowtype.org/docs/coming-soon.html http://flowtype.org/docs/coming-soon.html
• zghst 12y ago
  Waiting for more ES6 support! I am spoiled by 6to5.
• leopoldfreeman 12y ago
  Just tried it. Not good for projects depending heavily on 3rd party libs. I have to define all the interfaces in a 'interface file' to keep 'flow' silent. This seems an impossible job for our project.
  • joshkpeterson 12y ago
    It's the same with typescript. The community will take care of most libs over time.
• tadruj 12y ago
  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. And on the side note, I bet Facebook did this just to make nerds install OCaml and show them the light :)
• hyp0 12y ago
  Static types without performance benefits. So far, all popular static type systems have had the performance benefits, so it's unclear how much people value the other benefits (quality and documentation). I wonder which will have the most impact: code quality or types as documentation (esp for tooling)? 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's also usually a mess. Like NN4. But, they seem to be type experts - plus they're using ocaml. Maybe ad hoc by experts is the way to get these ideas adopted?
  • avik 12y ago
    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.
• paulddraper 12y ago
  Similar to the Google Closure Compiler (https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/), which has been around for years, just with fewer features. It has static type checking with optional type annotations and type inference. It doesn't have compiler-time constants, dead code removal, inlining, or other optimizations. But....still really cool.
  • avik 12y ago
    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.)
• hyp0 12y ago
  This looks great, in typesystem/tooling/presentation, and sounds perfect for facebook; but for mainstream adoption, it needs to meet (or be closer to) the ideal of free-benefits: (1) zero-work: works instantly with existing code and esp third party libraries; and (2) instant-benefit: provides some compelling benefit in that zero-work case above (of course, it's OK if it provides more benefit if you do more work, adding type annotations etc).
• hyp0 12y ago
  One of the authors of Flow offered to answer questions, but their comment is greyed out as a dupe (and it isn't a dupe - something went wrong): https://news.ycombinator.com/item?id=8625406 https://news.ycombinator.com/item?id=8625406
  • avik 12y ago
    Haha, yeah Hacker News didn't treat me well yesterday, so I'm trying to go through questions now and reply to them. :) Thanks for noticing!
  • dang 12y ago
    If you see "[dupe]" on a dead comment you can be sure that that is why it was killed. The problem was that there were two identical comments, the software killed one as a dupe, and avik deleted the other one. The software tries to fix this very scenario—it normally would have automatically unkilled the remaining member of the pair. But there are some corner cases where that doesn't work, and avik seems to have outsmarted it. We'll take a look and try to fix the fix.
• smartpants 12y ago
  http://flowtype.org/ http://flowtype.org/ Direct link
• emmanueloga_ 12y ago
  There's some tremendous effort being poured into making a crippled language like javascript usable, but when talking about solutions for maintainable frontend code, I'm more excited about compile-to-js languages like haxe [0], purescript [1] or ceylon [2]. 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/or some escape hatch so you can write javascript manually, for performance tuning or for using 3rd party libs. Even if you do write "raw" 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? BTW, I'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't get rid of. Congrats to the Facebook team for the release! 0: http://haxe.org/ http://haxe.org/ 1: http://purescript.org/ http://purescript.org/ 2: http://ceylon-lang.org/ http://ceylon-lang.org/
  • stonewhite 12y ago
    Last time I said this I was caught but I'll say it again. Nobody really wants to even touch Javascript without a 5 foot stick. People will tell me that it is a good language if you know how to use it, comparing javascript mastery to C mastery in a sense. I think there lies the problem.
  • jbergens 12y ago
    If everybody agreed that most other languages are much better and more productive than javascript then we should have had one of them in the browsers already. And if the problem is just social/organizational then we might never get anything better than javascript, in which case Flow is awesome. I think Dart seems to be a great language and IE, Firefox and Safari should have implemented it years ago, but they didn't. Now I think TypeScript is a great addition to javascript and I hope they build it into the browsers but I suppose they won't (maybe EcmaScript 7 will have some parts of TypeScript in it, or parts from AtScript from Google). By the way, you probably still want minification and concateneted files when you create js from other languages. That stops me from using them, I would have many levels of tools between my source code and the production code.
• phazelift 12y ago
  Static? I use my own type-checking/enforcing lib as a base for everything I write in JS or CS (https://github.com/phazelift/types.js https://github.com/phazelift/types.js). It's only 1.8kb, dynamic and never fails on me.
• sebastianconcpt 12y ago
  Can someone explain in simple words what is the problem that this would fix? I've never felt the need for this, why should I care?
  • DougBTX 12y ago
    It makes it easier to catch some types of bugs without having to run the code. http://en.wikipedia.org/wiki/Type_system#Static_type-checking http://en.wikipedia.org/wiki/Type_system#Static_type-checkin...
    • sebastianconcpt 12y ago
      Thanks, I guess for those who separates runtime from devtime it might be a problem
• Bahamut 12y ago
  Whatever people'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. 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). To contrast this, I have been doing development with Cordova the past week & 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't seem to believe in documenting their libraries well. I will take the JS ecosystem any day when confronted with a choice like that.
  • k__ 12y ago
    "Whatever people's thoughts on the language itself, Java 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. It helps that companies like Google and Oracle 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 GWT, Android, MySQL..."
    • Bahamut 12y ago
      I don't really see the Java ecosystem as comparable - sure, there's a lot of stuff, but I haven't seen nearly as much as in JS.
  • agmcleod 12y ago
    Working on an app recently for Android & iOS. Cordova helped us leverage a lot of existing skills in our team, and definitely made a lot of things easier. Changes not having to be implemented twice per platform for example. But one would run into some really weird bugs, and tricky things to debug now and then. Overall i'd say it was worth it, but hybrid apps definitely have their caveats.