5 ms·

The two are converging in a lot of ways. Flow maintains it's impressive ability to determine types based on individual usages of functions. Basically checking t

by slackingoff2017 9y ago

The two are converging in a lot of ways. Flow maintains it's impressive ability to determine types based on individual usages of functions. Basically checking type safety based on what you passed in rather than what the function says it's supposed to take. Typescript is more of a traditional typing system and discourages you from using variable types in the first place. The important distinction is that if you tell typescript a function can take in any value it makes no attempt to type check. Flow will look at each usage of the function and try to determine if the value being run through is valid. My personal preference is to typescript so I'm probably biased. Typescript community, tooling, and general ease of use is better. MS has long been known for good dev tools and it shines here. If you end goal is to statically type your whole application then flow has little or no advantages. In this case it's better to go with Typescript for ease of use, community support, friendlier error warnings, and better tooling. If your goal is to keep using JavaScript and use type checking as a fancy linter then flow is clearly superior. Something else I noticed that may be very important down the road: typescript is easier to get rid of. The JavaScript it outputs is very readable and mostly looks hand-written. IMO the best tools are the ones easy to get rid of, especially since JS is such a moving target. If Typescript dies one day you can compile down to JS one more time and throw the TS code away and still have a decent codebase. Flow and Babel produce some really crazy stuff, and codegen of clean and readable JavaScript seems like more of an afterthought.

davnicwil 9y ago
> If Typescript dies one day you can compile down to JS... flow and babel produce some really crazy stuff I'm not sure if I'm misinterpreting what you're saying here, but on the face of it, this is not correct. Flow is just annotations over JS, it is not a compile to JS language like TS. Flow doesn't produce anything. It's absolutely trivial to remove by just stripping the annotations. There is a babel plugin for doing that, but that's all it does. If there's any output after that that doesn't seem to map well to the original JS code, that's all babel on the remaining JS, nothing to do with Flow. It would be the same with or without Flow. Or did you mean something else?
- slackingoff2017 9y ago
  Typically you use flow with Babel so you can use newer JavaScript features. Babel creates messy JavaScript in the process of transpilation. Typescript combines typing and transpilation together, essentially doing what flow+Babel does. Typescript allows you use newer JS features like Babel but produces much cleaner JavaScript. If the choice is Typescript or flow without Babel Typescript is the winner by a mile. Without Babel hooked up to flow you can't use any new JS features.
  - davnicwil 9y ago
    Ah, sure, that makes sense. A couple of things which mitigate that downside with babel though, at least for my setup & way of working: (1) Sourcemaps. For me, the only practical purpose of touching the transpiled code is debugging. For this purpose I find the sourcemaps output by babel gives me 1-1 mapping to my source anyway, pretty flawlessly with chrome dev tools. So, I have no issues with the messiness or non-messiness of the transpiled code. (2) With babel, your source is just JS. Eventually, at some glorious point in the future, we will have enough of those great features available natively in enough browsers that it's possible to turn babel transpilation off. At that point, Flow has a massive ace up its sleeve in terms of being just an additional layer on top of JS - the build step will be incredibly fast and tiny. Typescript on the other hand will never be just JS. There will never be a total 1-1 mapping (TS is, by design philosophy, a superset of JS), and even if it gets really fast there will always be more of a transpilation step, always source mapping, etc. It will never go away. So, TS feels like a nice packaged solution now, but will it look so attractive in 5 years? Or maybe a touch over engineered for a problem that doesn't really exist any more? In this sense, to me, Flow feels a bit more future-proof.
  - Arnavion 9y ago
    >Typescript combines typing and transpilation together, essentially doing what flow+Babel does. Typescript allows you use newer JS features like Babel but produces much cleaner JavaScript. It's important to keep in mind that the simplicity of TS's ES5 codegen comes with the tradeoff that it isn't spec-compliant. For example, given a program `for (const el of arr) { }`, TS's codegen is a loop like `for(var i = 0; i < arr.length; i++) { var el = arr[i]; }` whereas Babel's codegen uses `Symbol.iterator`. The former is technically wrong in an environment where `arr` happens to have a custom `[Symbol.iterator]`. Another example is ES2015 classes, for which Babel's codegen asserts the constructor is being called with `new` whereas TS's doesn't.
lewisl9029 9y ago
Thanks for the response. I have no interest in statically typing my entire application, so being able to preserve JavaScript's dynamic nature to maximize iterate speed while still deriving some value from static type analysis (and having the option to specify manual types to improve the analysis) is an extremely attractive prospect for me. I was under the impression that both TypeScript and Flow would support this, but your account definitely pushes me a bit further in favor of Flow.
- tuxracer 9y ago
  "If you end goal is to statically type your whole application then flow has little or no advantages" does not somehow translate to: If your end goal is to /not/ statically type your whole application then typescript has a disadvantage. Both TypeScript and Flow are gradually typed and annotations are completely optional at every step of the way. Neither TypeScript nor Flow differ whatsoever in this regard.
  - lewisl9029 9y ago
    Hmm... did I somehow misinterpret this statement from the GP? > The important distinction is that if you tell typescript a function can take in any value it makes no attempt to type check. Flow will look at each usage of the function and try to determine if the value being run through is valid. This reads to me to mean that while annotations are optional in both systems, if you don't provide them for a particular subsystem in TypeScript, the static analysis will simply perform no checks for usages of that particular subsystem, while in Flow it will still attempt to validate your subsystem with properties it can infer on a best-effort basis from things like the way its functions are called.
    - Joeri 9y ago
      Typescript also tries to infer types, and falls back to an implicit "any" type when it can't. Flow was better at type inference, but I don't know if it still is.

davnicwil 9y ago

> If Typescript dies one day you can compile down to JS... flow and babel produce some really crazy stuff I'm not sure if I'm misinterpreting what you're saying here, but on the face of it, this is not correct. Flow is just annotations over JS, it is not a compile to JS language like TS. Flow doesn't produce anything. It's absolutely trivial to remove by just stripping the annotations. There is a babel plugin for doing that, but that's all it does. If there's any output after that that doesn't seem to map well to the original JS code, that's all babel on the remaining JS, nothing to do with Flow. It would be the same with or without Flow. Or did you mean something else?

slackingoff2017 9y ago
Typically you use flow with Babel so you can use newer JavaScript features. Babel creates messy JavaScript in the process of transpilation. Typescript combines typing and transpilation together, essentially doing what flow+Babel does. Typescript allows you use newer JS features like Babel but produces much cleaner JavaScript. If the choice is Typescript or flow without Babel Typescript is the winner by a mile. Without Babel hooked up to flow you can't use any new JS features.
- davnicwil 9y ago
  Ah, sure, that makes sense. A couple of things which mitigate that downside with babel though, at least for my setup & way of working: (1) Sourcemaps. For me, the only practical purpose of touching the transpiled code is debugging. For this purpose I find the sourcemaps output by babel gives me 1-1 mapping to my source anyway, pretty flawlessly with chrome dev tools. So, I have no issues with the messiness or non-messiness of the transpiled code. (2) With babel, your source is just JS. Eventually, at some glorious point in the future, we will have enough of those great features available natively in enough browsers that it's possible to turn babel transpilation off. At that point, Flow has a massive ace up its sleeve in terms of being just an additional layer on top of JS - the build step will be incredibly fast and tiny. Typescript on the other hand will never be just JS. There will never be a total 1-1 mapping (TS is, by design philosophy, a superset of JS), and even if it gets really fast there will always be more of a transpilation step, always source mapping, etc. It will never go away. So, TS feels like a nice packaged solution now, but will it look so attractive in 5 years? Or maybe a touch over engineered for a problem that doesn't really exist any more? In this sense, to me, Flow feels a bit more future-proof.
- Arnavion 9y ago
  >Typescript combines typing and transpilation together, essentially doing what flow+Babel does. Typescript allows you use newer JS features like Babel but produces much cleaner JavaScript. It's important to keep in mind that the simplicity of TS's ES5 codegen comes with the tradeoff that it isn't spec-compliant. For example, given a program `for (const el of arr) { }`, TS's codegen is a loop like `for(var i = 0; i < arr.length; i++) { var el = arr[i]; }` whereas Babel's codegen uses `Symbol.iterator`. The former is technically wrong in an environment where `arr` happens to have a custom `[Symbol.iterator]`. Another example is ES2015 classes, for which Babel's codegen asserts the constructor is being called with `new` whereas TS's doesn't.

lewisl9029 9y ago

Thanks for the response. I have no interest in statically typing my entire application, so being able to preserve JavaScript's dynamic nature to maximize iterate speed while still deriving some value from static type analysis (and having the option to specify manual types to improve the analysis) is an extremely attractive prospect for me. I was under the impression that both TypeScript and Flow would support this, but your account definitely pushes me a bit further in favor of Flow.

tuxracer 9y ago
"If you end goal is to statically type your whole application then flow has little or no advantages" does not somehow translate to: If your end goal is to /not/ statically type your whole application then typescript has a disadvantage. Both TypeScript and Flow are gradually typed and annotations are completely optional at every step of the way. Neither TypeScript nor Flow differ whatsoever in this regard.
- lewisl9029 9y ago
  Hmm... did I somehow misinterpret this statement from the GP? > The important distinction is that if you tell typescript a function can take in any value it makes no attempt to type check. Flow will look at each usage of the function and try to determine if the value being run through is valid. This reads to me to mean that while annotations are optional in both systems, if you don't provide them for a particular subsystem in TypeScript, the static analysis will simply perform no checks for usages of that particular subsystem, while in Flow it will still attempt to validate your subsystem with properties it can infer on a best-effort basis from things like the way its functions are called.
  - Joeri 9y ago
    Typescript also tries to infer types, and falls back to an implicit "any" type when it can't. Flow was better at type inference, but I don't know if it still is.