8 ms·

I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing defini

I know this probably comes up each typescript thread, but I still cannot figure out why I should use TS instead of flow + es6, and maintaining the typing definitions always discourages me as it's one more thing that needs to be kept up to date. Am I working on old information here?

Nemcue 10y ago
Why would flow + es6 be better?
- MehdiHK 10y ago
  Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
  - treehau5 10y ago
    Also, you can progressively opt in to add typing information, while still getting most of the benefits without.
    - whatever_dude 10y ago
      The same can be done with TypeScript. Type inference has been added to it in 2015.
      - treehau5 10y ago
        Awesome, did not know this.
      - shados 10y ago
        TypeScript type inference is minimal though and doesn't go very far. It falls back to "any" very quickly (and if you use the noImplicitAny option, then you have to type almost everything). It does a decent enough job at return types, but not a whole lot beyond that.
        whatever_dude 10y ago
        Do you have a use case where something would be correctly inferred in Flow but not in TS?
        dsp1234 10y ago
        The classic example is: function double(x) { return x * 2; } const result = double("foo"); Which passes in TS, but fails in Flow. In TS, the 'x' parameter to the double function is inferred as Any.
  - dangoor 10y ago
    TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.
    - MehdiHK 10y ago
      But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.
      - eknkc 10y ago
        With target esnext, it produces almost the same output with some spacing differences. Sans the annotations obviously.
      - Rapzid 10y ago
        Your equivalence with transpiling coffeescript is false. TS doesn't really have "syntactic sugars". Just about everything in it(less the types of course) is pretty far along in the ES adoption process. There are a couple exceptions like decorators that are called out in a very visible manner. If you target ES6 your code may look identical. Even much of the ES5 down leveling produced code that looks like a person wrote it. I converted a 10k line coffeescript project(with async/await !) to JS and then TypeScript. The similarities are so far apart they might as well be in different dimensions. But, if you don't want to take a rando posters word for it, it's pretty easy to make a little sample project and see if the output is to your liking.
      - whatever_dude 10y ago
        > Same cannot be said about typescript considering various language features and syntactic sugar TS offers I think you're vastly misinterpreting what TS is. It's not anything like CoffeeScript. It's JS plus types and a few other features like Interfaces or advanced ECMAScript features when targetting older versions of the standard. If you strip away types by exporting to your ECMAScript target of choice, you'll get real JavaScript with the same style as it was written in TypeScript. It's exactly the same thing you'd get with Flow in that sense. The only additional code you'd get would be for polyfills, but a) those are minimal and b) those will only appear if you export to an older ECMAScript version than the one you wrote it in. There is no vendor lock.
  - whatever_dude 10y ago
    That's an objectively incorrect assertion if you're applying that to TypeScript. The same can be done to it that would be done to Flow: you can just either strip types manually, or just do a single export to your ECMAScripttarget of choice. It'll be native JavaScript. Even the little shims/polyfills it does (to support older ECMAScript versions if you wish to export to it) are optional and can be disabled.
    - mohamedhegazy 10y ago
      TypeScript has `--target ESNext` this will strip out any TypeScript-specific type annotations, and leave you with standard-track-only JS code that looks identical to your input (modulo type annotations).
  - icholy 10y ago
    > Avoid vendor locking. It's open source. > you can just strip all type annotations with Babel and move on. Are you implying that this isn't possible with TypeScript?
  - dsp1234 10y ago
    If you're afraid of vendor lock-in, but fine with comments then you can just put all of your typing information in jsdoc comments. https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...
  - hzoo 10y ago
    FYI we do have an issue open about TS https://github.com/babel/babylon/issues/320 https://github.com/babel/babylon/issues/320 so that we could eventually support TS in Babel as a plugin and then create the same strip-types-plugin just like Flow.
- davesnothere 10y ago
  One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.
  - WorldMaker 10y ago
    Typescript and Babel play well together, too.
    - Rapzid 10y ago
      Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.
      - vivainio 10y ago
        Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.
        johnny_reilly 10y ago
        It's very useful if you want to use native APIs that arrived with es6: Promise, Map etc. TypeScript doesn't shim those
        mercer 10y ago
        I've had some major headaches getting TypeScript to work with Babel and Webpack 2. The main reason I had to use Babel was because I wanted to use Webpack 2's tree shaking feature. Do you know if it's possible to use just TypeScript and Webpack without Babel, and still take advantage of tree shaking? Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking). Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny. I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).
- treehau5 10y ago
  - You are writing javascript, not typescript. - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. - flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project. - flow fits nicely into existing popular js tooling, mainly babel and react. - no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
  - whatever_dude 10y ago
    At the risk of probably repeating myself, allow me to give my $0.02: > - You are writing javascript, not typescript. Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx. > - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. True, although IMO the greatest feature of TS is making your code stronger, not compiling things that are already part of some ECMAScript version. >- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project. True, with TS it's more of a lateral move rather than drops here and there. >- flow fits nicely into existing popular js tooling, mainly babel and react. TS works just as well; better, IMO, because dev tools (editors, linters) have better TS support in my experience. Writing React in JS to me makes me feel like I'm using Notepad since there's so much TS helps me with that is lost when using a purely dynamic language. >- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know. It does compile to pure JS so ejecting TS is easy; it's trying to follow future standards and proposed changes, not create something different; the project is open source. There is no vendor lock in.
    - 10y ago
WorldMaker 10y ago
With the last release (2.1) maintaining typing definitions is mostly as optional as Flow, because TS now just assumes imports it cannot find are `any` type. A lot of typings are now directly inside the NPM packages of the libraries themselves and install "automatically" for you; many other typings can be searched on NPM (primarily the @types/ scope).
whatever_dude 10y ago
I'm not sure this answers your question, but: I've been working with TS for the past couple of years but now I'm working on a Flow project. Flow doesn't even compare. It falls short on many things TS would immediately flag, and just feels less thought-out (subjective I know). Tooling support is terrible and while not the language's fault, it means it just doesn't help you as much as it could. Using Flow basically becomes an afterthought, a part of your build step, while with TS it's much easier to have that integrated into your development flow (via your editor of choice). And honestly, some of the decisions around the language just feel strange. Not knowing what kind of bool to use [0] is pretty emblematic of where it is going as a language. To me Flow is just half-helping in a way that TS is fully devoted to. [0] http://stackoverflow.com/questions/40618817/flow-bool-boolean-and-boolean http://stackoverflow.com/questions/40618817/flow-bool-boolea...
- damncabbage 10y ago
  > It falls short on many things TS would immediately flag I'm kind of curious what you've run into personally. Having a dependency without any type-defs get silently treated as `any` is my own beef, but I haven't hit much else yet. (Some type-defs' use for `any` also gets my goat, such as Promise's catch argument and some of the lodash functions, but I'm considering that a separate thing.) > And honestly, some of the decisions around the language just feel strange. Not knowing what kind of bool to use [0] is pretty emblematic of where it is going as a language. This is more an existing JS weirdness (`true`/`false` vs `Boolean()`); Flow doesn't mess with runtime semantics, only adding a layer that you check with then strip out. And TypeScript has the same thing: var a: boolean = new Boolean(1); // Produces: // NewTypering.ts(29,5): error TS2322: Type 'Boolean' is not assignable to type 'boolean'.
  - DanRosenwasser 10y ago
    TypeScript's full error message on that last one is actually Type 'Boolean' is not assignable to type 'boolean'. 'boolean' is a primitive, but 'Boolean' is a wrapper object. Prefer using 'boolean' when possible.
  - WorldMaker 10y ago
pixie_ 10y ago
I don't get the 'maintaining type definitions is hard' argument. It's super easy to do, especially when coupled with typewriter which will automatically generate types for your server side DTOs. Also having typings saves you an incredible amount of time with fast refactoring, auto-complete, and of course the type checking which saves countless hours of debugging the dumbest mistakes. When you start talking about getting into code bases that you didn't personally write. The time savings and productivity benefits that TypeScript brings are immense.
shp0ngle 10y ago
I like Flow and I am actually using it right now, but I also see some negatives It still feels like very much in beta. Things break often along the edges, there are things like interfaces that work only sometimes, the modules are always working strangely Also, and that might be a personal thing, but for me, TypeScript itself has a more readable source code, since it's in TypeScript. Flow is in OCaml, which I cannot read. On the other hand, I like how Flow is very "thin", and how I am just using ES6 with types "hints" on top; that's why I prefer Flow.
shados 10y ago
I've done some average sized projects in Flow and in TypeScript, and it's a lot more subtle IMO than most people would have it (especially people who only tried one, or only tried both cursively) TypeScript absolutely has the better tooling. It's not even -close-. It's a little tricky though because a lot of FE devs these days use VIM or Sublime with a few plugins and a linter running in a terminal is as far as it goes, so explaining the importance of proper refactoring tool and semantic search is tough (no, using grep/ag/ack is not enough in a large code base, no matter how good you are with them). On the other hand, the Flow checker is a lot more interesting, with more advanced call site analysis, and the type inference follows types a lot further (where you can type an entire file without any annotations, though Flow does require them on exports if you want imports in other files to be typed). That means functions with no annotations are much more frequently type checked and it's more useful during prototyping. Flow is also a bit more careful about putting on the C#/Java lipstick (neither Flow nor TypeScript are actually java/C#-like, being much more functional and using structural typing as first class citizens, but TypeScript definitely LOOK the part to the untrained eyes, which makes developers used with those languages try to use the same patterns and heavily abuse classes instead of union types, etc. In Flow it's less of an issue). Flow definitely causes a lot more surprises: call site analysis means error messages can be more confusing, and certain cases like inaccessible code path can cause some surprising scenarios. flow-typed has many less type definitions, but they're generally higher quality. TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. You also have issues with useStrictNull not having been there all along causing problems. TypeScript however benefits heavily from having more libraries being native TypeScript, which is better than having good type definitions. Finally, while TypeScript's tooling is vastly superior, Flow has the benefit of being parsable by Babel via Babylon, making large parts of the ecosystem a lot more Flow friendly. This came up recently with the amazing Prettier project being a non-starter for TypeScript users. I've been hopping between vanilla JS, Flow and TypeScript continually...and no matter which one I use, I wish I was using another.
- anonova 10y ago
  > TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. I've always found it funny that DefinitelyTyped's tag line is "The repository for high quality TypeScript type definitions", but it's an absolutely disastrous system. If it's not a well-used library, definitions there will be woefully out of date. Versioning is a huge issue with it, so it's hard to figure out what definitions actually match the version library you're using. I can only admit that it's an effort that's better than nothing. The few projects I added types to, the original project owners gladly accepted them into their main repos, which is great since types will "just work" without fuddling with @types packages.
danmaz74 10y ago
Talking about flow, I was wondering: couldn't something like that be implemented just with comments, leaving us with actually 100% valid javascript? Eg: // @param somestring [String] yadda yadda // @return [Boolean] function somefunction(somestring) { // @type [Boolean] var ret; ... return ret; } This would remove any type of "lock in" if you want to use it...
- xymostech 10y ago
  Flow actually explicitly allows this[1] by just /* */ commenting out the flow type signatures. We use this in Aphrodite's code base[2] and it works pretty well. [1]: https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html [2]: https://github.com/Khan/aphrodite/blob/master/src/generate.js#L139 https://github.com/Khan/aphrodite/blob/master/src/generate.j...
- insin 10y ago
  I'd prefer that approach too, as I can also document things at the same time as providing type annotations; flow-jsdoc looks interesting, but I don't know how easy it would be to plug into a Babel/Webpack+Babel workflow: https://github.com/Kegsay/flow-jsdoc https://github.com/Kegsay/flow-jsdoc
  - damncabbage 10y ago
    There's also comments support in Flow directly, but it's sadly (but understandably) hideous: function somefunction(somestring/*: string*/)/*: boolean */ { var ret/*: boolean */; ... return ret; } (See https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html)
  - Lio 10y ago
    Might be worth pointing out, the "documentation" package[1] can be used to generate jsdoc annotations suitable for Google Closure compiler from Flow type annotations. It can also build really nice HTML documentation to. [1] https://www.npmjs.com/package/documentation https://www.npmjs.com/package/documentation
mullsork 10y ago
My biggest gripe with Flow is how buggy it is. 1. it often fails to find the type for an imported piece of code 2. more often than not refers to the type definition being a problem rather than whoever's calling a function with an incorrect type 3. it seems to have an issue with cache busting(?) (I `killall flow` multiple times per day to make sure it's not complaining about old code) All in all I feel very sad for choosing Flow over TypeScript two weeks ago. We felt TS would be more invasive to our Webpack pipeline but I think I might just take a weekend to migrate over to TS... TS seems to have a lot more type definitions available as well, a more active community perhaps? Looking at the issue list of Flow I'm starting to suspect they're not very active in maintenance / issue handling. TS seems much more active.
nullxone 10y ago
Here's all the things. https://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/ https://djcordhose.github.io/flow-vs-typescript/flow-typescr...

Nemcue 10y ago

Why would flow + es6 be better?

MehdiHK 10y ago
Avoid vendor locking. Someday in near future if you don't like flow anymore, you can just strip all type annotations with Babel and move on. You are not risking ending up like coffeescript.
- treehau5 10y ago
  Also, you can progressively opt in to add typing information, while still getting most of the benefits without.
  - whatever_dude 10y ago
    The same can be done with TypeScript. Type inference has been added to it in 2015.
    - treehau5 10y ago
      Awesome, did not know this.
    - shados 10y ago
      TypeScript type inference is minimal though and doesn't go very far. It falls back to "any" very quickly (and if you use the noImplicitAny option, then you have to type almost everything). It does a decent enough job at return types, but not a whole lot beyond that.
      - whatever_dude 10y ago
        Do you have a use case where something would be correctly inferred in Flow but not in TS?
        dsp1234 10y ago
        The classic example is: function double(x) { return x * 2; } const result = double("foo"); Which passes in TS, but fails in Flow. In TS, the 'x' parameter to the double function is inferred as Any.
- dangoor 10y ago
  TypeScript compiles to JS in a straightforward manner as well. If you wanted to move away from TS, you could simply have the TS compiler compile to ES6 and you're done.
  - MehdiHK 10y ago
    But that'd still be transpiled code, right? After getting rid of flow it will be exactly same minus the type annotations. Same cannot be said about typescript considering various language features and syntactic sugar TS offers. Will it run? Yes. Will it feel that it was written by me? That depends.
    - eknkc 10y ago
      With target esnext, it produces almost the same output with some spacing differences. Sans the annotations obviously.
    - Rapzid 10y ago
      Your equivalence with transpiling coffeescript is false. TS doesn't really have "syntactic sugars". Just about everything in it(less the types of course) is pretty far along in the ES adoption process. There are a couple exceptions like decorators that are called out in a very visible manner. If you target ES6 your code may look identical. Even much of the ES5 down leveling produced code that looks like a person wrote it. I converted a 10k line coffeescript project(with async/await !) to JS and then TypeScript. The similarities are so far apart they might as well be in different dimensions. But, if you don't want to take a rando posters word for it, it's pretty easy to make a little sample project and see if the output is to your liking.
    - whatever_dude 10y ago
      > Same cannot be said about typescript considering various language features and syntactic sugar TS offers I think you're vastly misinterpreting what TS is. It's not anything like CoffeeScript. It's JS plus types and a few other features like Interfaces or advanced ECMAScript features when targetting older versions of the standard. If you strip away types by exporting to your ECMAScript target of choice, you'll get real JavaScript with the same style as it was written in TypeScript. It's exactly the same thing you'd get with Flow in that sense. The only additional code you'd get would be for polyfills, but a) those are minimal and b) those will only appear if you export to an older ECMAScript version than the one you wrote it in. There is no vendor lock.
- whatever_dude 10y ago
  That's an objectively incorrect assertion if you're applying that to TypeScript. The same can be done to it that would be done to Flow: you can just either strip types manually, or just do a single export to your ECMAScripttarget of choice. It'll be native JavaScript. Even the little shims/polyfills it does (to support older ECMAScript versions if you wish to export to it) are optional and can be disabled.
  - mohamedhegazy 10y ago
    TypeScript has `--target ESNext` this will strip out any TypeScript-specific type annotations, and leave you with standard-track-only JS code that looks identical to your input (modulo type annotations).
- icholy 10y ago
  > Avoid vendor locking. It's open source. > you can just strip all type annotations with Babel and move on. Are you implying that this isn't possible with TypeScript?
- dsp1234 10y ago
  If you're afraid of vendor lock-in, but fine with comments then you can just put all of your typing information in jsdoc comments. https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...
- hzoo 10y ago
  FYI we do have an issue open about TS https://github.com/babel/babylon/issues/320 https://github.com/babel/babylon/issues/320 so that we could eventually support TS in Babel as a plugin and then create the same strip-types-plugin just like Flow.
davesnothere 10y ago
One reason flow might be considered "better" (context is key) is that it plays well with the babel ecosystem, letting one pick and choose their language features.
- WorldMaker 10y ago
  Typescript and Babel play well together, too.
  - Rapzid 10y ago
    Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.
    - vivainio 10y ago
      Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.
      - johnny_reilly 10y ago
        It's very useful if you want to use native APIs that arrived with es6: Promise, Map etc. TypeScript doesn't shim those
      - mercer 10y ago
        I've had some major headaches getting TypeScript to work with Babel and Webpack 2. The main reason I had to use Babel was because I wanted to use Webpack 2's tree shaking feature. Do you know if it's possible to use just TypeScript and Webpack without Babel, and still take advantage of tree shaking? Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking). Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny. I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).
treehau5 10y ago
- You are writing javascript, not typescript. - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. - flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project. - flow fits nicely into existing popular js tooling, mainly babel and react. - no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know.
- whatever_dude 10y ago
  At the risk of probably repeating myself, allow me to give my $0.02: > - You are writing javascript, not typescript. Flow's and TypeScript's distance to JS world are the same, and are very similar in most cases. If you want to add type to one, it's the same as in the other. The only difference here is the file extension, since TS tends to like .ts/.tsx. > - When typescript came out, I was an early adopter, and a lot of it's touted benefits were the class-like syntax and constructors to make it more palatable to enterprise shops (not for me, but it was easier to sell to higher ups), this is mostly a moot point now. True, although IMO the greatest feature of TS is making your code stronger, not compiling things that are already part of some ECMAScript version. >- flow can be attached to any codebase as the codebase stands easily. It is, I have found, difficult to bring TS into an existing project. True, with TS it's more of a lateral move rather than drops here and there. >- flow fits nicely into existing popular js tooling, mainly babel and react. TS works just as well; better, IMO, because dev tools (editors, linters) have better TS support in my experience. Writing React in JS to me makes me feel like I'm using Notepad since there's so much TS helps me with that is lost when using a purely dynamic language. >- no risk of vendor lock in. Maybe TS compiles to pure 100% syntactically correct javascript today, maybe it doesn't in the future. It isn't javascript, so I won't know. It does compile to pure JS so ejecting TS is easy; it's trying to follow future standards and proposed changes, not create something different; the project is open source. There is no vendor lock in.
  - 10y ago

WorldMaker 10y ago

With the last release (2.1) maintaining typing definitions is mostly as optional as Flow, because TS now just assumes imports it cannot find are `any` type. A lot of typings are now directly inside the NPM packages of the libraries themselves and install "automatically" for you; many other typings can be searched on NPM (primarily the @types/ scope).

whatever_dude 10y ago

I'm not sure this answers your question, but: I've been working with TS for the past couple of years but now I'm working on a Flow project. Flow doesn't even compare. It falls short on many things TS would immediately flag, and just feels less thought-out (subjective I know). Tooling support is terrible and while not the language's fault, it means it just doesn't help you as much as it could. Using Flow basically becomes an afterthought, a part of your build step, while with TS it's much easier to have that integrated into your development flow (via your editor of choice). And honestly, some of the decisions around the language just feel strange. Not knowing what kind of bool to use [0] is pretty emblematic of where it is going as a language. To me Flow is just half-helping in a way that TS is fully devoted to. [0] http://stackoverflow.com/questions/40618817/flow-bool-boolean-and-boolean http://stackoverflow.com/questions/40618817/flow-bool-boolea...

damncabbage 10y ago
> It falls short on many things TS would immediately flag I'm kind of curious what you've run into personally. Having a dependency without any type-defs get silently treated as `any` is my own beef, but I haven't hit much else yet. (Some type-defs' use for `any` also gets my goat, such as Promise's catch argument and some of the lodash functions, but I'm considering that a separate thing.) > And honestly, some of the decisions around the language just feel strange. Not knowing what kind of bool to use [0] is pretty emblematic of where it is going as a language. This is more an existing JS weirdness (`true`/`false` vs `Boolean()`); Flow doesn't mess with runtime semantics, only adding a layer that you check with then strip out. And TypeScript has the same thing: var a: boolean = new Boolean(1); // Produces: // NewTypering.ts(29,5): error TS2322: Type 'Boolean' is not assignable to type 'boolean'.
- DanRosenwasser 10y ago
  TypeScript's full error message on that last one is actually Type 'Boolean' is not assignable to type 'boolean'. 'boolean' is a primitive, but 'Boolean' is a wrapper object. Prefer using 'boolean' when possible.
- WorldMaker 10y ago

pixie_ 10y ago

I don't get the 'maintaining type definitions is hard' argument. It's super easy to do, especially when coupled with typewriter which will automatically generate types for your server side DTOs. Also having typings saves you an incredible amount of time with fast refactoring, auto-complete, and of course the type checking which saves countless hours of debugging the dumbest mistakes. When you start talking about getting into code bases that you didn't personally write. The time savings and productivity benefits that TypeScript brings are immense.

shp0ngle 10y ago

I like Flow and I am actually using it right now, but I also see some negatives It still feels like very much in beta. Things break often along the edges, there are things like interfaces that work only sometimes, the modules are always working strangely Also, and that might be a personal thing, but for me, TypeScript itself has a more readable source code, since it's in TypeScript. Flow is in OCaml, which I cannot read. On the other hand, I like how Flow is very "thin", and how I am just using ES6 with types "hints" on top; that's why I prefer Flow.

shados 10y ago

I've done some average sized projects in Flow and in TypeScript, and it's a lot more subtle IMO than most people would have it (especially people who only tried one, or only tried both cursively) TypeScript absolutely has the better tooling. It's not even -close-. It's a little tricky though because a lot of FE devs these days use VIM or Sublime with a few plugins and a linter running in a terminal is as far as it goes, so explaining the importance of proper refactoring tool and semantic search is tough (no, using grep/ag/ack is not enough in a large code base, no matter how good you are with them). On the other hand, the Flow checker is a lot more interesting, with more advanced call site analysis, and the type inference follows types a lot further (where you can type an entire file without any annotations, though Flow does require them on exports if you want imports in other files to be typed). That means functions with no annotations are much more frequently type checked and it's more useful during prototyping. Flow is also a bit more careful about putting on the C#/Java lipstick (neither Flow nor TypeScript are actually java/C#-like, being much more functional and using structural typing as first class citizens, but TypeScript definitely LOOK the part to the untrained eyes, which makes developers used with those languages try to use the same patterns and heavily abuse classes instead of union types, etc. In Flow it's less of an issue). Flow definitely causes a lot more surprises: call site analysis means error messages can be more confusing, and certain cases like inaccessible code path can cause some surprising scenarios. flow-typed has many less type definitions, but they're generally higher quality. TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. You also have issues with useStrictNull not having been there all along causing problems. TypeScript however benefits heavily from having more libraries being native TypeScript, which is better than having good type definitions. Finally, while TypeScript's tooling is vastly superior, Flow has the benefit of being parsable by Babel via Babylon, making large parts of the ecosystem a lot more Flow friendly. This came up recently with the amazing Prettier project being a non-starter for TypeScript users. I've been hopping between vanilla JS, Flow and TypeScript continually...and no matter which one I use, I wish I was using another.

anonova 10y ago
> TypeScript's type definitions I found are very, very poor, as a relic of the days where versioning was an issue and many have not been fixed. I've always found it funny that DefinitelyTyped's tag line is "The repository for high quality TypeScript type definitions", but it's an absolutely disastrous system. If it's not a well-used library, definitions there will be woefully out of date. Versioning is a huge issue with it, so it's hard to figure out what definitions actually match the version library you're using. I can only admit that it's an effort that's better than nothing. The few projects I added types to, the original project owners gladly accepted them into their main repos, which is great since types will "just work" without fuddling with @types packages.

danmaz74 10y ago

Talking about flow, I was wondering: couldn't something like that be implemented just with comments, leaving us with actually 100% valid javascript? Eg: // @param somestring [String] yadda yadda // @return [Boolean] function somefunction(somestring) { // @type [Boolean] var ret; ... return ret; } This would remove any type of "lock in" if you want to use it...

xymostech 10y ago
Flow actually explicitly allows this[1] by just /* */ commenting out the flow type signatures. We use this in Aphrodite's code base[2] and it works pretty well. [1]: https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html [2]: https://github.com/Khan/aphrodite/blob/master/src/generate.js#L139 https://github.com/Khan/aphrodite/blob/master/src/generate.j...
insin 10y ago
I'd prefer that approach too, as I can also document things at the same time as providing type annotations; flow-jsdoc looks interesting, but I don't know how easy it would be to plug into a Babel/Webpack+Babel workflow: https://github.com/Kegsay/flow-jsdoc https://github.com/Kegsay/flow-jsdoc
- damncabbage 10y ago
  There's also comments support in Flow directly, but it's sadly (but understandably) hideous: function somefunction(somestring/*: string*/)/*: boolean */ { var ret/*: boolean */; ... return ret; } (See https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html)
- Lio 10y ago
  Might be worth pointing out, the "documentation" package[1] can be used to generate jsdoc annotations suitable for Google Closure compiler from Flow type annotations. It can also build really nice HTML documentation to. [1] https://www.npmjs.com/package/documentation https://www.npmjs.com/package/documentation

mullsork 10y ago

My biggest gripe with Flow is how buggy it is. 1. it often fails to find the type for an imported piece of code 2. more often than not refers to the type definition being a problem rather than whoever's calling a function with an incorrect type 3. it seems to have an issue with cache busting(?) (I `killall flow` multiple times per day to make sure it's not complaining about old code) All in all I feel very sad for choosing Flow over TypeScript two weeks ago. We felt TS would be more invasive to our Webpack pipeline but I think I might just take a weekend to migrate over to TS... TS seems to have a lot more type definitions available as well, a more active community perhaps? Looking at the issue list of Flow I'm starting to suspect they're not very active in maintenance / issue handling. TS seems much more active.

nullxone 10y ago

Here's all the things. https://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/ https://djcordhose.github.io/flow-vs-typescript/flow-typescr...