6 ms·

I wish Facebook would drop FlowTypw at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going

I wish Facebook would drop FlowTypw at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond TS. One immediate benefit would be better support for react. Yes it works but not always as seamlessly as Angular/TypeScript.

smdz 10y ago
I wish the same. Unfortunately not many devs are trying out TypeScript. I've used React+TS for a year now. It works perfectly. The decorators in TS are great to use with the react-redux implementations - makes the code look less verbose The only problems I have faced is when type definitions are not available for certain libs. The workaround is simple - using "require(...)" instead of "import .. from ..." statements With type definitions available from npm and @types, its pretty easy compared to the TSD and Typings I had to use earlier.
- danappelxx 10y ago
  > Unfortunately not many devs are trying out TypeScript. Really? I've seen so much hype for typescript (though not as much recently). How much is enough?
- johnfn 10y ago
  TypeScript is the 9th most used language on the StackOverflow survey - ahead of languages like Ruby, Swift, and Objective-C - so I wouldn't say that "not many devs" are trying it out. :)
- Ciantic 10y ago
  You should try the "allowJs" tsconfig option, it should allow to use the JS libraries without types with normal syntax (if you do that already with require trick, you are basically doing that anyhow).
seattle_spring 10y ago
Couldn't the same be said about TypeScript? "I wish Microsoft would drop TypeScript at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond Flow."
- jiaweihli 10y ago
  This is a bit meta, but both of you stated a position without providing a concrete rationale. Something to consider is that people can gloss over an explanation for convenience. For example: in the previous sentence, I didn't provide any proof that it's accurate. You could make the argument that nobody glosses over explanations for convenience. I don't think it's necessarily worth proving every statement, because that'd be extremely time-consuming. But if you provide an opposing viewpoint, back it up with clear reasons (this helps filter out positions that are undefendable), and I'm interested in defending my position or continuing the discussion, then we can have a meaningful discussion from that.
  - seattle_spring 10y ago
    > This is a bit meta, but both of you stated a position without providing a concrete rationale. The primary difference being that "my position" was not actually my position, it was just an attempt to point out exactly what you're trying to say. I guess I failed ;)
    - WhitneyLand 10y ago
      So you disagree or just were wanting to understand the backstory? I would try to help you but the sarcasm makes it unclear the best way to do that.
      - seattle_spring 10y ago
        Neither. I think Flow and TypeScript are both great solutions, and neither is clearly better at this point.
z3t4 10y ago
Flow is JavaScript (with type annotations) while Typescript is an entirely different language that needs to compile to JavaScript. You do not need any source maps for Flow as it just replace the type annotations with spaces. So you get to eat the cookie and keep it, while with Typescript you eat the cookie and lock yourself in.
- jstarks 10y ago
  What's an example of a TypeScript program where erasing the type information won't produce valid ES6? I had thought Flow and TypeScript were the same in this regard, but I am not an expert.
  - evmar 10y ago
    TypeScript supports ES7 features, for example. It also has a few language-local quirks (like parameter properties, described https://www.typescriptlang.org/docs/handbook/classes.html https://www.typescriptlang.org/docs/handbook/classes.html ). I find the grandparent argument pretty unconvincing though. People writing Flow are generally using JSX or ES modules (the Flow docs recommend the latter, for example), both of which require a transpiler like Babel to be used in a browser anyway.
- WhitneyLand 10y ago
  No, this is hyperbole and misleading. Follow their roadmap and stated direction. They have always been committed to aligning with standards and whenever ES adopts new functionality they gravitate to it's lead. They will never drift off to some mutation that isolates you from the JS ecosystem or its benefits.
  - wiredearp 10y ago
    If you look up "embrace, extend and extinguish" in the textbook, you will see Microsoft mentioned in the first sentence [1]. If you are old enough to remember Internet Explorer, you've already seen how this works. Consider then that static types do in fact extend JS and perhaps you'll see why this is not so reassuring after all. [1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
spion 10y ago
I believe that one area where TS could stand some improvement are multi-package projects. https://github.com/Microsoft/TypeScript/issues/3469 https://github.com/Microsoft/TypeScript/issues/3469
bastawhiz 10y ago
Yeah, using Flow with React is painful. Which is weird, considering they're both from Facebook. Want to add a propType for 'children'? Sorry, nope. Want to use the equivalent of PropTypes.node? Good luck with that. The biggest thing that I see as a barrier to entry for TS (and someone please correct me if this is no longer a problem) is integration with build tools from the rest of the ecosystem. Webpack with fancy loaders, third party language tools (linters, etc.), top-tier non-VS Code editor support, and so on.
- Ciantic 10y ago
  TypeScript's strong part is the IDE support. It worked great with Eclipse years ago (using the same language server), it worked with Atom years ago. It has Sublime plugin that also uses the language server (not tried this myself). This is because the whole language is build with IDE tooling in mind. It's also approachable, as more language servers are being built the same way, like the PHP language server that is now gathering steam and will be used in several IDE's also besides VS Code. Webpack and fancy loaders could be issue if you want type checking on really fancy syntax plugins. (Not sure what they are, since JSX is part of TS) These days you need one Webpack loader anyway for new ES features. It's really great that you can just remove Babel and use ts-loader in place as many of the ES features are already in TS.
  - bastawhiz 10y ago
    The IDE support I yearn for is the really nice autocomplete support you see in tools designed specifically for TS. Last I used it, it was very flimsy in Sublime and Atom--very little in the way of helpful suggestions. Perhaps that's been improved, which I would welcome. The loaders I use in webpack are mostly around asset loading. Style loaders, integration with other languages (coffeescript...ugh) for some weird legacy code, etc.
- deleted 10y ago
  [deleted]

smdz 10y ago

I wish the same. Unfortunately not many devs are trying out TypeScript. I've used React+TS for a year now. It works perfectly. The decorators in TS are great to use with the react-redux implementations - makes the code look less verbose The only problems I have faced is when type definitions are not available for certain libs. The workaround is simple - using "require(...)" instead of "import .. from ..." statements With type definitions available from npm and @types, its pretty easy compared to the TSD and Typings I had to use earlier.

danappelxx 10y ago
> Unfortunately not many devs are trying out TypeScript. Really? I've seen so much hype for typescript (though not as much recently). How much is enough?
johnfn 10y ago
TypeScript is the 9th most used language on the StackOverflow survey - ahead of languages like Ruby, Swift, and Objective-C - so I wouldn't say that "not many devs" are trying it out. :)
Ciantic 10y ago
You should try the "allowJs" tsconfig option, it should allow to use the JS libraries without types with normal syntax (if you do that already with require trick, you are basically doing that anyhow).

seattle_spring 10y ago

Couldn't the same be said about TypeScript? "I wish Microsoft would drop TypeScript at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond Flow."

jiaweihli 10y ago
This is a bit meta, but both of you stated a position without providing a concrete rationale. Something to consider is that people can gloss over an explanation for convenience. For example: in the previous sentence, I didn't provide any proof that it's accurate. You could make the argument that nobody glosses over explanations for convenience. I don't think it's necessarily worth proving every statement, because that'd be extremely time-consuming. But if you provide an opposing viewpoint, back it up with clear reasons (this helps filter out positions that are undefendable), and I'm interested in defending my position or continuing the discussion, then we can have a meaningful discussion from that.
- seattle_spring 10y ago
  > This is a bit meta, but both of you stated a position without providing a concrete rationale. The primary difference being that "my position" was not actually my position, it was just an attempt to point out exactly what you're trying to say. I guess I failed ;)
  - WhitneyLand 10y ago
    So you disagree or just were wanting to understand the backstory? I would try to help you but the sarcasm makes it unclear the best way to do that.
    - seattle_spring 10y ago
      Neither. I think Flow and TypeScript are both great solutions, and neither is clearly better at this point.

z3t4 10y ago

Flow is JavaScript (with type annotations) while Typescript is an entirely different language that needs to compile to JavaScript. You do not need any source maps for Flow as it just replace the type annotations with spaces. So you get to eat the cookie and keep it, while with Typescript you eat the cookie and lock yourself in.

jstarks 10y ago
What's an example of a TypeScript program where erasing the type information won't produce valid ES6? I had thought Flow and TypeScript were the same in this regard, but I am not an expert.
- evmar 10y ago
  TypeScript supports ES7 features, for example. It also has a few language-local quirks (like parameter properties, described https://www.typescriptlang.org/docs/handbook/classes.html https://www.typescriptlang.org/docs/handbook/classes.html ). I find the grandparent argument pretty unconvincing though. People writing Flow are generally using JSX or ES modules (the Flow docs recommend the latter, for example), both of which require a transpiler like Babel to be used in a browser anyway.
WhitneyLand 10y ago
No, this is hyperbole and misleading. Follow their roadmap and stated direction. They have always been committed to aligning with standards and whenever ES adopts new functionality they gravitate to it's lead. They will never drift off to some mutation that isolates you from the JS ecosystem or its benefits.
- wiredearp 10y ago
  If you look up "embrace, extend and extinguish" in the textbook, you will see Microsoft mentioned in the first sentence [1]. If you are old enough to remember Internet Explorer, you've already seen how this works. Consider then that static types do in fact extend JS and perhaps you'll see why this is not so reassuring after all. [1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

spion 10y ago

I believe that one area where TS could stand some improvement are multi-package projects. https://github.com/Microsoft/TypeScript/issues/3469 https://github.com/Microsoft/TypeScript/issues/3469

bastawhiz 10y ago

Yeah, using Flow with React is painful. Which is weird, considering they're both from Facebook. Want to add a propType for 'children'? Sorry, nope. Want to use the equivalent of PropTypes.node? Good luck with that. The biggest thing that I see as a barrier to entry for TS (and someone please correct me if this is no longer a problem) is integration with build tools from the rest of the ecosystem. Webpack with fancy loaders, third party language tools (linters, etc.), top-tier non-VS Code editor support, and so on.

Ciantic 10y ago
TypeScript's strong part is the IDE support. It worked great with Eclipse years ago (using the same language server), it worked with Atom years ago. It has Sublime plugin that also uses the language server (not tried this myself). This is because the whole language is build with IDE tooling in mind. It's also approachable, as more language servers are being built the same way, like the PHP language server that is now gathering steam and will be used in several IDE's also besides VS Code. Webpack and fancy loaders could be issue if you want type checking on really fancy syntax plugins. (Not sure what they are, since JSX is part of TS) These days you need one Webpack loader anyway for new ES features. It's really great that you can just remove Babel and use ts-loader in place as many of the ES features are already in TS.
- bastawhiz 10y ago
  The IDE support I yearn for is the really nice autocomplete support you see in tools designed specifically for TS. Last I used it, it was very flimsy in Sublime and Atom--very little in the way of helpful suggestions. Perhaps that's been improved, which I would welcome. The loaders I use in webpack are mostly around asset loading. Style loaders, integration with other languages (coffeescript...ugh) for some weird legacy code, etc.
deleted 10y ago
[deleted]