7 ms·

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

mattnewton 2y ago
Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code).
- LoganDark 2y ago
  Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?
  - mdhb 2y ago
    The compiler itself lives on but it works with TypeScript now rather than the JSDoc comments style approach which is officially EOL AFAIK.
  - flohofwoe 2y ago
    Closure is still used in Emscripten to optimize the generated Javascript shim file.
  - rty32 2y ago
    This can give you some hints of the current status of closure compiler: https://github.com/google/closure-compiler/issues/2731 https://github.com/google/closure-compiler/issues/2731 I happen to know this because we have some old projects that depend on this and are working hard to get rid of the dependency. I wish Google either updates it or just mark the whole thing deprecated -- the world has already moved on anyway. Relating this to Google's recent cost cutting, and seeing some other Google's open source projects more or less getting abandoned, I have to say that today's Google is definitely not the same company from two decades ago.
- miki123211 2y ago
  Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[function]()` is perfectly valid JS, where the value of `function` might come from the user. A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Because Closure was a type checker and a minifier at the same time, it could minify the properties declared as private, while leaving the public ones intact.
  - wiktor-k 2y ago
    > Something like `foo.bar[function]()` is perfectly valid JS, A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".
    - mkesper 2y ago
      Oh boy, just think functionName and it fits.
  - mananaysiempre 2y ago
    > A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.
    - afavour 2y ago
      Theoretically TS could… until it encounters an ‘any’ type in that code path, then it would have to give up. But there are TSconfig options to ensure no use of any so with the right level of strictness it could happen.
    - epolanski 2y ago
      What do you mean by unsound exactly. I'm asking because there's no accepted definition of what an unsound type system is. What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.
- btown 2y ago
  Google’s Closure Library is fascinating too. It’s being retired, but if you want to build a rich text interface for email authoring that truly feels like Gmail, warts and all, you can just use a pre-compiled version of the library and follow https://github.com/google/closure-library/blob/master/closure/goog/demos/editor/editor.html https://github.com/google/closure-library/blob/master/closur... within a more modern codebase!
- rty32 2y ago
  Closure is almost a forgotten child of Google now. Does not even fully support ES2022 as of today. We are working hard to get rid of it completely. Surprise, lots of important projects still rely on it today.
  - jazzypants 2y ago
    This is true. For instance, React still uses Closure compiler in their build process.
simplify 2y ago
Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.
- sesm 2y ago
  Because Flow is an actual developer tool, not a rent-seeking landgrab with a marketing budget.
  - 9dev 2y ago
    I don’t know what axe you have to grind, but TypeScript is firmly in the hands of the community now. There’s not much Microsoft could do to change that. In what way would it be rent-seeking?
  - recursive 2y ago
    If you're paying rent for typescript, you're doing it wrong.
hajile 2y ago
Flow tries to be sound and that makes it infinitely better than TS where the creators openly threw the idea of soundness out the window from the very beginning.
- machiaweliczny 2y ago
  But in practice is was crap
- draw_down 2y ago
  Maybe FB should have tried putting more than like 4 people on the project then. (Yes I met them all once.)
- ahuth 2y ago
  TS made the choice to be “just JS” + types, and lean into JS-isms. Both choices are reasonable ones to make. Flow has some really cool stuff, and works great for a lot of people. There’s no denying, though, that there’s TS has done something right (even if you personally dislike it)
- idlephysicist 2y ago
  Can you explain what you mean when you say "to be sound"?
  - pansa2 2y ago
    Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695 https://news.ycombinator.com/item?id=41069695
    - recursive 2y ago
      You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.
sesm 2y ago
There was no real competition, Flow was a practical internal tool with 0 marketing budget. Typescript is typical MS 3E strategy with a huge budget. Needless to say, Flow is much more practical and less intrusive, but marketing budget captured all the newbie devs.
- ignoramous 2y ago
  > There was no real competition There was: Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM (2013). Summary: https://g.co/gemini/share/a60c3897bae1 https://g.co/gemini/share/a60c3897bae1 / https://archive.is/qJ1wA https://archive.is/qJ1wA
- com2kid 2y ago
  TypeScript was really really easy to get started with back in the day. It allows for incremental correctness, has good docs, and good tooling. On top of that a lot of beginner React tutorials started out with TypeScript, which onboarded a lot of new engineers to the TS ecosystem, and got them used to the niceties of TS (e.g. import syntax).
- treflop 2y ago
  Have to disagree. I tried Flow irrespective of marketing and didn’t think it was polished. Kept running into type situations that the language didn’t support well. Kept bugging out in my IDE. Had no elegance.
  - spoiler 2y ago
    When I last used it, as a type system it was much better than TypeScript. A lot of flow features now exist in TypeScript though too. One big annoyance with Flow I had is like you said: unpolished tooling. Another was frequent breaking changes (I don't hold it against them too much, it was 0.x software after all) Also because features diverged, you had to maintain type defs for multiple versions of flow for for multiple library versions. And then at one point, they also decided to convert internal errors to any types instead of displaying the error. That was the last straw for me, especially since I maintained a few flow type defs. I spent _so_ much of _my_ time just on type def maintenance for open source libraries already, with the any decay I like flying blind too. So I just switched to TS with its interior type system: it was good enough and others maintained library typedefs for me. But now the type systems are much more closely aligned (unless flow drifted), so switching to TS paid off in the end.

mattnewton 2y ago

Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code).

LoganDark 2y ago
Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?
- mdhb 2y ago
  The compiler itself lives on but it works with TypeScript now rather than the JSDoc comments style approach which is officially EOL AFAIK.
- flohofwoe 2y ago
  Closure is still used in Emscripten to optimize the generated Javascript shim file.
- rty32 2y ago
  This can give you some hints of the current status of closure compiler: https://github.com/google/closure-compiler/issues/2731 https://github.com/google/closure-compiler/issues/2731 I happen to know this because we have some old projects that depend on this and are working hard to get rid of the dependency. I wish Google either updates it or just mark the whole thing deprecated -- the world has already moved on anyway. Relating this to Google's recent cost cutting, and seeing some other Google's open source projects more or less getting abandoned, I have to say that today's Google is definitely not the same company from two decades ago.
miki123211 2y ago
Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[function]()` is perfectly valid JS, where the value of `function` might come from the user. A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Because Closure was a type checker and a minifier at the same time, it could minify the properties declared as private, while leaving the public ones intact.
- wiktor-k 2y ago
  > Something like `foo.bar[function]()` is perfectly valid JS, A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".
  - mkesper 2y ago
    Oh boy, just think functionName and it fits.
- mananaysiempre 2y ago
  > A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.
  - afavour 2y ago
    Theoretically TS could… until it encounters an ‘any’ type in that code path, then it would have to give up. But there are TSconfig options to ensure no use of any so with the right level of strictness it could happen.
  - epolanski 2y ago
    What do you mean by unsound exactly. I'm asking because there's no accepted definition of what an unsound type system is. What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.
btown 2y ago
Google’s Closure Library is fascinating too. It’s being retired, but if you want to build a rich text interface for email authoring that truly feels like Gmail, warts and all, you can just use a pre-compiled version of the library and follow https://github.com/google/closure-library/blob/master/closure/goog/demos/editor/editor.html https://github.com/google/closure-library/blob/master/closur... within a more modern codebase!
rty32 2y ago
Closure is almost a forgotten child of Google now. Does not even fully support ES2022 as of today. We are working hard to get rid of it completely. Surprise, lots of important projects still rely on it today.
- jazzypants 2y ago
  This is true. For instance, React still uses Closure compiler in their build process.

simplify 2y ago

Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.

sesm 2y ago
Because Flow is an actual developer tool, not a rent-seeking landgrab with a marketing budget.
- 9dev 2y ago
  I don’t know what axe you have to grind, but TypeScript is firmly in the hands of the community now. There’s not much Microsoft could do to change that. In what way would it be rent-seeking?
- recursive 2y ago
  If you're paying rent for typescript, you're doing it wrong.

hajile 2y ago

Flow tries to be sound and that makes it infinitely better than TS where the creators openly threw the idea of soundness out the window from the very beginning.

machiaweliczny 2y ago
But in practice is was crap
draw_down 2y ago
Maybe FB should have tried putting more than like 4 people on the project then. (Yes I met them all once.)
ahuth 2y ago
TS made the choice to be “just JS” + types, and lean into JS-isms. Both choices are reasonable ones to make. Flow has some really cool stuff, and works great for a lot of people. There’s no denying, though, that there’s TS has done something right (even if you personally dislike it)
idlephysicist 2y ago
Can you explain what you mean when you say "to be sound"?
- pansa2 2y ago
  Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695 https://news.ycombinator.com/item?id=41069695
  - recursive 2y ago
    You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

sesm 2y ago

There was no real competition, Flow was a practical internal tool with 0 marketing budget. Typescript is typical MS 3E strategy with a huge budget. Needless to say, Flow is much more practical and less intrusive, but marketing budget captured all the newbie devs.

ignoramous 2y ago
> There was no real competition There was: Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart https://www.youtube.com/watch?v=5AqbCQuK0gM https://www.youtube.com/watch?v=5AqbCQuK0gM (2013). Summary: https://g.co/gemini/share/a60c3897bae1 https://g.co/gemini/share/a60c3897bae1 / https://archive.is/qJ1wA https://archive.is/qJ1wA
com2kid 2y ago
TypeScript was really really easy to get started with back in the day. It allows for incremental correctness, has good docs, and good tooling. On top of that a lot of beginner React tutorials started out with TypeScript, which onboarded a lot of new engineers to the TS ecosystem, and got them used to the niceties of TS (e.g. import syntax).
treflop 2y ago
Have to disagree. I tried Flow irrespective of marketing and didn’t think it was polished. Kept running into type situations that the language didn’t support well. Kept bugging out in my IDE. Had no elegance.
- spoiler 2y ago
  When I last used it, as a type system it was much better than TypeScript. A lot of flow features now exist in TypeScript though too. One big annoyance with Flow I had is like you said: unpolished tooling. Another was frequent breaking changes (I don't hold it against them too much, it was 0.x software after all) Also because features diverged, you had to maintain type defs for multiple versions of flow for for multiple library versions. And then at one point, they also decided to convert internal errors to any types instead of displaying the error. That was the last straw for me, especially since I maintained a few flow type defs. I spent _so_ much of _my_ time just on type def maintenance for open source libraries already, with the any decay I like flying blind too. So I just switched to TS with its interior type system: it was good enough and others maintained library typedefs for me. But now the type systems are much more closely aligned (unless flow drifted), so switching to TS paid off in the end.