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.
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 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.
At Stately, we want to make app and business logic accessible to the entire team and eliminate barriers between development, design, and product to make it easier to build and maintain complex applications quickly and robustly.
We enable development teams to collaborate effectively on even the most complex logic and flows with visual tools and insightful services. Helping them speak a common language so that the specifications, designs, and code are always synchronized, up-to-date, and visually clear.
We’re building a team inspired to work on this mission to make software development better for everyone and practice what we preach, both inside Stately and everywhere else.