Hacker News new | ask | show | jobs
by davidkpiano 48 days ago
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...

9 comments

You were the reason I first discovered state machines!

This was a talk I gave at Laracon that was my stab at distilling my thinking about State Machines, State Charts etc.

https://www.youtube.com/watch?v=1A1xFtlDyzU

I loved this talk!
For the clojure folks there's https://github.com/fulcrologic/statecharts which a pretty sophisticated implementation that removes the XML requirement (particularly for executable content), yet remaining close to SCXML. XState even gets a reference in the prior art section.
And for those of us who want to avoid/are allergic to XML (& SCXML -_-), there is clj-statecharts too (https://lucywang000.github.io/clj-statecharts/docs/get-start...), I've always found it slightly more ergonomic and their codebase is a bit more intuitive and simpler than Fulcro's
I had used (and would gladly still use) XState, without even knowing about what "statecharts" even means.

I used it with lit.js to help with a drawer-like navigation component that reacts to page width and has many props and internal states. I can't even think how horrible it'd have been without XState. Thank you very much!

With all respect to xstate, if you don't need complex nested state machines, you should check out robot3.js. The automatic TS type inference makes it pretty handy for the spots where you want a bit of state machine logic.
There is also @xstate/store for simple event-driven stores and atoms; just as simple as Zustand + Jotai: https://stately.ai/docs/xstate-store
I’m a big fan of @xstate/store!
Xstate has helped me clean up some hairy situations in the past. Looking forward to the next version, and thanks for your great work!
XState is awesome, made a complex decentralized key sharing scheme a breeze.
XState is an awesome library! Stoked to hear there's a new major version and visualizer coming. :)
Since you’re in the know, do you have any opinion on Petri Nets?
I’m not the GP, but I think petri nets are awesome. At least they’re a great way to represent and visualize many systems. Statecharts I find tricky by comparison. For a simple example, imagine you’re making a game and the player has to talk to three people in any order before moving to the next stage. this is very easy to represent as a petri net. (you just need three places and have a token in each one represent having talked to the necessary person.) But I think it corresponds to 8 separate states in an FSM (or statechart? not sure). Which just seems overly complex for a simple situation like this
> But I think it corresponds to 8 separate states in an FSM (or statechart? not sure)

In a conventional FSM yes but not a statechart. Statecharts support parallel regions within a single state. You’d have 3 regions for your example: one waiting for each person. There would be 4 states total: one to wait on each person, each in its own region, plus the superstate. The superstate would exit when all 3 “waiting for person <x>” sub states exited, independent of their sequence.

I’m with you on Petri nets though, very helpful for modelling concurrent behaviour.

Thanks to the both of you. I have always just stuck to plain old Control Flow Diagrams, which can be quite tricky to get all the nuances of a FSM. Always been interested to commit to using Statecharts or PetriNets, but I think the usefulness of concurrency tips it over the edge… To Amazon I go
nice thanks. been looking for a rust equivalent
This would be the closest: https://github.com/GnomesOfZurich/scxml/