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...
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
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.
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.
It'll take some time for those apps/tools to realize the full potential of statecharts, but it's a good start.
But at the same time, frontier models are very good at writing XState.
Yes, I stumbled upon statecharts checking out this Godot plugin: https://github.com/derkork/godot-statecharts
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.
What is a statechart?
A statechart can be explained in many ways, and we’ll get to those explanations, but essentially, a statechart is a drawing. Here’s a simple statechart:
However, this drawing isn’t very useful for software engineers who want to reap the benefits outlined elsewhere on this site, so let’s dive into some other ways of describing what a statechart is. The original paper that defines statecharts bills them as “A visual formalism for complex systems” (Harel, 1987). With that out of the way, let’s try to explain statecharts.
Put simply, a statechart is a beefed up state machine. The beefing up solves a lot of the problems that state machines have, especially state explosion that happens as state machines grow. One of the goals of this site is to help explain what statecharts are and how they are useful.
Statecharts offer a surprising array of benefits
It’s worth noting that you’re already coding state machines, except that they’re hidden in the code.
There are a few downsides to using statecharts that you should be aware of.
There are a few common arguments against statecharts in addition to the ones listed above:
The benefits outlined above should make it clear that the introduction of statecharts is generally a net positive.
First of all, know that a W3C committee spent 10+ years (2005 to 2015) standardizing something called SCXML (yes, Statechart XML), and that it defines a lot of the semantics and specifies how to deal with certain edge cases. There are tools to read, author and even execute statecharts written in SCXML, in various languages. There are also some derivatives that support the same model as SCXML, but using a different syntax.
Additionally, there are statechart libaries for a variety of platforms, that in varying degrees support the semantics described by SCXML. You should consider using these libraries just to get those edge cases taken care of. The libraries generally perform entry and exit actions in the right order and so on.
With that out of the way, read on!
In addition to just using statecharts to model the behaviour in documents separate from the actual running code, it’s possible to use one of various machine formats, both to design the behaviour, and at run-time to actually be the behaviour. The idea is to have a single source of truth that describes the behaviour of a component, and that this single source drives both the actual run-time code, but that it can also be used to generate a precise diagram that visualises the statechart.
This carries along some different pros and cons:
In essence, if you have any definition of a statechart in your code, all you need to do is to take that representation and automate the generation of the visual statechart. This is of course simpler when the definition is in a separate file, e.g. in a JSON or XML file.
This is all explained on the page on how to use statecharts!
If you feel like chatting to someone about statecharts, you can go to gitter.im (no login required to see the chat), where you’ll find a community of like minded developers that can help you understand and reap the benefits of using Statecharts. For a more Q&A-type site, head on over to the statecharts GitHub discussions, where we’ll do your best to answer your question.
Quite a few people have written books or held presentations that deal with statecharts in various ways, and they’re included in our resources page. If you’ve written something, please share it by posting it to GitHub Discussions.
There are some pages that haven’t found any place in the web of documents, so they’re honourably mentioned here: