Flow vs. Typescript • Hacker News Board

Re: Flow vs. Typescript

#31

Post by yuchi » Mon, Jun 06, 2016, 7:32 AM UTC

Hurtak wrote: post #30

greenspot wrote: post #29

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.

Re: Flow vs. Typescript

#32

Post by tkubacki » Mon, Jun 06, 2016, 7:34 AM UTC

smt88 wrote: post #26

tkubacki wrote: post #24

Earlier quoted context omitted.

what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.

> what if further JS will intersect with TS syntax A core value of TypeScript is to support the latest ES20xx standard. The TypeScript team pays attention to JavaScript proposals. In the unlikely event that JavaScript got a type system, it would almost definitely be either TypeScript or Flow. If it wasn't, or if ES standards overlapped with TS syntax, then TS would remove that syntax. Also, if you don't like the next…

"then TS would remove that syntax."

So there is no hard promise of TS backward compatibility ?

Sorry but whole TS looks like another EEE - MS will/can argue on some further JS changes for/against based on existing TS codebase. I hope I'm wrong here though.

Re: Flow vs. Typescript

#33

Post by knocte » Mon, Jun 06, 2016, 7:35 AM UTC

greenspot wrote: post #29

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently:…

Right, that check-list is actually useful in any dynamically-VS-statically typed decision scenario.

Re: Flow vs. Typescript

#34

Post by Matthias247 » Mon, Jun 06, 2016, 7:41 AM UTC

Regarding the first class definition with TS (sayer):

You can shorten the it by declaring the public variable within the constructor: constructor(public this.what: string) {}. Thereby you can eliminate the property declaration as well as the assignment inside the constructor.

And regarding the non-nullable example for Typescript: I think there is an non-implicit-returns option or something similar for the compiler which would have warned you that the function is incomplete. Of course it wouldn't help if you manually return null/undefined (which is valid).

Re: Flow vs. Typescript

#35

Post by robinricard » Mon, Jun 06, 2016, 7:42 AM UTC

Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you just start the project and you use VSCode, TS seems to be a strongest choice. Depends on what you do, but both tools are great, whatever you choose, typechecking is worth in javascript if you need more reliability and maintainability.

Re: Flow vs. Typescript

#36

Post by pjmlp » Mon, Jun 06, 2016, 7:47 AM UTC

sgift wrote: post #6

huuu wrote: post #4

Earlier quoted context omitted.

But programming with comments is bad practice. Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.

That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.

Unfortunately code quality tends to be on the bottom of customer happy list.

I also had the "pleasure" to work in a few projects where it wasn't even on the list, beyond a few powerpoint presentations.

Re: Flow vs. Typescript

#37

Post by michaelwww » Mon, Jun 06, 2016, 7:53 AM UTC

Slide 12 is incorrect. TypeScript does catch this with a "not all control paths return a value"

Re: Flow vs. Typescript

#38

Post by hoodunit » Mon, Jun 06, 2016, 7:56 AM UTC

robinricard wrote: post #35

Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you j…

I actually found the opposite was true in our project - TypeScript was easier to add into the code than Flow. The biggest reason for this was that Flow demands null/undefined checking and null was used extensively throughout this code base. With TypeScript, on the other hand, the changes to make it work initially amounted to sprinkling a few "any" notations and making some explicit object interfaces at various points.

Re: Flow vs. Typescript

#39

Post by Hurtak » Mon, Jun 06, 2016, 7:57 AM UTC

I heard somewhere, that TS class syntax diverged somewhat from the spec. Can anybody who has insight into the TS tell me what the situation is?

Re: Flow vs. Typescript

#40

Post by hoodunit » Mon, Jun 06, 2016, 8:07 AM UTC

solomatov wrote: post #5

The best things about flow which typescript doesn't have is sound typesystem. I hope typescript will adopt it at some point in time.

One area in which Flow may be "technically" sound but it feels illogical is how in how it infers certain types. TypeScript requires that a variable has one type that doesn't change, but Flow will infer multiple types for a variable at different points in the code depending on how it is used. Also because Flow infers types based on how they are used, there are some interesting situations where you would expect the type checker to complain but it doesn't. E.g. if you have an object with a field that is never used, Flow won't complain about the field even if it is not defined in the type of the object. Overall I feel like TypeScript enforces logical, opinionated defaults, while Flow is happier to go with the illogical structure of your own usage (while enforcing opinionated defaults in other areas like null-checking).