12 ms·

I'd love a pro con from someone who's really tried out both TypeScript and Flow. I tried to get either of them started last weekend and couldn't get to a good p

I'd love a pro con from someone who's really tried out both TypeScript and Flow. I tried to get either of them started last weekend and couldn't get to a good place. Flow was missing annotations for three.js and typescript didn't seem to support es6isms. I found a compiler for the typescript definitions file for threejs but also couldn't sort out how to actually import that into flow.

msoad 9y ago
We did a very deep dive in comparison between the two before going with TypeScript. The biggest differences are: 1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions 2. Tooling, TypeScript has a much better tooling support 3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular. Syntax and personal opinions was not part of our decision making process.
- nojvek 9y ago
  with the checkJs option, now you don't even need to rename your files to .ts, You can just use typescript as a nice typechecker and give you sane .js
freditup 9y ago
What es6 features were you looking for that TS didn't support? In general, it supports most stage 3 and higher ES proposals. (Note that TS doesn't polyfill methods; it only adds support for syntactic elements)
styfle 9y ago
I suspect you didn't set target to ES6 in the `tsconfig.json` file which would limit some of the features. If you don't specify, I think the default is ES5. See this example: https://github.com/styfle/react-server-example-tsx/blob/master/tsconfig.json#L5 https://github.com/styfle/react-server-example-tsx/blob/mast...
ng12 9y ago
Flow is basically a linter, which I really don't like. If you run flow on an existing JS project it will find a few hundred not-really-bugs. That and the incredibly poor tooling (Flow runs as a separate server process) were enough to make me ditch it. On the other hand, if you use Typescript with the allowJs setting it's exactly ES6 plus optional types.
nawgszy 9y ago
I'd love a pro con from someone who's really tried out both TypeScript and ES6 Javascript. What exactly is the use case that TypeScript allows one to write JS for that one can't just write JS for?
- frogstomp19 9y ago
  I've been using both for a few years (TS at my old job, es6 at my new job but we're moving to TS so now I'm using both depending on what I'm working on). The use case I like most about typescript is it makes refactoring and making changes really painless. For example, in an angular app, you may have a service that several components rely on. When changing a method signature in the service, you'll get compile-time info about any other usages of that service, and you feel a lot more confident about making changes without something dumb slipping through the cracks and causing bugs in production. This confidence generally lends itself to less fear of change and more willingness to refactor, which leads to a better/cleaner codebase. Aside from that, I love the JSDoc comments showing up as you type, especially if you're working on a team in which you may not know 100% what everyone has worked on. Other features I use every day and love: -automatic/generated import statements -type definitions for libraries (most have solid documentation) -control-flow logic checking (you'll find more bugs than you think with this and it encourages more defensive programming) -transpiling down to support older browsers (babel does this too but it's nice to have it built in) Edit: I forgot to go into the "cons" list here. -there's some finagling you'll have to do with some of the more poorly-written npm packages that strap themselves onto globals -there's a slight learning curve -you'll require a build step (with es6 if you're targeting es6-only browsers you can deploy just static files, but most people use webpack/babel anyway for older browser support and other things webpack gives you like bundling/minification/etc)
  - metamet 9y ago
    > you'll require a build step I'd like to note that this is done automatically in Visual Studio 2015 and on. You just save your .ts file and VS will create the .js file.
    - 9y ago
bcherny 9y ago
As far as type systems/language features: TypeScript: - Structurally typed - Enum types - Mapped types - Abstract classes - Scoped class members (public, private, protected) - Namespaces Flow: - Nominally typed - Covariance/contravariance annotations - Supertype annotations (via $Supertype type) - Subtype annotations (via $Subtype type) - Arity annotations (via $Pred type) - Subtraction types (via $Diff type) - Opt-in 2-way type resolver (via * type) - Refer to nested type (via $PropertyType type) Otherwise, the two are remarkably similar. I've been using TS for a few years, and Flow for a few months. Please correct me if any of the above are wrong.
- andreypopp 9y ago
  In Flow only classes are nominally typed. Objects and interfaces are typed structurally.
- pininja 9y ago
  Thank you for the comparison. This basically matches my experience as well. Hoping your post gets up to the top.
- deleted 9y ago
  [deleted]
andreypopp 9y ago
Ok, I've used TS while contributing to OSS written with TS and I've used Flow extensively in production settings. The main takeaway for me is that TS is much much less sound than Flow. That means it checks less invariants which in turn makes you less trust it... Consider the following code which is valid (!) in TS: let promisedString: Promise<string> = new Promise( resolve => { // Perfectly valid in TypeScript! resolve(42) } ) Another downside of TS is poor type inference. It requires to annotate each top level function while Flow only requires to annotate exported functions. Even the following simple piece of code will make TS ask you to annotate doAddition function: export function addition(a: number, b: number) { return doAddition(a, b) } function doAddition(a, b) { return a + b } I'm really glad Flow doesn't force me into it. Edit: spelling
- ng12 9y ago
  FWIW your Promise example has to do with whatever implementation of Promise you're using, not Typescript. Bluebird's typings would correctly complain with that example -- both because your second Promise is implicit-any, and the resolve is wrong.
  - andreypopp 9y ago
    EDIT 2: This still surprises me... let promisedString: Promise<string> = new Promise<string>( resolve => { // Perfectly valid in TypeScript! resolve(undefined) } ) EDIT: no, I was wrong — Bluebird typings won't allow this behaviour but they force me to annotate both the binding and the Promise constructor call: let promisedString: Promise<string> = new Promise<string>( resolve => { resolve(42) // type error here, ok } ) That's surprising TS ships with such unsafe typings for ES2015 Promise API... Hm... no. First, note that this is with noImplicitAny activated. You can check this in TS playground. Then if we inspect what typings TS have for ES2015 Promises[1] and for Bluebird[2], you can clearly see that those are identical in this case.. [1]: https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es2015.promise.d.ts#L33 https://github.com/Microsoft/TypeScript/blob/master/lib/lib.... [2]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/bluebird/v2/index.d.ts#L34 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
cletusw 9y ago
I haven't used Flow much, but having used TypeScript at work for only a few weeks we've already found several instances where the type system isn't flexible/complete enough to describe several perfectly valid JavaScript idioms. Workarounds often mean lots of `any` types or tons of boilerplate/repeated code. Not fun. On the whole, though, compared to un-typed JavaScript, still totally worth it. I'd just be interested to see how Flow handles some of these situations.
- icholy 9y ago
  Do you have an example of one of these idioms that typescript can't handle?
- deleted 9y ago
  [deleted]
- ArlenBales 9y ago
  Could you please post those situations? Someone familiar with Flow might be able to answer you.
netheril96 9y ago
I have only superficial experience, but the biggest benefit of typescript over flow is the tooling. It is easy to setup, with transpiling, JSX, linting, webpack loader all bundled together, while with flow you have setup a lot of different components yourself, which may not interact well with each other.
gempir 9y ago
Heard a talk about that a while ago. Here are the slides maybe you can get something from them. https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html#/ https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.ht...

msoad 9y ago

We did a very deep dive in comparison between the two before going with TypeScript. The biggest differences are: 1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions 2. Tooling, TypeScript has a much better tooling support 3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular. Syntax and personal opinions was not part of our decision making process.

nojvek 9y ago
with the checkJs option, now you don't even need to rename your files to .ts, You can just use typescript as a nice typechecker and give you sane .js

freditup 9y ago

What es6 features were you looking for that TS didn't support? In general, it supports most stage 3 and higher ES proposals. (Note that TS doesn't polyfill methods; it only adds support for syntactic elements)

styfle 9y ago

I suspect you didn't set target to ES6 in the `tsconfig.json` file which would limit some of the features. If you don't specify, I think the default is ES5. See this example: https://github.com/styfle/react-server-example-tsx/blob/master/tsconfig.json#L5 https://github.com/styfle/react-server-example-tsx/blob/mast...

ng12 9y ago

Flow is basically a linter, which I really don't like. If you run flow on an existing JS project it will find a few hundred not-really-bugs. That and the incredibly poor tooling (Flow runs as a separate server process) were enough to make me ditch it. On the other hand, if you use Typescript with the allowJs setting it's exactly ES6 plus optional types.

nawgszy 9y ago

I'd love a pro con from someone who's really tried out both TypeScript and ES6 Javascript. What exactly is the use case that TypeScript allows one to write JS for that one can't just write JS for?

frogstomp19 9y ago
I've been using both for a few years (TS at my old job, es6 at my new job but we're moving to TS so now I'm using both depending on what I'm working on). The use case I like most about typescript is it makes refactoring and making changes really painless. For example, in an angular app, you may have a service that several components rely on. When changing a method signature in the service, you'll get compile-time info about any other usages of that service, and you feel a lot more confident about making changes without something dumb slipping through the cracks and causing bugs in production. This confidence generally lends itself to less fear of change and more willingness to refactor, which leads to a better/cleaner codebase. Aside from that, I love the JSDoc comments showing up as you type, especially if you're working on a team in which you may not know 100% what everyone has worked on. Other features I use every day and love: -automatic/generated import statements -type definitions for libraries (most have solid documentation) -control-flow logic checking (you'll find more bugs than you think with this and it encourages more defensive programming) -transpiling down to support older browsers (babel does this too but it's nice to have it built in) Edit: I forgot to go into the "cons" list here. -there's some finagling you'll have to do with some of the more poorly-written npm packages that strap themselves onto globals -there's a slight learning curve -you'll require a build step (with es6 if you're targeting es6-only browsers you can deploy just static files, but most people use webpack/babel anyway for older browser support and other things webpack gives you like bundling/minification/etc)
- metamet 9y ago
  > you'll require a build step I'd like to note that this is done automatically in Visual Studio 2015 and on. You just save your .ts file and VS will create the .js file.
  - 9y ago

bcherny 9y ago

As far as type systems/language features: TypeScript: - Structurally typed - Enum types - Mapped types - Abstract classes - Scoped class members (public, private, protected) - Namespaces Flow: - Nominally typed - Covariance/contravariance annotations - Supertype annotations (via $Supertype type) - Subtype annotations (via $Subtype type) - Arity annotations (via $Pred type) - Subtraction types (via $Diff type) - Opt-in 2-way type resolver (via * type) - Refer to nested type (via $PropertyType type) Otherwise, the two are remarkably similar. I've been using TS for a few years, and Flow for a few months. Please correct me if any of the above are wrong.

andreypopp 9y ago
In Flow only classes are nominally typed. Objects and interfaces are typed structurally.
pininja 9y ago
Thank you for the comparison. This basically matches my experience as well. Hoping your post gets up to the top.
deleted 9y ago
[deleted]

andreypopp 9y ago

Ok, I've used TS while contributing to OSS written with TS and I've used Flow extensively in production settings. The main takeaway for me is that TS is much much less sound than Flow. That means it checks less invariants which in turn makes you less trust it... Consider the following code which is valid (!) in TS: let promisedString: Promise<string> = new Promise( resolve => { // Perfectly valid in TypeScript! resolve(42) } ) Another downside of TS is poor type inference. It requires to annotate each top level function while Flow only requires to annotate exported functions. Even the following simple piece of code will make TS ask you to annotate doAddition function: export function addition(a: number, b: number) { return doAddition(a, b) } function doAddition(a, b) { return a + b } I'm really glad Flow doesn't force me into it. Edit: spelling

ng12 9y ago
FWIW your Promise example has to do with whatever implementation of Promise you're using, not Typescript. Bluebird's typings would correctly complain with that example -- both because your second Promise is implicit-any, and the resolve is wrong.
- andreypopp 9y ago
  EDIT 2: This still surprises me... let promisedString: Promise<string> = new Promise<string>( resolve => { // Perfectly valid in TypeScript! resolve(undefined) } ) EDIT: no, I was wrong — Bluebird typings won't allow this behaviour but they force me to annotate both the binding and the Promise constructor call: let promisedString: Promise<string> = new Promise<string>( resolve => { resolve(42) // type error here, ok } ) That's surprising TS ships with such unsafe typings for ES2015 Promise API... Hm... no. First, note that this is with noImplicitAny activated. You can check this in TS playground. Then if we inspect what typings TS have for ES2015 Promises[1] and for Bluebird[2], you can clearly see that those are identical in this case.. [1]: https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es2015.promise.d.ts#L33 https://github.com/Microsoft/TypeScript/blob/master/lib/lib.... [2]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/bluebird/v2/index.d.ts#L34 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

cletusw 9y ago

I haven't used Flow much, but having used TypeScript at work for only a few weeks we've already found several instances where the type system isn't flexible/complete enough to describe several perfectly valid JavaScript idioms. Workarounds often mean lots of `any` types or tons of boilerplate/repeated code. Not fun. On the whole, though, compared to un-typed JavaScript, still totally worth it. I'd just be interested to see how Flow handles some of these situations.

icholy 9y ago
Do you have an example of one of these idioms that typescript can't handle?
deleted 9y ago
[deleted]
ArlenBales 9y ago
Could you please post those situations? Someone familiar with Flow might be able to answer you.

netheril96 9y ago

I have only superficial experience, but the biggest benefit of typescript over flow is the tooling. It is easy to setup, with transpiling, JSX, linting, webpack loader all bundled together, while with flow you have setup a lot of different components yourself, which may not interact well with each other.

gempir 9y ago

Heard a talk about that a while ago. Here are the slides maybe you can get something from them. https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html#/ https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.ht...