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 model everything with them. They're most useful when you have behavior where the answer to "what happens next?" depends on both the current state & the event. A statechart can act as an oracle for questions like: "Given I'm in this state, when this event happens, what is the next state, and what effects should run?"
I'm close to releasing an alpha of the next major version of XState, focused on better ergonomics, type safety, and composability, as well as a new visualizer/editor.
2 hours and not a single comment yet?! At one point, Statecharts seemed to be getting traction in the frontend/UI ecosystem, albeit tiny traction. Leveraging state machines (and particular Statecharts, which is basically compositions of state machines) for UI interactions makes complex flows so much easier to reason about! However, seems the traction eventually disappeared for unknown reasons, sadly.
If this is the first time you're hearing about Statecharts, I highly recommend the book "Constructing the user interface with statecharts" by Ian Horrucks (https://archive.org/details/isbn_9780201342789/mode/2up) which yes, is from 1999, but probably the best introduction for how to actually apply and use Statecharts.
Statecharts are still getting some traction! XState has over 4 million weekly npm downloads. Animation tools like Rive & LottieFiles heavily advertise state machine capabilities. AI tools like LangGraph are built on state machine foundations.
It'll take some time for those apps/tools to realize the full potential of statecharts, but it's a good start.
I've been wanting to code up an AI flavor wrapper around state machines that will be visible as an AI generated image in PRs.
I often have my AI code output one just to make sure my logic feels more sound. Along with mermaid charts if I need to toy around or drop into stately for more power.
I've always been a fan of state machines and have hoped for their adoption to grow.
Having visual understanding of state is becoming increasingly important for AI generated code you don't nearly understand as well as the human variety.
It seems many still favor store based reactivity state in frontend frameworks.
I contribute to it being the default so why change and because libraries like xstate are far more difficult to learn the syntax and are more verbose. But with AI that's hardly an issue, so I wonder if there is more to it I don't see and we just haven't seen the state chart reach it's peak yet.
The next version of XState will be much more ergonomic, with a reduced API surface area, lower learning curve, and much easier for devs (and agents) to author.
But at the same time, frontier models are very good at writing XState.
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.
"No statechart will survive contact with real world applications".
I mean, when you have external dependencies, multilayer protocols, multithreading, perf requirements, the state will becomes an ugly mess. One can only dream of a clean statechart.
Hierarchical state machines are common in hardware development. I've also used them for embedded systems, and dug my way out of spaghetti nightmares in distributed systems by reworking a system into a set of state machines.
Is it clean? Not always, it gets messy. On the other hand it is deterministic and traceable to specifications. Specifications as state machines can be easier understood and shared than raw code or raw prose.
I also think more effort is needed to synthesize a clean set of state machines with hierarchy for a system at scale and I'm sure there are times when that effort is not warranted.
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 model everything with them. They're most useful when you have behavior where the answer to "what happens next?" depends on both the current state & the event. A statechart can act as an oracle for questions like: "Given I'm in this state, when this event happens, what is the next state, and what effects should run?"
I'm close to releasing an alpha of the next major version of XState, focused on better ergonomics, type safety, and composability, as well as a new visualizer/editor.
There's also an open-source basic statechart visualizer here: https://sketch.stately.ai
For the formal/spec side, SCXML is worth reading: https://www.w3.org/TR/scxml
Also worth reading the original paper by David Harel: https://www.weizmann.ac.il/math/harel/sites/math.harel/files...
2 hours and not a single comment yet?! At one point, Statecharts seemed to be getting traction in the frontend/UI ecosystem, albeit tiny traction. Leveraging state machines (and particular Statecharts, which is basically compositions of state machines) for UI interactions makes complex flows so much easier to reason about! However, seems the traction eventually disappeared for unknown reasons, sadly.
If this is the first time you're hearing about Statecharts, I highly recommend the book "Constructing the user interface with statecharts" by Ian Horrucks (https://archive.org/details/isbn_9780201342789/mode/2up) which yes, is from 1999, but probably the best introduction for how to actually apply and use Statecharts.
Statecharts are still getting some traction! XState has over 4 million weekly npm downloads. Animation tools like Rive & LottieFiles heavily advertise state machine capabilities. AI tools like LangGraph are built on state machine foundations.
It'll take some time for those apps/tools to realize the full potential of statecharts, but it's a good start.
> Statecharts seemed to be getting traction in the frontend/UI ecosystem
Yes, I stumbled upon statecharts checking out this Godot plugin: https://github.com/derkork/godot-statecharts
I've been wanting to code up an AI flavor wrapper around state machines that will be visible as an AI generated image in PRs.
I often have my AI code output one just to make sure my logic feels more sound. Along with mermaid charts if I need to toy around or drop into stately for more power.
The title contains hierarchical, which does not come back in the post. You probably need hierarchy, otherwise state charts become unweildingly large.
I've always been a fan of state machines and have hoped for their adoption to grow.
Having visual understanding of state is becoming increasingly important for AI generated code you don't nearly understand as well as the human variety.
It seems many still favor store based reactivity state in frontend frameworks.
I contribute to it being the default so why change and because libraries like xstate are far more difficult to learn the syntax and are more verbose. But with AI that's hardly an issue, so I wonder if there is more to it I don't see and we just haven't seen the state chart reach it's peak yet.
The next version of XState will be much more ergonomic, with a reduced API surface area, lower learning curve, and much easier for devs (and agents) to author.
But at the same time, frontier models are very good at writing XState.
One of my favorite data structures
Created StateKit for ObjC/Swift some time ago, it’s been production tested in some very large apps: https://github.com/sghiassy/StateKit
Such a cool data structure
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.
Hierarchical state charts have been formalized in as a type of UML diagram. Details:
https://en.wikipedia.org/wiki/UML_state_machine
"No statechart will survive contact with real world applications". I mean, when you have external dependencies, multilayer protocols, multithreading, perf requirements, the state will becomes an ugly mess. One can only dream of a clean statechart.
Hierarchical state machines are common in hardware development. I've also used them for embedded systems, and dug my way out of spaghetti nightmares in distributed systems by reworking a system into a set of state machines.
Is it clean? Not always, it gets messy. On the other hand it is deterministic and traceable to specifications. Specifications as state machines can be easier understood and shared than raw code or raw prose.
I also think more effort is needed to synthesize a clean set of state machines with hierarchy for a system at scale and I'm sure there are times when that effort is not warranted.