Isn't this what Dash[1] does? You can see a very similar graph in the built-in debugging tools.
Show HN: Octopus – a directed acyclic graph for app development
11–20 of 49 posts
Re: Show HN: Octopus – a directed acyclic graph for app development
#12A) I agree with many of the comments here arguing that this is not necessarily a new technique, and
B) you’re gonna go far in this life, I’d bet! I know nothing about you but this whole README just reeks of a bright young thinker who’s not afraid to question existing paradigms and can follow through on their conceptual vision. Plus it helps that you’re a very dramatic and effective writer. I encourage you not to let any of this feedback get you down!
Will sit down with the repo myself later, just for me it’s not an angle of HCI I’ve examined explicitly, at least for very long.
Re: Show HN: Octopus – a directed acyclic graph for app development
#13well, partially because there's no license in your repo so unless you're selling it to someone ... what outcome are you expecting to happen?
Great message (“you forgot a license!”), not a very necessary tone IMO! Not to be the hall monitor…
Re: Show HN: Octopus – a directed acyclic graph for app development
#14A) I agree with many of the comments here arguing that this is not necessarily a new technique, and B) you’re gonna go far in this life, I’d bet! I know nothing about you but this whole README just reeks of a bright young thinker who’s not afraid to question existing paradigms and can follow through on their conceptual vision. Plus it helps that you’re a very dramatic and effective writer. I encourage you not to let…
> it’s not an angle of HCI I’ve examined explicitly, at least for very long
If you're looking for additional reading then it's arguable that Reacts matches this viewpoint but any web framework from the past few years using signals (re-popularized by Solid) is explicitly this approach. Most frameworks don't opt for graphical node editors and I've never liked the approach but I've seen a number of those as well.
More generally this falls into dataflow programming which has had a number of published papers starting in the late 80s I believe.
If you're looking for a similar computer sciency approach to UI structure you can look up statecharts which is an older idea that formed the conceptual basis for Ember Router and, in turn, most js framework routers in the past decade.
Re: Show HN: Octopus – a directed acyclic graph for app development
#15The browser is already a graph. Or am I missing something?
The special property of a DAG is that there are no cyclic paths between nodes. In the DOM, every node has a path to every other node, so you can create infinite loops (e.g. element.parentNode.nextElementSibling.previousElementSibling.firstChild).
That's the document tree - when it comes to application state, which is just data in memory, anything is possible. These state libraries tend to treat in-memory application state as the "real" state, and try to treat the document tree as a side effect. This is one reason that front end unit tests tend to miss bugs - application state being what you expected doesn't mean the user sees what they expected.
Re: Show HN: Octopus – a directed acyclic graph for app development
#16The browser is already a graph. Or am I missing something?
The special property of a DAG is that there are no cyclic paths between nodes. In the DOM, every node has a path to every other node, so you can create infinite loops (e.g. element.parentNode.nextElementSibling.previousElementSibling.firstChild). That's the document tree - when it comes to application state, which is just data in memory, anything is possible. These state libraries tend to treat in-memory application…
[deleted]
Re: Show HN: Octopus – a directed acyclic graph for app development
#17I remember working at a company where we had a backend web framework that was essentially a DAG. You could use it to create API's where the caller simply specifies what they want, and the server figures out, through graph theory, what series of processing steps and API calls to other services should be performed (some of which can have dependencies on the results of other API calls and/or processing steps), and the optimal way to parallelize them.
It struck me as being both a very intriguing framework, and also exceptionally over-engineered for the kind of problem it was solving (since an async-await architecture gets you all the same benefits).
Re: Show HN: Octopus – a directed acyclic graph for app development
#18A) I agree with many of the comments here arguing that this is not necessarily a new technique, and B) you’re gonna go far in this life, I’d bet! I know nothing about you but this whole README just reeks of a bright young thinker who’s not afraid to question existing paradigms and can follow through on their conceptual vision. Plus it helps that you’re a very dramatic and effective writer. I encourage you not to let…
This is exactly my take. I love anything that makes it easier to track state and transitions. Especially so if it’s a framework for generalizable applications.
Re: Show HN: Octopus – a directed acyclic graph for app development
#19The DAG framing might miss the key points and attract contention.
The "law of Demeter" is a design rule that says to only work with data you directly know about - i.e., friends, but not friends of friends. It make local reasoning tractable and forces any (friendly) use to be surfaced as such, which gives a better way to assess global complexity. (By contrast, the DOM is just, well, global state, whatever the data structure.)
But who or what is "you"? In this case, the node, which is responsible for (local) data liveness; a UI as simply derived nodes from that, with cross-node validation dependencies represented as graph dependencies.
Modeling overall system activity as graph updates does provide nice separation to permit concurrent programming, with graph structure as the arbiter of conflicts, but you'll need a more specific notion of "consistency" that can distinguish the use cases this would work for.
The comparison and question would be with various UI and data component systems, which handle data mapping to the back-end, cross-component aspects like themes or device constraints, user id and security, etc.: how are these higher-level concerns managed with an iterative graph structure?
Serialization is a nice sample concern, but your (attractive) approach exemplifies the issue: to make it work entails tracking some conventions/responsibilities, which are not captured by the DAG framing.
For me, frameworks work when the types basically constrain developers into doing the right thing. Local reasoning and responsibility translate directly to local code, and proof relates directly to compliance, preferably at the language level at build time.
These kind of local-reasoning models shine when the code is federated, e.g., when hosting multiple services and contributions. The whole app should just work if the participants can be validated on load/launch, and any failures should be restricted to the local nodes instead of cascading. So if you target an app requiring some specific collaborative domain (with a promising business model), this proposal might draw more attention, and you can work through issues concretely.
So perhaps target a killer app, build understandable constraints into the code, and demo key features.
Re: Show HN: Octopus – a directed acyclic graph for app development
#20How is React state not a DAG out of the box? What problems does this solve? The pitch appears to be: > any outside change (user action, api result) unleashes a graph traversal. Our UI components become much simpler, because they just need to dumbly reflect values in the graph. But that sounds the same as the reasoning behind React's one-way data flow.
It's very different. Your react components are organized in a tree that mirrors your DOM. If you're using React without an additional state management package, you need to hoist your shared state to a common ancestor, then prop drill it down to where it's needed. Nightmare. I'm advocating a graph that mirrors your subject domain, unconstricted by your DOM. Also, my graph is constructed from below, which feels very intuitive. Nodes specify who they want to read. You make no change to the node being read.