[HN Gopher] Show HN: Octopus - a directed acyclic graph for app ...
___________________________________________________________________
Show HN: Octopus - a directed acyclic graph for app development
Directed acyclic graphs are muched discussed in comp-sci, but
octopus appears to be the first reusable, turnkey, ready-to-wear,
off-the-shelf implementation of a DAG for application development,
in any language, that I'm aware of. This is remarkable because
DAGs hit a sweet spot in the middle of the three common programming
paradigms (OO, event-driven, functional). Let's have a DAG as the
top-level structure of our applications. Data-fetching and onChange
handlers live in DAG nodes, next to the data they act on. The UI
flows out from the DAG with fine-grained reactivity. Our app state
is effortlessly consistent, because 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. I'm putting this up for a second time.
Absolutely no-one bit the first time, which can't be right :-)
Author : bbsimonbb
Score : 45 points
Date : 2023-12-14 18:36 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kitd wrote:
| > Directed acyclic graphs are muched discussed in comp-sci, but
| octopus appears to be the first reusable, turnkey, ready-to-wear,
| off-the-shelf implementation of a DAG for application
| development, in any language, that I'm aware of.
|
| I may be misunderstanding what this is, but back in the J2EE days
| ISTR Struts having something very similar to this, ie a flow from
| page to page declared apart from the actual page logic itself.
| Edit: and all done in XML, so obviously doesn't count!
|
| Cool project though!
| mdaniel wrote:
| well, partially because there's no license in your repo so unless
| you're selling it to someone ... what outcome are you _expecting_
| to happen?
| bbor wrote:
| Great message ("you forgot a license!"), not a very necessary
| tone IMO! Not to be the hall monitor...
| reactordev wrote:
| The browser is already a graph. Or am I missing something?
| kokanee wrote:
| 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.
| efnx wrote:
| > Directed acyclic graphs are muched discussed in comp-sci, but
| octopus appears to be the first reusable, turnkey, ready-to-wear,
| off-the-shelf implementation of a DAG for application
| development, in any language, that I'm aware of.
|
| I wrote one for Rust called moongraph:
| https://crates.io/crates/moongraph
| https://github.com/schell/moongraph
|
| It powers my configurable renderer and my ECS. I'm sure lots of
| other folks have written their own and they might not even know
| it's a DAG.
| archibaldJ wrote:
| I don't really understand what values such design pattern can
| bring worth (that will outweigh its own complexities)
|
| my experience working with DAGs programmatically (ie not as an
| abstraction (like in React) but actually handling the edges&nodes
| of a graph-based abstraction in code) is that it looks nice
| theoretically but in practice top-down (conceptual) approach like
| this often tends to over-complicate things
|
| would love to see some real-world examples where an actual dev
| team, etc, find values in graph-theortical-based abstractions
| like this
| kokanee wrote:
| How 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.
| hobofan wrote:
| Almost every modern framework is implicitly modeled as a DAG? It
| just rarely used that nomenclature. Heck with Elm a whole
| language exists for that principle.
|
| I'm really not sure what's supposed to be different here. As is
| evident from the repository you obviously know about React and
| Vue, so maybe try to contrast it to them, or how it fits in in
| relation to them? To me it looks like you are building a system-
| in-a-system, where you are rebuilding the primitives that already
| come with React (or any of its peers).
| catapart wrote:
| Like others are saying: I think a lot of modern frameworks
| already fit this mold, or are so close that people can't quite
| tell the difference. But for a near 1-1 example, maybe look at
| XState? Especially given that XState has a visual, graph view
| which interactively indicates state in real time.
| speps wrote:
| Isn't this what Dash[1] does? You can see a very similar graph in
| the built-in debugging tools.
|
| [1] https://github.com/plotly/dash
| bbor wrote:
| A) 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.
| grayrest wrote:
| > 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.
| AndrewKemendo wrote:
| 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.
| wavemode wrote:
| I 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).
___________________________________________________________________
(page generated 2023-12-14 23:00 UTC)