61–70 of 91 posts
Glad to see statecharts still getting attention! I created XState, a JS/TS library for authoring, executing, and visualizing state machines/statecharts: https://github.com/statelyai/xstate I've been working on it for 10+ years. The main thing I've learned is that statecharts are most valuable when they're treated as executable behavior, not just documentation. That doesn't mean you need to use them everywhere or mode…
Glad to see statecharts still getting attention! I created XState, a JS/TS library for authoring, executing, and visualizing state machines/statecharts: https://github.com/statelyai/xstate I've been working on it for 10+ years. The main thing I've learned is that statecharts are most valuable when they're treated as executable behavior, not just documentation. That doesn't mean you need to use them everywhere or mode…
This was a talk I gave at Laracon that was my stab at distilling my thinking about State Machines, State Charts etc.
What's better than graphically designing your HSM, simulating it vs all kinds of scenarios to verify it, and auto generating the code?
I wonder if it's possible to combine statecharts with durable execution engines like Temporal, DBOS, Restate, etc. At work we use Cloudflare Workflows for managing onboarding and payment workflows. It generates flowchart diagram that is useful for quickly reasoning about what the workflow does, which I guess is what statecharts is trying to achieve.
When you say "it generates flowchart diagrams…" what exactly is generating them? Is it built into cloudflare workers or is it something your team created?
One thing usually skipped in primers: history pseudo-states (H, H ) make a statechart formally non-deterministic from outside. The pitch is "current state is a pure function of inputs" — history breaks that. Entering a parent via `H` puts you in whichever child was active last, so the same event from the same outer state can land you in two different inner states. That latent "last-active child" IS state, just state…
"inputs" can refer to just current and future inputs --- or it refers to the totality of inputs, including the inputs leading up to "here".
in the latter interpretation the machine is perfectly deterministic. and the "deep history" pointer simply is part of the state machine.
One thing usually skipped in primers: history pseudo-states (H, H ) make a statechart formally non-deterministic from outside. The pitch is "current state is a pure function of inputs" — history breaks that. Entering a parent via `H` puts you in whichever child was active last, so the same event from the same outer state can land you in two different inner states. That latent "last-active child" IS state, just state…
I’m essentially thinking of H’ as a write-ahead-log prefixing any node
i gave it some time, but that's not a good site. it takes forever to explain simple things and never gets to any important and novel idea. i gave up when it turned out that it's just a tree of state machines - for some reason called a 'chart' despite not apparently having any chart-like property.
ugh. it's just a doodling exercise for architecture astronauts. OMG it actually, unironically references UML and has Statechart XML!
flipping the bit on this one
Earlier quoted context omitted.
Perhaps, but I object to the "machine" phrasing. Ordinary finite state "machines" (without hierarchy) aren't machines either, they are just diagrams of something that could be a machine or something else.
They're diagrams of something that does something , otherwise it's just a rectangle. And once it does something , isn't that kind of an abstract machine anyways?
I wonder if it's possible to combine statecharts with durable execution engines like Temporal, DBOS, Restate, etc. At work we use Cloudflare Workflows for managing onboarding and payment workflows. It generates flowchart diagram that is useful for quickly reasoning about what the workflow does, which I guess is what statecharts is trying to achieve.
What I'm solving for is AI-generated diagrams are usually one-shot: Mermaid/SVG/PNG gets emitted, but there’s no durable diagram state to update, validate, diff, or reuse.
Zindex makes the diagram itself structured state. Agents use a Diagram Scene Protocol (DSP) to patch nodes, edges, groups, relationships, constraints, and revisions; Zindex handles validation, layout, rendering, versioning, and storage.
So for Temporal/DBOS/Restate/Cloudflare Workflows, I’d imagine Zindex sitting beside the durable execution engine: the engine remains the source of truth for execution, while Zindex maintains the persistent, inspectable visual model derived from code or execution history.