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.
I still think that Node-RED has one of the easiest approaches to get into visual programming, the use of JavaScript objects ("messages") greatly simplifies the visual aspects, minimising the number and spaghetti nature of the wiring.
By the look of things Nodegraph is Meta/Facebook thing that might have been stopped since AI gained traction. Most activity ceased around 2021, coincident? Plus Node-RED isn't react based, Facebook wouldn't push a jQuery based product ...
I agree with you but also understand people have difficulty understanding visual programming. Why did AI take off and Visual Programming (VP) didn't even though usable VP has been around far longer than usable AI? I would suggestion that VP entails higher complexity at the entry level than AI and hence people go the "simpler" path of using AI. In the long term, VP is simpler and more understandable and maintainable but we humans think in terms of minutes, not months.
Speaking of spaghetti, can anyone recommend a library that automagically organises a node graph into a clean layout? Just the way mermaid can layout any diagram, is there something similar for a "random" node graph?
Sorry for the spam, this hacker news discussion from 2019 is quite eye opening since one of the first comment is (highlights are mine):
Experience with tools like Blender or Nuke and particularly with visual programming in games engines is actually where a lot of the better informed dislike of visual programming comes from.
The biggest problem with these tools is scalability and maintainability. You will hear many stories in the games and VFX industries of nightmare literal spaghetti code created with visual programming tools that is impossible to debug, refactor or optimize.
Visual programming seems easy for very small examples but it doesn't scale. It has no effective means of versioning, diffing or merging and usually lacks good mechanisms for abstraction, reuse and hierarchical structure. It doesn't have tooling for refactoring and typically lacks tooling for performance profiling.
[...]
My Conclusion: Visual Programming won't take off unless all the tools that programmers are used to have an equivalent approach in VP - at least amongst programmers. Non-programmers probably won't approach VP since it's even more niche than using emacs and some scripting language such PHP or Python! However Node-RED being Web-based, is the perfect starting point for teaching everyone about VP.
I would disagree that VP didn't take off. It most certainly did. And in many forms. Blockly, for example is used in many (most?) schools to teach computer logic and programming before moving on to written languages (usually Python). And visual tools are used in hundreds of different products and have been available for decades. Blockly, LabView, Microsoft PowerPlatform (itself several generations down a visual programming path), .... - the list goes on and on.
Currently, I would suggest that AI is perceived as an easy way out of having to think about logic at all! Ask a question, get your answer. No need to map out the logic.
Of course, this is a total fallacy. Since the only logic that LLM tools supply is the logic someone else has already laid out. It is a dead-end. But everyone is excited because they think it is a quick and easy way out of having to actually think for themselves. LLM's are also a somewhat dangerous dead-end in that the cost to both train and run them is enormous and likely to be highly unsustainable. Make use of free ones while you can. (Though maybe someone will invent more efficient runtime models, that's the potential of innovation of course).
Not to say that LLM and ML doesn't have a place - and an important one too. But, as usual, it won't be what most people think.
And, on that we certainly both agree.
There are certainly libraries that do this. Let me check my list. I believe that there are a number of layout theories - math approaches - that can be used as well though that is way above my head.
OK, apologies for the length of the following. Not all of it will be relavent - it comes from my Obsidian knowledgebase and lists many of the graph-based libraries and tools that I'm aware of. Certainly some of these have auto-layout capabilities. Even the venerable graphviz has several auto-layout options.
X6 is an HTML and SVG-based graph editing engine that provides low-cost customization capabilities and out-of-the-box built-in extensions to quickly build DAG diagrams, ER diagrams, flowcharts, lineage diagrams, and more.
A dynamic, browser based visualization library. The library is designed to be easy to use, to handle large amounts of dynamic data, and to enable manipulation of and interaction with the data. The library consists of the components DataSet, Timeline, Network, Graph2d and Graph3d.
Sure VP is a thing in many places but in your statement before moving on to written languages is partly what I mean: why isn't learning written programming languages before moving to VP. I kind of mean that when I say VP didn't take off.
Another example: if I want to write a node or two for Node-RED, why is that I have to do that in my text editor (ie. emacs)? If I want to extend emacs, I code that extension in emacs. Yet extensions to Node-RED (and I assume all other VP environments) have to be written in an textual environment.
The concept of visual programming is alive and well but that VP becomes the go-to concept for programming hasn't happened. I know many people believe that VP imagery becomes too complex as more functionality comes along, i.e. visual spaghetti code but Node-RED seems to have found good solutions to that (i.e. subflows, link nodes, groups and custom nodes).
Thank you for that list, gave me plenty of food for thought. I was thinking of how to auto layout a Node-RED flow. A dynamically created flow I should say and I want to automagically layout it out. Again one my off-the-wall ideas of how to use Node-RED!
Ah, sweet! I'll give that a try ... I was playing around with elkjs but it simply won't work in a function node ... I used it directly in node and it worked fine, but as a function node it does nothing.
You can also package a Subflow as a node Packaging a Subflow as a module : Node-RED so yes you can almost create nodes for node-red by using node-red. (A la emacs example you gave)
Thanks for that, I got it working in a flow - that uses the ClientCode node that executes frontend Javascript from a backend trigger. So I took what Nick had done and put it in a client-code node with an inject node attached.
Now anyone who wants an initial layout engine can copy the nodes from the flow above. (Sorry for the own advertising but the flow might genuinely help!)
I saw the subflow extra configuration but never got warm to it, if there was a button "Submit here" ok, I'd go for it but there isn't. Hence my playing around with FlowHub and getting flow sharing done via Node-RED only ... admittedly I have no idea how authentication and trust could work but at least sharing is working!
Plus I would also like to have node development in Node-RED - something to manage the package.json, readme, etc ... the .js and .html are easily taken care of as templates.
I think that it seems hard enough to create a computer language, to then abstract that to a visual paradigm is even harder. Which is why VPL's tend to be in specialist areas where it is easier to apply that, such as music, images and video.
To create a general-purpose visual programming environment is extremely hard. Even Node-RED is far from perfect after all though it has proven very useful in many different use-cases, there is still a lot it cannot do. (Not a particular criticism by the way, just an observation).
Visual tools use models and models are, by necessity, somewhat simplified otherwise they become so complex that the visual aspect is no longer so useful.
Written language, on the other hand, can be extremely complex but still comprehensible. I'm sure there are lots of biological and social reasons for this - I'm no expert.
You don't. You can take a sub-flow and turn that into a node.
Ah, as I said above.
It is indeed, one of the best in my opinion. But it is still FAR from being a complete, open-ended, programming environment. And there are many tasks that are FAR easier to do in language than visually. I don't think that will ever completely change, I believe it is some aspect of our brains. After all, while visual communication (e.g. cave paintings) massively pre-date written language, it would seem that written language was what really triggered the massive innovation across the world.
Summarized: I love it
Thanks for sharing this!! Very useful.
Although your ClientCode node is a very convenient way to implement this, hopefully you (or somebody else) can ever implement this a bit more in the flow editor UI. Not sure if plugins (like this one) can be used for something like that, e.g. to add a new action...
BTW when I imported your flow, it contained a series of html escaped characters:
And some escaped characters are no issue for the Monaco code editor, but the browser doesn't like them:
I should qualify my VP expectations: I spend a lot of time typing on the keyboard when I use Node-RED, no question. So yes, I still do a lot of textual coding and yes, that won't disappear anytime soon (perhaps with a Neuromancer-style direct interface we'll get rid of the keyboard).
But I'm firmly a fan of the the old adage a picture is worth a thousand words - somewhere between all text, no visuals and all visuals, no text is the sweet spot. Where? I don't know. I definitely hope that all that we have learned from textual programming doesn't fall by the wayside - as it happening with AI.
Argh, I can import all I want, it just works - I have had escaped-stuff-problems before in other flows but not in this one - it just works. Using Firefox on Mac ... and those encoding bugs are just rabbit holes (looking at you geolib and the ° symbol).
On the other hand, I wonder why it would do that but not with a normal function node? Perhaps I did code something incorrectly somehow ... I just copied it from the github diff window, nothing special. I'll have an investigate ... thanks for the heads up
I just want to be able to hit the inject button and have things happen in my editor Thanks for the link, I was wondering how to get a user-made header onto Node-RED.
Thank you, much appreciated just as much as I enjoyed finding and using your SVG node Ended up multi-coloured blinking SVGs!
Btw thinking about how to change the code ... first step is width of nodes, the code assumes 200px for all nodes.
It might be useful if some settings were (somehow) easily adjustable, because they are user dependent. For example I like to have a smaller distance horizontally between my nodes, while other users like to have them separated widely...
Not sure if this is somehow related to the Node-RED lint tool settings. Never had time to play with it. Just thinking out loud now...
I'm using document.getElementById(id).getBBox().width to get the width of the node, then there needs to be spacer that can/should be adjustable but to avoid overlap the width of the node needs to be known. Also it's the width of the parent node, which is another issue on its own ...
I also had a look at the flow data for the client-code flow, there is no > in there (for the client code code) - if you edit the node, is there > in the Node-RED editor window?
- I have had escaped-stuff-problems before in other flows but not in this one - it just works. Using Firefox on Mac ... and those encoding bugs are just rabbit holes (looking at you 
