Comment by antiuniverse | Hacker News Reader

Comment by antiuniverse | Hacker News Reader

Parent Full thread

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.

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.

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.

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)

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-...

> but ultimately isn't this isomorphic to the halting problem?

Take a look at http://matt.might.net/articles/intro-static-analysis/

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).

> ...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.

The TypeScript compiler does indeed barf when it encounters JSX.

Reply on news.ycombinator.com