Interestingly of those 3 the only one where I got to a page where I could try out the product was litegraph but that got me to an empty screen - the other two were with signup (n8n) or "sorry our product is broken"-popup (total.js).
Probably the lesson is that a browser-based node-flow-visual-programming tool for profit-and-gain should have an working example page (without signup please!)
I think what Node-RED does right is the one-or-zero inputs and no typing of inputs/outputs - most node programming environments have types for their inputs, confusing me no end. Admittedly most use colours to distinguish types, so one learns red outputs can only go into red inputs (for example).
IMHO Node programming is confusing enough (for beginners) without having colour coded inputs/outputs. I personally hope Node-RED sticks to the grey one-or-zero concept.
I think it really depends on the application as to whether an event-based or graph-based nodes are a better fit. IMO, graphs are better for introducing complex and simultaneous functionality, like in audio-visual or state-based systems. Event based applications are easier to start with and they make sense for much more linear systems like IoT and industrial settings.
If I understand correctly, things like noisecraft are clock-based state machines - i.e. everything is synchronised to a clock and states change with the tick of the clock. So in a sense each wire is always on and has some value that is read with the clock goes tick. In Blender I'd guess that would be frame counter.
While Node-RED is event-based and data-driven meaning that data flows when events happen otherwise the wires or pipes are empty or off. Node-RED describes action that should happen when something does happen!
Fun to think of seeing two identical flows yet their outcomes or meaning is completely different since one is event-driven and the other is a state machine!
So I wrote my thoughts down in pipes, wires & nodes, for me it seems that visual programming and the representation of flows will become more confusing since they all look the same but can be completely different.
Compared to textual programming language, one can visually recognise the difference between lisp code and java code and thereby one knows what the underlying concepts of the program are: object oriented programming or list-based functional programming - this isn't possible in a visual programming world.
You might be able to but I know a lot of people who wouldn't. And I've seen plenty of Java code that might as well be Lisp!
But how many people would know the difference in approach without doing some research if they'd not come across either language before?
So maybe we are over-thinking things here? I'm not convinced it matter that much as long as there is clear and accessible information on the basics of how the platform works and what the differences mean.
For example, my tongue-in-cheek explanation of Node-RED's approach really doesn't matter to most people - at least until they get into more complex concepts. That a message doesn't really "flow" is not important to start with, only that it appears to do so.
To me, I think the most important difference in approaches of different visual programming tools is whether the flow is linear/synchronous or asynchronous. Node-RED is asynchronous which is why only a single input port exists for each node. Most visual programming tools have multiple ports because the coupling between nodes is tight, not loose like Node-RED. So a node defines input variables that translate to input ports, 1 for each variable. Node-RED uses loose coupling with its "message" based approach.
Most people would literally not know how to use a keyboard - 8 billion, some 2 or more billion living in poverty who would never have seen a keyboard. Then probably another 2 billion who are barely surviving and are happy to know how to use a mobile phone. Of course, most people won't give a flying banana what we're discussing here
The point is not to reach everyone, the point is to leave bread crumbs for people who come along and start thinking about these things. Little bread crumbs to follow along the trail of learning Node-RED and discovering visual programming.
There isn't a single approach to explaining Node-RED to others, and the more I try to explain Node-RED, the more I realise that Node-RED is very complex because of its visual programming nature. But that makes it far better in explaining some things than a long text file with some obscure programming language. I also wrote about the visual programming approach and how it comes far more naturally to some people.
Exactly, another approach to explain Node-RED For me I wouldn't see it like you but I understand what your saying. If someone comes along and reads that and suddenly they understand Node-RED, perfect - that's my goal: spreading the understanding of Node-RED and visual programming.
I have a completely different approach to Node-RED than you - that's why I build RSS to node convertors - totally obscure, totally questionable what might be the purpose but totally possible with Node-RED!
One final thing I did today was to explicitly convert Python to Node-RED - fun experiment, don't know about what is better but I do know: Node-RED flow is visual and code, that's what UML wanted to be!
Literally it won't be that hard to build a basic python interpretor for a node Red json file. You just need to emulate the basic nodes (change, switch, join and split) and integrate v8 into python for the function nodes
Having read that discussion I might stay away from a computer on the weekend! It would really make more sense to create a Node-RED.py and not Node.py, i.e. completely build a new visual programming tool (as you suggested in that thread). It's only a pity since the frontend would have to be reimplemented in JS anyway.
What I was thinking of was a simple head-less python engine for interpreting some of the core nodes based on being sent a flows.json from the frontend. I would do that if there was a) a specific use case with b) a specific limited number of nodes involved, i.e., the core logic nodes. But since I don't have a use-case, the weekend is saved!
How does google sheets do that? They seem to have it down pat. Are you planning to have parallel updates of data by multiple users? Or just one user manipulating the data? O(1) or O(n) headaches!
The dynamics are actually quite easy since Node-RED with uibuilder already provides all the tools.
Even the multi-user issue is dealt with already since uibuilder already surfaces a number of properties (client id, tab id, page name, ip address) and custom ones are easily added if needed.
What you do with the data back in Node-RED is, of course, entirely down to your skill with authoring flows and wrangling data.
Actually, another thread reminded me about Perspective | Perspective (finos.org) which does much of what I'm looking for - except one major thing, you cannot update data via the grid as far as I can tell. Which is sad because I can easily create a uibuilder extermal template that would let anyone easily throw a Perspective data view onto a web page. It is just a few lines of code.
It is with a sad heart that we've decided to not pursue monetization of Interface Vision's core technologies. We've done a lot of amazing things, but there just isn't a market for visual programming environments: yet. It will happen: it's inevitable. But just not now.
Seems to have been a 1-man band. Also his list didn't even include Node-RED!!!
And clearly there was already a market when he wrote that, he just couldn't leverage it it would seem. After all, Node-RED dates from before then.
Also annoying that they don't mention Node-RED which is an excellent example of a node graph!
Not really surprising that most of the examples of node-graph processing come from the music and visual world since those are obvious use-cases for the orchestration of, often highly time-dependent, actions. But of course, that is a very different use-case to Node-RED's asynchronous processing that was originally intended to orchestrate sensors and robotic controls.