Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Flow still has some better sides:

* first class opaque type support

* exact object type

* correct variance, sound liskov oop

* no transpilation support (/*: */ and /*:: */) - so simple, so powerful; jsdoc ts doesn't compare, you can't import type star, when consuming libraries you have to increase maxNodeModuleJsDepth and other shenanigans; in flow you simply have access to all flow type language; why they don't want to do the same with ts is beyond me, it's like half a day of work to do it?

* nominal types for classes, structural for the rest - as it should be

* correct spread matching runtime behaviour

Flow is under active development. They recently completed ~2 years of work on local type inference which is a big deal. But dev team is not interested in external contributions - quite opposite to how ts development is done.

I did switch to ts as well but do miss above.



Great list!

Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs.

This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwards compat [1].

Though interestingly enough, Flow themselves recently announced they're going to start introducing runtime constructs, which is an interesting plot twist [2].

[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

[2] https://medium.com/flow-type/clarity-on-flows-direction-and-...


In another plot twist TypeScript is supporting the Types as Comments TC39 proposal that would provide a true 0-transpilation workflow.

https://devblogs.microsoft.com/typescript/a-proposal-for-typ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: