5 ms·

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

Vinnl 8y ago
Well, TypeScript at least is growing enormously. Whether Flow dies or not is up to its authors, but I think TypeScript is pretty much unstoppable today.
russley 8y ago
There have been several projects that were flow based that have moved to TS. I think the real litmus test will be if React eventually either includes TS types or is rewritten in TS. Disclaimer: I work with TypeScript professionally.
- acemarke 8y ago
  I'm pretty in tune with what's going on around React, and I don't see that one ever happening. The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another. I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).
  - 52-6F-62 8y ago
    One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten. A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files. (This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped) Ex: JavaScript: app.js function app(arg1, arg2, arg3) { // does something return { key1: someStringValue, key2: someNumberValue, }; } TypeScript: app.d.ts declare type AppReturnValue = { key1: string, key2: number }; declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;
    - acemarke 8y ago
      Given that React is already heavily invested in Flow types, there would be _some_ form of rewrite. And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.
      - 52-6F-62 8y ago
        Oh— can you point me at a file in particular? I had a look around the codebase and didn't see anything but plain JS. Might have been looking in the wrong places. And I certainly get your point. However I wonder if they'd consider community-contributed TypeScript declaration files to the official repo as they wouldn't cause conflicts with the Flow system—
        acemarke 8y ago
        Flow types are _everywhere_ in the codebase. To pick a specific example, here's the file that implements the core logic for the new Hooks feature: https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e4601bcee979a004fe91/packages/react-reconciler/src/ReactFiberHooks.js https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e... As for the TS typings, there's been lots of agitation from people asking them to be officially included and shipped with React. But, again, the React devs themselves aren't TS users (that I know of), and so they don't have the expertise to write and maintain those typings. Better that they be left over in DefinitelyTyped for the community to maintain. (I'm a Redux maintainer, and I feel exactly the same way about the typings for React-Redux. I don't have any actual TS experience myself yet, and I couldn't do anything useful in regards to the React-Redux typings. Plus, I've got far too much else on my plate to worry about those.)
LaGrange 8y ago
Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-454956694 https://github.com/facebook/flow/issues/7365#issuecomment-45.... Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets sued out of business :-P
- kimsk112 8y ago
  I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.
  - LaGrange 8y ago
    I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug) change significantly.
    - int_19h 8y ago
      Even with wasm, much as I'm looking forward to the Great JS Purge personally, it's not going to happen anytime soon - too much existing code and devices. JS will remain necessary on the front-end for at least another decade, and probably beyond that. So TS will still be necessary to make the pill less bitter.
sephoric 8y ago
I tried Flow and TypeScript out about half a year ago in a client project and Flow was kind of painful and difficult to use, the updates, bug fixes and new features weren't coming as often as TypeScript's were, and maybe 70% of people I talked to were using TypeScript instead of Flow. Since then it's more like 90% now, and the TS team seems to be adding and announcing features faster than before, whereas I haven't heard about any new features in Flow. Maybe they're there, I'm just saying I haven't heard about them. This is all anecdotal but from what I've heard, it's very common. This is a big reason I chose TypeScript in Autumn. Also, VS Code has become the de facto free editor of JavaScript projects with a full set of professional-grade IDE features across the board, and VS Code has first-class support for TypeScript but only plugin-level support for Flow. Since Monaco is simply extracted from VS Code, that means I got all VS Code's IDE features for free when I embedded Monaco into Autumn, all I had to do was set the language to "typescript" and it just works. All these free and serious benefits of TypeScript's ecosystem kind of point to this conclusion that I've seen on HN and elsewhere over and over, that TypeScript has already won and Flow is on its way out.
mrspeaker 8y ago
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon? [Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]
- _hardwaregeek 8y ago
  TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
  - sephoric 8y ago
    Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
  - deleted 8y ago
    [deleted]
- Vinnl 8y ago
  Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
- lmm 8y ago
  If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.
jinder 8y ago
Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction. I'd consider flow dead.
- bouncing 8y ago
  > A corporate like Facebook would never allow that unless there was an internal shift in direction. Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is. Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist. But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.
  - venturin 8y ago
    Engineering VPs very much know about it.
ng12 8y ago
Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.
- noir_lord 8y ago
  For people now thinking well we have a large untyped codebase..damn. You can turn typescripts type inference on on a regular js file. https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
agentultra 8y ago
I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it. Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard? Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much. The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet? Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.
- nicoburns 8y ago
  > Has TypeScript caught up with flow in this regard I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference. The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly. You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap
whatever_dude 8y ago
The writing has been on the wall for a very [1] very [2] long [3] time. Facebook and some consumers of their ecosystem have been holding the fort, but it was inevitable something like this would happen. 1: https://npm-stat.com/charts.html?package=babel-core&package=typescript&package=flow-bin&from=2015-01-01 https://npm-stat.com/charts.html?package=babel-core&package=... 2: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0n50hxv,facebook%20flow%20%2B%20flow%20language%20%2B%20flowtype,%2Fm%2F0hjc5m0,%2Fm%2F03yb8hb,%2Fm%2F0h52xr1 https://trends.google.com/trends/explore?date=today%205-y&q=... 3: https://developers.slashdot.org/story/18/11/25/017227/microsofts-typescript-dominates-in-state-of-javascript-2018-report https://developers.slashdot.org/story/18/11/25/017227/micros...
bluepnume 8y ago
I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now. [0]: https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d https://medium.com/@bluepnume/introducing-paypals-open-sourc... [1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-even-with-react-out-of-the-picture-c597187134b7 https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...

Well, TypeScript at least is growing enormously. Whether Flow dies or not is up to its authors, but I think TypeScript is pretty much unstoppable today.

russley 8y ago

There have been several projects that were flow based that have moved to TS. I think the real litmus test will be if React eventually either includes TS types or is rewritten in TS. Disclaimer: I work with TypeScript professionally.

acemarke 8y ago
I'm pretty in tune with what's going on around React, and I don't see that one ever happening. The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another. I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).
- 52-6F-62 8y ago
  One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten. A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files. (This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped) Ex: JavaScript: app.js function app(arg1, arg2, arg3) { // does something return { key1: someStringValue, key2: someNumberValue, }; } TypeScript: app.d.ts declare type AppReturnValue = { key1: string, key2: number }; declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;
  - acemarke 8y ago
    Given that React is already heavily invested in Flow types, there would be _some_ form of rewrite. And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.
    - 52-6F-62 8y ago
      Oh— can you point me at a file in particular? I had a look around the codebase and didn't see anything but plain JS. Might have been looking in the wrong places. And I certainly get your point. However I wonder if they'd consider community-contributed TypeScript declaration files to the official repo as they wouldn't cause conflicts with the Flow system—
      - acemarke 8y ago
        Flow types are _everywhere_ in the codebase. To pick a specific example, here's the file that implements the core logic for the new Hooks feature: https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e4601bcee979a004fe91/packages/react-reconciler/src/ReactFiberHooks.js https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e... As for the TS typings, there's been lots of agitation from people asking them to be officially included and shipped with React. But, again, the React devs themselves aren't TS users (that I know of), and so they don't have the expertise to write and maintain those typings. Better that they be left over in DefinitelyTyped for the community to maintain. (I'm a Redux maintainer, and I feel exactly the same way about the typings for React-Redux. I don't have any actual TS experience myself yet, and I couldn't do anything useful in regards to the React-Redux typings. Plus, I've got far too much else on my plate to worry about those.)

LaGrange 8y ago

Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-454956694 https://github.com/facebook/flow/issues/7365#issuecomment-45.... Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets sued out of business :-P

kimsk112 8y ago
I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.
- LaGrange 8y ago
  I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug) change significantly.
  - int_19h 8y ago
    Even with wasm, much as I'm looking forward to the Great JS Purge personally, it's not going to happen anytime soon - too much existing code and devices. JS will remain necessary on the front-end for at least another decade, and probably beyond that. So TS will still be necessary to make the pill less bitter.

sephoric 8y ago

I tried Flow and TypeScript out about half a year ago in a client project and Flow was kind of painful and difficult to use, the updates, bug fixes and new features weren't coming as often as TypeScript's were, and maybe 70% of people I talked to were using TypeScript instead of Flow. Since then it's more like 90% now, and the TS team seems to be adding and announcing features faster than before, whereas I haven't heard about any new features in Flow. Maybe they're there, I'm just saying I haven't heard about them. This is all anecdotal but from what I've heard, it's very common. This is a big reason I chose TypeScript in Autumn. Also, VS Code has become the de facto free editor of JavaScript projects with a full set of professional-grade IDE features across the board, and VS Code has first-class support for TypeScript but only plugin-level support for Flow. Since Monaco is simply extracted from VS Code, that means I got all VS Code's IDE features for free when I embedded Monaco into Autumn, all I had to do was set the language to "typescript" and it just works. All these free and serious benefits of TypeScript's ecosystem kind of point to this conclusion that I've seen on HN and elsewhere over and over, that TypeScript has already won and Flow is on its way out.

mrspeaker 8y ago

Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon? [Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]

_hardwaregeek 8y ago
TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
- sephoric 8y ago
  Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
- deleted 8y ago
  [deleted]
Vinnl 8y ago
Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
lmm 8y ago
If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.

jinder 8y ago

Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction. I'd consider flow dead.

bouncing 8y ago
> A corporate like Facebook would never allow that unless there was an internal shift in direction. Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is. Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist. But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.
- venturin 8y ago
  Engineering VPs very much know about it.

ng12 8y ago

Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.

noir_lord 8y ago
For people now thinking well we have a large untyped codebase..damn. You can turn typescripts type inference on on a regular js file. https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...

agentultra 8y ago

I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it. Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard? Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much. The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet? Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.

nicoburns 8y ago
> Has TypeScript caught up with flow in this regard I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference. The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly. You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap

whatever_dude 8y ago

The writing has been on the wall for a very [1] very [2] long [3] time. Facebook and some consumers of their ecosystem have been holding the fort, but it was inevitable something like this would happen. 1: https://npm-stat.com/charts.html?package=babel-core&package=typescript&package=flow-bin&from=2015-01-01 https://npm-stat.com/charts.html?package=babel-core&package=... 2: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0n50hxv,facebook%20flow%20%2B%20flow%20language%20%2B%20flowtype,%2Fm%2F0hjc5m0,%2Fm%2F03yb8hb,%2Fm%2F0h52xr1 https://trends.google.com/trends/explore?date=today%205-y&q=... 3: https://developers.slashdot.org/story/18/11/25/017227/microsofts-typescript-dominates-in-state-of-javascript-2018-report https://developers.slashdot.org/story/18/11/25/017227/micros...

bluepnume 8y ago

I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now. [0]: https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d https://medium.com/@bluepnume/introducing-paypals-open-sourc... [1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-even-with-react-out-of-the-picture-c597187134b7 https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...