6 ms·

After spending a few minutes bouncing around to other discussions trying to figure this out, the answer seems to be something like "Use Flow if you: 1) use JSX,

After spending a few minutes bouncing around to other discussions trying to figure this out, the answer seems to be something like "Use Flow if you: 1) use JSX, or 2) can't be bothered to annotate your code but want a chance of maybe catching some classes of error anyway." Regarding #1, I don't personally like JSX, but a lot of people do, so maybe they should use Flow. It seems likely the TypeScript compiler would barf on code that employs JSX. Regarding #2, I can't see how that will drive any appreciable adoption of this tool. If you care enough to statically analyze your code, you probably care enough to annotate it to get the much stronger safety guarantees that will provide (not to mention other benefits, like "free" self-documentation, and enabling more sophisticated tooling, that have been discussed elsewhere at length). Maybe I've missed an important use case here, but that's what I've been able to piece together since I skimmed the article. And since the author was recently interning on a large React codebase and never mentions TypeScript in the article, I have a feeling he falls into use case #1 above.

mot0rola 12y ago
The TypeScript compiler does indeed barf when it encounters JSX.
yazaddaruvala 12y ago
I mean you seem to discredit "incrementally adding annotations" as a feature. You're correct that anyone that would like to statically analyze a part of their code would want all of it analyzed. However, you're totally disregarding the biggest problem. Large existing code bases. I'm not sure if you've ever had to deal with a large, deployed to production code base, but it doesn't seem like you have. I can tell you there is no way to refactor all of it at once. The only realistic way forward is to refactor a single function, perhaps full file, one at a time.
- antiuniverse 12y ago
  Like skybrian's reply mentioned, I don't think this is actually an area where Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla JavaScript should also readily compile as TypeScript. In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem? [0]: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...
  - xjia 12y ago
    > but ultimately isn't this isomorphic to the halting problem? Take a look at http://matt.might.net/articles/intro-static-analysis/ http://matt.might.net/articles/intro-static-analysis/
    - antiuniverse 12y ago
      Well, it's kind of uncanny how precisely that article addresses my misconceptions at the outset. Thanks for an awesome link (and the related k-CFA article at the bottom).
  - jvilk 12y ago
    > ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail: // error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'. [1, 2, 3].join(4); However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.
- skybrian 12y ago
  Typescript does support incremental conversion, at least according to the talk I saw about it. Most JavaScript files are also valid TypeScript (they say), so starting to use the compiler for your project isn't hard. Also, external libraries can be described with .d.ts files. It didn't sound like migrating a large codebase would be that hard, assuming you have a consensus about doing it.
  - spion 12y ago
    Yes, we converted about 16KLoc from JS to TS in ~1 week. The project was working the entire time during the process (the compiler both reported errors and generated JS files)

mot0rola 12y ago

The TypeScript compiler does indeed barf when it encounters JSX.

yazaddaruvala 12y ago

I mean you seem to discredit "incrementally adding annotations" as a feature. You're correct that anyone that would like to statically analyze a part of their code would want all of it analyzed. However, you're totally disregarding the biggest problem. Large existing code bases. I'm not sure if you've ever had to deal with a large, deployed to production code base, but it doesn't seem like you have. I can tell you there is no way to refactor all of it at once. The only realistic way forward is to refactor a single function, perhaps full file, one at a time.

antiuniverse 12y ago
Like skybrian's reply mentioned, I don't think this is actually an area where Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla JavaScript should also readily compile as TypeScript. In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem? [0]: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...
- xjia 12y ago
  > but ultimately isn't this isomorphic to the halting problem? Take a look at http://matt.might.net/articles/intro-static-analysis/ http://matt.might.net/articles/intro-static-analysis/
  - antiuniverse 12y ago
    Well, it's kind of uncanny how precisely that article addresses my misconceptions at the outset. Thanks for an awesome link (and the related k-CFA article at the bottom).
- jvilk 12y ago
  > ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail: // error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'. [1, 2, 3].join(4); However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.
skybrian 12y ago
Typescript does support incremental conversion, at least according to the talk I saw about it. Most JavaScript files are also valid TypeScript (they say), so starting to use the compiler for your project isn't hard. Also, external libraries can be described with .d.ts files. It didn't sound like migrating a large codebase would be that hard, assuming you have a consensus about doing it.
- spion 12y ago
  Yes, we converted about 16KLoc from JS to TS in ~1 week. The project was working the entire time during the process (the compiler both reported errors and generated JS files)