Hi, here's a short introduction video about my flow-based-programming project: . In the near future I'll upload more videos to talk and show more deeply about the project, but I hope that this video already gives you an idea of what I am creating

Looks good. Am I understanding right that the nodes/arrows only show what are the inputs, and all actually calculations are specified in (textual) code?

Thanks, and I'll try to explain: Each node has a property taskType which specifies the plugin which is used when the node is executed. The plugins determine the parameters that they need. The expression task which calculates the body mass index is an example of such a plugin. The whole flow is actually stored in json format as an array : both nodes and connections are stored in that array. The json is executed by code, and it is used to setup rxjs observables and trigger the attached plugins

What happens if two branches - or conditions - overlap? Or put in another way: What happens at the point where you have multiple arrows as input?

Basically a node gets executed when it gets called via an input. A node can be triggered multiple times, so if it has 10000 inputs, it gets triggered 10000 times. At least in theory because it depends on the type of nodes and how the flow is setup, for example if the flow has conditional nodes it can happen that nodes don't trigger their output. And some nodes trigger multiple times (in the typescript implementation a node can return an observable which can trigger multiple times)

Ok, so, the rightmost box. What color does it get when multiple things 'trigger' it with different values? You'd need some order of execution, right?

It gets the last color it got triggered with

What sort of audience do you envision using it, and what kind of analysis/apps do you imagine it being used for?

That are actually the big questions I have myself. I know that I would like to use it myself in production for web and apps which have complex forms which need calculations. But I probably wouldn't use this myself if I wouldn't be in control of the underlaying code and I assume that a lot of other developers who code a lot (and like to code) also think like that. "Citizen developers" could be a potential audience though. I would use it myself on application level and not so much the deep specialized code on lower levels.

I'm attracted to the general approach of being able to write arbitrary expressions or code blocks in the individual blocks (as text) but use a diagram for higher-level code.

One of the current supported use-cases is that you can use the editor locally and run it beside your dev environment. The editor can be easily extended with your own tasks which you can develop in your dev environment. For example if you have a frontend workflow you code the tasks in vs.code in typescript. The same can be done with backend code, I do this myself with a php project. A lot of the typescript code that I've build can already be installed via npm but I am not actively promoting or documenting that, it's there to make it easier for myself at least. But I am also a bit reluctant in putting everything online for free because I am still thinking about a business model

It would interesting if a node could output the JSON for another graph of nodes (which would probably require a diffing algorithm to prevent having to recreate the whole thing each time, like a vdom)

One of the items on my backlog is to load parts of the flow dynamically to be able to run flows at scale. My concerns is that this cannot grow indefinitely, parts of the flow also need to be removed from memory dynamically and loaded again when needed. Probably a flow needs to be really really big before this is a problem nowadays. Is this what you meant?