2026: The year of the node based editor(medium.com)
medium.com
2026: The year of the node based editor
https://medium.com/@fadimantium/2026-the-year-of-the-node-based-editor-941f0f15d467
4 comments
TikZ, SVG, PNG, notebooks, code. These are all different ways of carrying "the same" idea, but each preserves different features. Today the user shuttles artifacts through representations and tools. MCP solves some of the plumbing, agents can call tools, but it doesn't solve representation-choice: what should be canonical, which conversions are lossy, or where edits can round-trip.
I come from a background of electrical engineering, and have found schematic capture to be much faster, clearer, and less error prone than programming or description languages. Schematics cannot be updated after a product is shipped, without having the product shipped, cut with a knife, jumpered and soldered, tested, and shipped again, so it is very important that a design is fully functional and qualified before testing. If something better than schematic capture existed, the industry would quickly jump to it.
This absolutely does not translate to current node-based editors. Earlier attempts with block-based editors, like Scratch and Blockly, were just discreet lines of code that could be rearranged with a mouse, giving them all of the elegance and power of a programming language, with all the readability and maintainability of a programming language.
Node-based environs do expand on that, by allowing nodes to be placed anywhere, and allowing single outputs to lead to multiple inputs. This does give the flexibility of a schematic, but the way it's implemented hurts readability, instead of improving it, making its use a laborious and error-prone process. I once tried to do some simple math in ComfyUI, and it took over an hour to get a handful of operations linked properly, when it would've taken minutes with schematic capture or a programming language.
The image in the article (https://miro.medium.com/v2/1*ASetOBQ2eRdZUi_5VA5hGQ.png) is a great example. There's a column of indistinguishable nodes running down the center of the image, and it's nearly impossible to tell what the nodes on the right side of the image are linked to, because the links are obscured by the nodes themselves.
Compare that to a simple device like a soldering iron (https://files.pine64.org/doc/Pinecil/Pinecil_schematic_v2.0_...) or something as complex as an entire laptop (https://files.pine64.org/doc/pinebook/pinebook_mainboard_sch...). Though the soldering iron is simple for an electronics schematic, fitting in a single page, it is far more complex than even the most complex files that are workable in a node editor. The laptop has multiple pages of schematics, with a block diagram connecting them, but is just as easy to follow as the soldering iron.
Node editors do support hierarchy, but the links are what really suffers. There's no busses and no built-in support to route and branch links while placing them, so you either get a mess of automatically-drawn links, with all branched at the output nodes, or spend a bunch of time placing reroute nodes to get something that is readable, but impossible to edit.
This absolutely does not translate to current node-based editors. Earlier attempts with block-based editors, like Scratch and Blockly, were just discreet lines of code that could be rearranged with a mouse, giving them all of the elegance and power of a programming language, with all the readability and maintainability of a programming language.
Node-based environs do expand on that, by allowing nodes to be placed anywhere, and allowing single outputs to lead to multiple inputs. This does give the flexibility of a schematic, but the way it's implemented hurts readability, instead of improving it, making its use a laborious and error-prone process. I once tried to do some simple math in ComfyUI, and it took over an hour to get a handful of operations linked properly, when it would've taken minutes with schematic capture or a programming language.
The image in the article (https://miro.medium.com/v2/1*ASetOBQ2eRdZUi_5VA5hGQ.png) is a great example. There's a column of indistinguishable nodes running down the center of the image, and it's nearly impossible to tell what the nodes on the right side of the image are linked to, because the links are obscured by the nodes themselves.
Compare that to a simple device like a soldering iron (https://files.pine64.org/doc/Pinecil/Pinecil_schematic_v2.0_...) or something as complex as an entire laptop (https://files.pine64.org/doc/pinebook/pinebook_mainboard_sch...). Though the soldering iron is simple for an electronics schematic, fitting in a single page, it is far more complex than even the most complex files that are workable in a node editor. The laptop has multiple pages of schematics, with a block diagram connecting them, but is just as easy to follow as the soldering iron.
Node editors do support hierarchy, but the links are what really suffers. There's no busses and no built-in support to route and branch links while placing them, so you either get a mess of automatically-drawn links, with all branched at the output nodes, or spend a bunch of time placing reroute nodes to get something that is readable, but impossible to edit.
tbf, node based editors have been "the year of" every year since blender. they all look like a murder board to me! comfyui especially has a terrible ui/ux IMO
weavy seems kind of smart, for ai-gen video, if you're into that kind of (fucked-up) thing.