Comment by andybak | Hacker News Reader

Comment by andybak | Hacker News Reader

Parent Full thread

My feeling is that people need to stop building graphical node editors until we've solved some basic issues and agreed on some common standards.

1. Playing nice with version control. Opening a graph and moving a node by one pixel should cause not merge conflicts. Stop mixing logic and layout together.

2. Lossless round-tripping to a human-readable text format. Text editing tools are insanely powerful for many things. Not being able to use them is a huge drawback of node-based development

3. A common format that allows people to build tools that are agnostic to your specific environment. Node editors themselves should be like IDEs - not tied to a specific app. I don't use a different code editor when I switch from Godot to Unity - why is the node editor any different.

4. Just better everything. Batch/bulk changes, search/replace, auto-align. The quality of these essential features varies from "passable" to "what?"

Everyone is reinventing the wheel all the time. Every platform, app, environment has it's own way of editing node graphs. And most of them suck. The amount of wasted effort for mediocre outcomes...

Finally - are we sure node graphs are the best metaphor? Modifier stacks (like 3DS Max) give you 80% of what you want for many use-cases and they are a lot easier to learn and use.

Event grids are great for many things - and again they are much simpler.

Maybe node graphs should be the "expert mode" not the default (although the real "expert mode" is surely good old text coding - with all it's faults)

Have you seen the Haystack editor? Addresses some of this: https://github.com/haystackeditor/haystack-editor

I am interested in “node-based” design tools and libraries, given the convergence of editors and whiteboards within the knowledge management domain (Obsidian canvas, Heptabase), and they are encountering the kinds of issues you noted. The generative AI boom has been pushing this along very quickly, by improving and creating libraries to support tools like ComfyUI, DAG visualizers, and knowledge graphs; these solutions being so “close to the code”, I am hopeful they’ll be solved.

The Haystack Editor has been mentioned here previously, and seems quite promising.

It makes an interesting contrast to:

https://leo-editor.github.io/leo-editor/

I wound up using TeXshop/TeXworks with a Literate Programming setup I hacked together with a bit of help from A.X. on tex.stackexchange:

https://tex.stackexchange.com/questions/722886/how-to-write-...

My first thought was "I didn't mean browser-based GUIs" but then I paused.

It still feels wrong for the kind of apps I'm usually thinking of when people talk about node editors - none of them are web apps.

But I guess convergence and all that.

To me, it’s always been strange that we speak of “node editors” as the concept here, when the defining abstraction is the data structure of a node graph representing a dataflow.

Specifically:

• with the graph having an associated schema that defines node types;

• where each node type has fields, properties, and connectors;

• where fields are (potentially runtime data-bound) inputs, with types that define their data type, bounds, quantization, etc. and thus equate to a single optimal choice of input control;

• where properties are like fields, but always runtime data-bound, and read-only;

• where connectors are the actual graph vertices; are owned by specific nodes; are directional (in/out/inout); pair with other connectors on other node types, with connections permitted through each connector specifying an interface type that matching connectors must implement;

• where node-level connectors have a “purpose” (registered UUID) that may define how they are rendered at the UX level (e.g. “input” purpose = top or left sticky-outy knob; “plugin inout” = black internal rectangle; etc)

• where all fields have implicit inout connectors to control and/or sample their value; and where all properties have implicit out connectors to sample their value.

(Also, optionally: with sets of nodes able to be encapsulated into groups, with connectors of nodes exposed as connectors of the group, and connectors outside the group able to connect only to the group’s exposed connectors.)

A nodal dataflow graph document, then, would consist of 1. a schema (embedded or referenced); 2. a set of nodes, with groups; 3. the initial values for all fields without schema-specified default values; and 4. the connection edges between connectors.

Note how none of that defines what a program should actually do with a given nodal dataflow graph document, even when it has a well-defined schema.

This is on purpose; to me, a “nodal dataflow graph document” should be a thing like an XML document — able to be processed by domain-specific tools, but also by general-purpose tools. A nodal-dataflow-graph editor, could potentially be such a general-purpose tool.

(When using general-purpose tooling, you’d lose any rendering for domain-specific types in fields/properties, and you wouldn’t be able to “run” the graph… unless these documents could point to logic allowing a generic editor to understand domain types — like HTML5 does with JavaScript-based Custom Element definitions.)

Great comment! I also struggle with the terminology, but from a much less cogent perspective :). It’s all over the place. As I dig into the existing libraries for tools like this in github, I keep finding new Topic terms that revolve around many of the same ideas: “dataflow”, “node based”, “graph”, “canvas”, “whiteboard”, “diagrammer”, “workflow”, “drawing”, and on. Systems being built with these components are blurring the lines between graph, diagram, and even text editor, and so maybe I am unfair to criticize; after all, it’s almost as difficult as cache invalidation.

> 3. A common format

I'm not convinced this is possible. Text is simple which is why it is easy to make multiple editors. Most other things are not.

For example imagine structured drawing programs. Some might support circles, others might support ovals. If the 2nd one writes an oval and the first one doesn't support ovals then it's no longer portable. You can't think of all the features you could possibly want therefore you can't have a portable format. Even for the same features, one app might store a circle as center+radius and another as left corner+right corner of it's bounding box, and yet another as center+widthRadius+heightRadius and another as center+angleOfRotation+2radiuses and another as radius+group(scale/rotation/position)

You can see this issue throughout structured drawing programs. Illustrator,Affinity Design, Inkscape. They might all export/import to SVG but they lose all the data that makes them editable because every app supports different features and or similar features but defined in different ways.

Even pixel image formats are not portable for all the same reasons. Yes you can load/save a PNG from any image editor. But, generally, trying to load the apps own format, the one where it's still in a more editable format, into another editor is at best a lossy feature and usually not supported. It's lossy, because the editor doing the loading doesn't support every feature of the other app. For example, Photoshop supports "smart layers" (layers where the data is not rasterized into the layer but rendered on demand). Those layers can contain PDFs. So your app needs a PDF renderer to load and render them and keep them editable.

Node editors will arguably have all the same issues. The simplest example is that they might all support different widgets inside the nodes. A music node editor might show waves, or knobs. A graphics node editor might show a spinible cube/sphere preview. A node editor for tablets will also likely have a different UX.

I agree that it would be tough to create a uniform standard; there’s at least one library that tries to use/extend SVG features for defining node shapes, and even they admit it’s a PITA and so provide programmatic wrappers: [GoJS Geometry](https://gojs.net/latest/api/symbols/Geometry.html)

They leverage SVG Paths [1] to define node/object shapes, and so you can use Bézier curves and other entities defined in the SVG spec in your graphs [2]. Alternatively you can just reference .svg files. They have a lot of cool samples [3]. I don’t remember where I came across it, but I’ve been digging through github to find the libraries that popular tools use; there are 3k forks, so somebody likes it.

1. [SVG Paths](https://www.w3.org/TR/SVG/paths.html) 2. [GoJS Path Strings](https://gojs.net/latest/intro/geometry.html) 3. [GoJS Samples](https://gojs.net/latest/samples/)

Then you need to have editors specify which features they support and create common standards to make sure that two editors that support the same feature can actually understand each others' encodings of it. It's unfortunately too true that we will never have a single, perfect standard in any domain. It falls upon us to create smaller standards and be explicit in which ones we each dabble in. Otherwise there are no standards at all.

Surely it's no different to how IDEs can support autocomplete and intellisense for multiple languages. Something like a LSP definition would tell the editor what nodes were supported and what the syntax rules were.

Previews and feedback would be the toughest problem - a lot of node editors are very closely tied to rendering (or the equivalent) and real time feedback is common.

But - these are challenges more than they are blockers.

They aren't. For proof I give 50 years of this problem not being solved anywhere except text files effectively because text files have no structure except line feed.

There is no universal format for formatted text. You could point to HTML but try exporting to HTML from Word and then importing back in and you'll see what's missing. There is no universal format for structured graphics. No universal format for raster graphics. No universal format for 3D. No universal format for spreadsheets. Etc.....

They all have the same issue. There are infinite possible features and infinite possible ways to represent those features, each with their own tradeoffs.

And yet somehow every day people are importing files from one application into another application.

A solution doesn't have to be 100% to be useful. 3D file formats are a complete mess and yet somehow movies get made.

> are we sure node graphs are the best metaphor? Modifier stacks (like 3DS Max) give you 80%

Worth noting that, generally speaking, a linear sequence of modifier steps is what we get as the output of a topological sort on a DAG.

Meaning, it is indeed simpler and easier to reason about if we just let the user define and manage that list, as opposed to building a graph which then produces that list.

It seems like both concepts can happily coexist, if the task runner just needs a list of tasks. Then any structure that can be transformed into a list can work (list, tree, graph), and then a “modifier stack generator” can transform a tree using a tree search, or a graph using a topological sort (or whatever algorithm is appropriate based on the kind of graph).

Not all node graphs are DAGs - a lot of audio platforms allow cycles I believe.

But I'm thinking more about how the user would want to interact with the system.

The trouble with graphs is that they tend to nudge you towards spaghetti and they tend to force micromanagement of layout on you. Smart autolayouts alleviate this latter point somewhat but you also lose some of the semantic value that spatial organisation provides.

Depending on the application you tend to most be doing "fan out" or "fan in" - most of the graph is a tree. "Fan in" is easy to handle in a stack. A modifier takes another stack as input. The other stack doesn't have to live somewhere different spatially - it can just be hidden and shown as needed.

I just don't want to spend my time tidying up my graph and zooming in and out just to see things. Node graphs are probably responsible for a decent chunk of the sales of incredibly large monitors! I like to work on a small-ish laptop and I have the eyesight of a middle-aged man.

Excellent points.

(much of the below has been posted in other discussions here, my apologies to folks who are seeing it for the _n_th time)

This is a sort of tool I've believed in/wanted for a long while (and I've been funding the author and chatting with him on Discord and via e-mail), but there seem to be a few fundamental issues which good answers need to be found for:

>What does an algorithm look like?

Can such visual tools be expressive enough to justify the effort?

They seem to work well for problems which can be expressed as one screen of diagram --- and while making modules would seem an easy way to increase the complexity, this goes against the initial mode of expression and if overdone, results in the wall-of-text one is trying to escape from, just dressed up in colored boxes and lines. Once one starts to scroll, or can't see the entire flow at a glance, things get complicated.

And of course, there are collections such as:

https://blueprintsfromhell.tumblr.com/

https://scriptsofanotherdimension.tumblr.com/

which might be used as arguments against.

I've been using:

https://www.blockscad3d.com/editor/

but it doesn't support all of OpenSCAD (and has some annoying bugs in what it does try to implement) and also funded:

https://github.com/derkork/openscad-graph-editor

but it has problems with a stylus (I have to leave the Windows Settings app open to toggle stylus behaviour which is enough friction that I don't use it as much as I would otherwise).

Hopefully the author will pop in and share a bit.

What are the advantages of modifier stacks?

Simplicity. Compactness.

point 1 sentence 2: s/should cause/should not cause/

Thanks. Fixed.

Reply on news.ycombinator.com