HN user
developer, Lyon, France
If anyone's tempted to visit, the home page is in French. Click on "Chiffrer un produit" and you're into the configurator which has English translation (top right). All the magic is on the third screen, after selecting a category and a product. The disposition of options and choices, plus prices for all choices, plus the 3d rendering, plus all the totals, all recalculate in the browser with zero latency, based on previous choices.
We're off and running, making the world's best configurators for complex products. Our first clients love us. Our configurators implement some very personal ideas about front-end state management, and it's really a thrill to see it all working with real products, 3d rendering and zero latency.
This is worth meditating! The American empire, like the British before it and the other european while we're at it, are flashes in the pan compared to the Romans, the Byzantines, the Ottomans. It could be that hypocrisy, racism and just wanting the oil/diamonds/gold/consumers is not a formula for lasting success.
Good suggestion.
I like and use MobX. I "come from" Vue, and I like mutability (though I concede its dangers). For my needs, the limitation was reactions. In mobx, reactions shouldn't update other observables. In Octopus, chaining is the whole point. Nodes can be stacked to n depth. There is no distinction between state and computed. Computed just generates more observable state.
Then, in Octopus you also get reporting nodes and visualisation, which, once tasted, no return.
So xstate implements state machines. This is quite a different concept from DAGs, though there may be a DAG underneath. This isn't mentionned anywhere though. The concepts you work with are state machine concepts.
I looked at and rejected state machines, because I didn't like/understand the need for the formalism of defining every possible state.
That looks really remarkable.
I'm not doing this for fun. Especially since I'm fundamentally lazy (and more of a practitioner than a comp-sci person). I'm looking at custom configurators for complex made-to-measure products with dozens of options, with many interdependencies between options.
Are you talking about this? https://patents.google.com/patent/US7865872B2/en
I put a concrete example in the sample app. "pizza" depends on "size" and "base". So a DAG, as you point out, is less constraining than a tree. When you shoehorn your state and orchestration into react components, not only do you have to fit them into a tree, it's fundamentally the wrong tree.
That sounds very cool indeed.
No. Signals work with a weak map of references, not a graph. So in my Pizza example, when pizza changes, totalPrice would recalculate twice: once on a signal from pizza, once on a signal from tip. Explicitly constructing the graph dramatically reduces needless recalculation in bigger systems.
That looks interesting, and totally new to me. Thanks.
Have a look at the node code. It's biblically simple. I would say it's much simpler than any comparable solution. You can forget about reducers, thunks, computed, even useState, useContext, useEffect and props are rare. I've stuck with graph terminology: nodes, predecessors etc, but you don't need to grok that stuff to use this. Once you've understood that a node is a value, some methods and a reup() function, that's it.
The graph framing is essential. I use typescript graph libraries for the topological sort and for the visualization. I did much less work than either of those two libraries !
As I've just written above, React components form a tree that mirrors the DOM. A graph is a much better fit. Nodes in my DAG ressemble "computed" in Vue, where they watch a value and recalculate when it changes, but... in Vue the watched value needs to exist, ie you're responsible for constructing the graph and ensuring no cycles, and the computed value is only available locally, to be used in the template. In my DAG, you just name the thing you want to watch, octopus checks for cycles. Plus you get the visualization.
The closest thing I'm aware of is Jotai. Atoms in jotai can take dependencies on other atoms, so forming a graph.
Reporting nodes in Octopus are, I believe, completely new. You can create nodes that select their predecessors with a filter function. So the "totalPrice" node takes a dependency on any node with a price property, and recalculates when anything with a price changes.
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.
Cone looks fantastic. You're going to make me buy an IPhone.
Sorry for the trouble you had to go through to get there, but that looks really useful.
I found state management too boilerplatey and full of concepts. I thought the distinction between state and computed was unhelpful, and I thought the methods were all over the place. I remarked that the subjects our UIs handle generally have a completely stable structure, and this structure is a directed acyclic graph.
So I decided "I'm going to make a directed acyclic graph that hosts everything: your state, your UI oninput handlers, your data fetching. That way, your state lives with the methods that modify it, in nodes, and everything will be consistent all the time, because the graph will know which nodes to recalculate when any node changes. Then as a bonus, we'll be able to visualize the emergent structure of our apps, live, in a super devtools."
Tis a little disconcerting to see master called master. I thought we'd all changed that?
Basically everyone who utters the question “.. but how technical are they?” in that particular tone of voice is a shitbird.
Software is a new industry, we're only just starting to get it right, and put behind us a litany of failed projects and methodologies. Every decision in a software company has a technical aspect. I personally am absolutely over non-technical managers and the aberrant strategies and directions they set out on. In my jaundiced view, any software company not led by developers is just waiting to be blown out of the water.
But don't let that detract from an intelligent, heart-felt and thought-provoking article :-)
datagrip in pycharm seems to be on a similar trip. The SQL stays in string literals, but datagrip looks inside the string literal to validate and propose auto-completion.
The wikipedia page says exactly the opposite. "EOF abstracts the process of interacting with a relational database by mapping database rows to Java or Objective-C objects. This largely relieves developers from writing low-level SQL code." https://en.wikipedia.org/wiki/Enterprise_Objects_Framework
also zapatos, scala-slick (see type-checked sql statements) and yesql
This thread only underscores the total mindshare dominance of ORMs. The implicit alternative to ORMs in almost every comment is raw sql in string literals in app code.
For 6 years now, we've had tools that let you use sql as a language, then generate the wrapper exposing your query to your app as a method. (queryfirst, pgtyped, pugsql, sqlc) This is (or could be) a paradigm shift. It's clearly, demonstrably a superior way of working, but it exists on the fringes because ORMs (and this unchanging discussion) have sucked all the oxygen.
There were 488 Pedestrian deaths in France in 2022, (pop. 57 million, 3 times less likely)
There were 57 in holland (pop 17 million, 6 times less likely)
Is this a big knob you can buy?