Show HN: React Flow – library for creating node based editors and apps
github.com
github.com
Also I see you depend on d3, where do you use it for?
(Edit: is it Airflow?)
I'm curious if that's your inspiration.
https://dl.dropbox.com/s/kxlzlqypn0nz8bw/Screenshot%202021-0...
...last week. Hooray for HN!
It is not as well documented though.
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.
[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
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).
yes
Also "node-based" doesn't mean the usual run-javascript-in-backend node, but the diagram nodes.
“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.).
The algorithm for drawing an edge between nodes, for instance, doesn't seem magical (just a spline or beizer curve) - but only because the library doesn't care about routing edges around nodes. Layout isn't magical because you're doing it manually - unlike graphviz/xdot, for instance.
Does this library have magic, or is it, instead, the product of a lot of elbow-grease?
If it was the latter, I'm not going to complain - I'll take a pre-written library over doing it myself in a heartbeat - but, as I'm not a web developer, I wonder if I'm missing something, and it's interesting for me to taxonomize things.