4 ms·

I'm a huge Flow fan, and picked it over TypeScript because at the time I didn't like the idea of: - Switching everything to .ts and .tsx files - Switching a l

I'm a huge Flow fan, and picked it over TypeScript because at the time I didn't like the idea of: - Switching everything to .ts and .tsx files - Switching a lot of tooling (TypeScript's built-in ES6 transpiler instead of Babel, tslint instead of eslint, etc.) - At the time, TypeScript's types were nullable, Flow's were non-nullable, which makes a huge difference to me - Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators) That said, some of the errors from Flow can be incredibly confusing, and even with the latest versions I feel like there's improvement which needs to be made here. This (in my view) is the number one thing it needs to drive adoption.

bcherny 9y ago
I went through a similar process and chose TS > Flow. - Renaming to .ts and .tsx is nicer than adding comments, because it integrates better with tooling (compile all files that end with .ts) and it's easier to see at a glance what's ported - You can always compile TS to ES2018 and run that through Babel, if you like. TSLint -> ESLint is indeed a change, though you can continue to use most of ESLint for TS [0] - As a rule, TS is compile time only. There are a few exceptions, but that's almost always the case. For me the advantages of TS are: - Huge library of community written typings for JS libs - Mapped types - Full support for literal types - Read only types That said, I really like Flow's co/contravariance annotations, and the corresponding $Supertype and $Subtype functions. That, and nominal typing can be really convenient (coming to TS soon, hopefully). [0] https://github.com/eslint/typescript-eslint-parser https://github.com/eslint/typescript-eslint-parser
- nothrabannosir 9y ago
  > As a rule, TS is compile time only. There are a few exceptions Sorry just for my information: which ones are those?
  - charrondev 9y ago
    I'm pretty sure generators need a runtime component. TS supports them down to ES3. Async/await gets transformed to generators too afaik.
    - nothrabannosir 9y ago
      The typescript compiler is a type checker and a cross-JS-version transpiler in one. Runtime code introduced to support generators in lower ES versions isn't exactly the same as the type system needing a runtime component. It's more like "the Babel part" which is included in TS. I personally don't think it's an attractive part of TS; it's confusing, and it's just duplicating efforts that Babel already does best. But that's just me.
- klibertp 9y ago
  > That, and nominal typing can be really convenient (coming to TS soon, hopefully). I think you meant structural typing? TS was always nominally typed. I searched for a bit and it looks like TS also supports structural typing with explicit interfaces, and I think Flow tries to infer such types? I don't use either one, so I'm not sure about the details.
  - cowmoo728 9y ago
    TS is structurally typed. You declare the fields you expect on a type or interface, and as long as an object has at least those fields, it will typecheck. Nominal typing would mean that you could declare type A and type B with identical fields, but if something is declared as A, it cannot be used in place of B. TS has a strange workaround to get nominal typing for now: https://basarat.gitbooks.io/typescript/docs/tips/nominalTyping.html https://basarat.gitbooks.io/typescript/docs/tips/nominalTypi...
    - klibertp 9y ago
      That's interesting - I'm almost sure last time I checked (possibly a couple years back) TS used nominal typing. Do you know if this changed at some point, or is it just my memory being bad?
      - RyanCavanaugh 9y ago
        TypeScript has used structural typing since the beginning. Classes used to be nominal, but changed to structural (except for classes with private fields) at some point.
        klibertp 9y ago
        > Classes used to be nominal, but changed to structural Ah, ok, makes sense. I think I was last looking at TS around version 1.1 or something like that. Thanks!
lewisl9029 9y ago
> Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators) This is a huge part of why I tend to prefer Flow for my projects these days as well. I really value the fact that Flow is just a thin layer of static type annotations you place on top of your spec-compliant JavaScript, and none of its features have any chance of introducing unexpected runtime behavior. Also, I'd like to add that using Flow with Babel transpilation targeting a ES20xx preset largely guarantees that the source code you're writing is valid spec-compliant JavaScript that can run without transpilation one day (requiring only a dead-simple type-stripping transform using something like https://www.npmjs.com/package/babel-plugin-transform-flow-strip-types https://www.npmjs.com/package/babel-plugin-transform-flow-st... or https://github.com/flowtype/flow-remove-types https://github.com/flowtype/flow-remove-types), and I've had great success with simply dropping all/parts of the transpilation step as the features I use start to become supported in node/browsers/react-native/electron/runtime-polyfills/etc for apps where I don't plan on supporting browsers more than a few versions behind latest, which has been an absolute godsend for debugging in both development and production. I highly encourage people to try it out on a project where they can afford to do the same (i.e. for packaged projects where you have control over the runtime environment like Electron or React Native, or for web projects where most of your users happen to be also web developers). It's really been a breath of fresh air after dealing with all sorts of subtle transpilation induced bugs/edge-cases. To be clear, I'm not trying to bash TypeScript, because it's an awesome project, with top-class tooling that has attracted an amazing community around it. I just wanted to remind all the people mindlessly shouting "TypeScript has won" into their own silos, that Flow is also a great type system, that just happens to be designed with a fundamentally different set of trade-offs in mind. That alone doesn't make either system better or worse than the other, but it does mean there are use cases where Flow can excel over TypeScript and vice versa, and that you should carefully consider your project's needs and what characteristics you value in a type system before simply cargo-culting one or the other.
- esamatti 9y ago
  This is possible with Typescript too with Babel 7. See my comment here https://news.ycombinator.com/item?id=15236089 https://news.ycombinator.com/item?id=15236089

bcherny 9y ago

I went through a similar process and chose TS > Flow. - Renaming to .ts and .tsx is nicer than adding comments, because it integrates better with tooling (compile all files that end with .ts) and it's easier to see at a glance what's ported - You can always compile TS to ES2018 and run that through Babel, if you like. TSLint -> ESLint is indeed a change, though you can continue to use most of ESLint for TS [0] - As a rule, TS is compile time only. There are a few exceptions, but that's almost always the case. For me the advantages of TS are: - Huge library of community written typings for JS libs - Mapped types - Full support for literal types - Read only types That said, I really like Flow's co/contravariance annotations, and the corresponding $Supertype and $Subtype functions. That, and nominal typing can be really convenient (coming to TS soon, hopefully). [0] https://github.com/eslint/typescript-eslint-parser https://github.com/eslint/typescript-eslint-parser

nothrabannosir 9y ago
> As a rule, TS is compile time only. There are a few exceptions Sorry just for my information: which ones are those?
- charrondev 9y ago
  I'm pretty sure generators need a runtime component. TS supports them down to ES3. Async/await gets transformed to generators too afaik.
  - nothrabannosir 9y ago
    The typescript compiler is a type checker and a cross-JS-version transpiler in one. Runtime code introduced to support generators in lower ES versions isn't exactly the same as the type system needing a runtime component. It's more like "the Babel part" which is included in TS. I personally don't think it's an attractive part of TS; it's confusing, and it's just duplicating efforts that Babel already does best. But that's just me.
klibertp 9y ago
> That, and nominal typing can be really convenient (coming to TS soon, hopefully). I think you meant structural typing? TS was always nominally typed. I searched for a bit and it looks like TS also supports structural typing with explicit interfaces, and I think Flow tries to infer such types? I don't use either one, so I'm not sure about the details.
- cowmoo728 9y ago
  TS is structurally typed. You declare the fields you expect on a type or interface, and as long as an object has at least those fields, it will typecheck. Nominal typing would mean that you could declare type A and type B with identical fields, but if something is declared as A, it cannot be used in place of B. TS has a strange workaround to get nominal typing for now: https://basarat.gitbooks.io/typescript/docs/tips/nominalTyping.html https://basarat.gitbooks.io/typescript/docs/tips/nominalTypi...
  - klibertp 9y ago
    That's interesting - I'm almost sure last time I checked (possibly a couple years back) TS used nominal typing. Do you know if this changed at some point, or is it just my memory being bad?
    - RyanCavanaugh 9y ago
      TypeScript has used structural typing since the beginning. Classes used to be nominal, but changed to structural (except for classes with private fields) at some point.
      - klibertp 9y ago
        > Classes used to be nominal, but changed to structural Ah, ok, makes sense. I think I was last looking at TS around version 1.1 or something like that. Thanks!

lewisl9029 9y ago

> Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators) This is a huge part of why I tend to prefer Flow for my projects these days as well. I really value the fact that Flow is just a thin layer of static type annotations you place on top of your spec-compliant JavaScript, and none of its features have any chance of introducing unexpected runtime behavior. Also, I'd like to add that using Flow with Babel transpilation targeting a ES20xx preset largely guarantees that the source code you're writing is valid spec-compliant JavaScript that can run without transpilation one day (requiring only a dead-simple type-stripping transform using something like https://www.npmjs.com/package/babel-plugin-transform-flow-strip-types https://www.npmjs.com/package/babel-plugin-transform-flow-st... or https://github.com/flowtype/flow-remove-types https://github.com/flowtype/flow-remove-types), and I've had great success with simply dropping all/parts of the transpilation step as the features I use start to become supported in node/browsers/react-native/electron/runtime-polyfills/etc for apps where I don't plan on supporting browsers more than a few versions behind latest, which has been an absolute godsend for debugging in both development and production. I highly encourage people to try it out on a project where they can afford to do the same (i.e. for packaged projects where you have control over the runtime environment like Electron or React Native, or for web projects where most of your users happen to be also web developers). It's really been a breath of fresh air after dealing with all sorts of subtle transpilation induced bugs/edge-cases. To be clear, I'm not trying to bash TypeScript, because it's an awesome project, with top-class tooling that has attracted an amazing community around it. I just wanted to remind all the people mindlessly shouting "TypeScript has won" into their own silos, that Flow is also a great type system, that just happens to be designed with a fundamentally different set of trade-offs in mind. That alone doesn't make either system better or worse than the other, but it does mean there are use cases where Flow can excel over TypeScript and vice versa, and that you should carefully consider your project's needs and what characteristics you value in a type system before simply cargo-culting one or the other.

esamatti 9y ago
This is possible with Typescript too with Babel 7. See my comment here https://news.ycombinator.com/item?id=15236089 https://news.ycombinator.com/item?id=15236089