- 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.
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.
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.
Picking and choosing language features via babel plugins (many of which will never become part of JavaScript) is an anti-feature. You essentially are creating your own language that only you understand.
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.
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.
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.
FYI we do have an issue open about TS 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.
treehau5|9 years ago
- 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|9 years ago
> - 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.
davesnothere|9 years ago
Touche|9 years ago
WorldMaker|9 years ago
MehdiHK|9 years ago
icholy|9 years ago
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?
dangoor|9 years ago
whatever_dude|9 years ago
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.
dsp1234|9 years ago
https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...
hzoo|9 years ago
treehau5|9 years ago