Neat project, awful name. Overloading Flow, an already important part of the React ecosystem, just makes it harder to both find information about your project and find information about Flow.
Yes, there's an active albeit small community there.
I don't think I'd recommend it over TS for a new project by default, unless the person has some specific pain points with TS that Flow would fix. But Flow does still have some neat features - exact types, nominal types, explicit strict variance rules etc. - and performance benefits in large projects that could make one choose it over TS. And they have been streadily improving stuff like editor support, even though admittedly it's still a long long way behind TS.
Our team just migrated (3 mil+ LOC) from Flow to TS in large part due to performance issues with Flow, especially in local development. Our fans have been running a lot quieter since the migration, happy to share more.
Please do if it's not too much trouble. We have gone back and forth with this idea but never did make the jump.
A few random questions off of the top of my head...
Did you use a tool like flow-to-ts to help with some of the rewrites? What version of Flow were you using before? Did you take some special steps to get the TS perform well in the project or was it just better out of the box?
How's the experience been apart from the performance improvement - is there Flow features that you miss and have you done something to accommodate?
Namely, I'm personally a bit sad to loose local function parameter inference, exact types and explcit type assertion syntax.
I'm a bit afraid of bugs coming from excess properties or misspelled optional properties, or from the abuse of TS "as" keyword (which is not the same as Flow's `(foo: Foo)` assertion syntax).
> and performance benefits in large projects that could make one choose it over TS
[citation needed]
A medium size app using Flow would take 10 seconds to type check in an IDE. It's possible we had some issues with circular dependencies but Flow was such a burden to deal with. Not to mention issues where the flow server would chew CPU resources on a dev machine.
Typescript on a much much larger project has had zero issues with performance.
I don't have anything but own anecdotial evidence to provide. Would be cool if there were some good, recent benchmarks between the two, but I wasn't able to find any.
Maybe I've just configured something wrong, but I keep facing this issue where autocomplete stops to think suggestions and might just freeze the whole VSCode for a second. This is in a small project that has some fairly large library definition files (namely, aws-sdk).
If you search for "TypeScript performance", you'll find a bunch of issues and posts discussing the subject, so I don't think I'm totally alone in calling it out.
Granted, Flow gets it's share of similar search results and I have also experienced similar issues where a recheck sometimes takes long and CPU usage jumps very high. This side of Flow has been consistently improving between almost every release, though. Most recently, a couple months back, their switch to this new "types-first" architecture [1] is supposedly unlocking something like 50%-90% perf improvements compared to what they vere before.
My point with this isn't to question your experience with Flow, I've sometimes faced similar issues. I'm just saying that, depending on the Flow version you were using, things may have changed a lot for the better.
Just so that I'm not talking _completely_ out of my ass here, as a quick very unscientific test I cloned the Tutanota project's repo [2]. SCC says there's 967 JS files, consisting of 205433 lines of code in there. Flow version is 0.136, which is a little behind, but they are using the new types first mode.
time node_modules/.bin/flow check
Found 0 errors
node_modules/.bin/flow check 1,00s user 0,11s system 9% cpu 11,905 total
AFAICT at this point it's basically just Facebook projects (since they use it internally) and some older libraries that pre-date TypeScript popularity. I'm not sure there is much reason to choose Flow over TypeScript for a new project in 2021.
Yikes; alternate uses for _two_ already-overloaded terms ("flow" and "node") in the tagline? Naming things isn't _that_ hard. Less of a nitpick and more of a red flag wrt wisdom and experience of the lib's authors.
“Node-based interface” is common for that kind of UI though, the author didn't invent it. It's a shame that NodeJS chose such a common word as its name, but “node” can't be erased from CS just because NodeJS exists (one would have to remove graph theory, cluster grapes, many UIs concepts [tree UI, nodes UI, ...], many 3D jargon, etc.).
