I like the "visual abstraction" vs "visual representation" distinction, and agree with your point that Flyde falls into the latter.
Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?
That way, yes. I mean a transformation into spatial problems in much the hardware design way, e.g. the "I need to find a way to add that node without crossing any wires" way. Your example is surely elegant for Promise.all(), although it's a happy path. Can users manage rejected promises, Promise.any() or Promise.allSettled() through nodes and wiring (i.e. not through hidden configuration)?
I think so, yes.
A rejected promise is equivalent to a node that throws an error. Flyde exposes a default "error" output pin for each node. As everything in Flyde is async, any error thrown can be viewed as a rejected promise.
Promise.any can be achieved with 3 promises and a throttle node
Promise.allSettled translated to connecting the error output pin and hooking it to whatever you wanted the fulfilled value to go.
Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?