davidkpiano

Author here; still in alpha!

Pretty cool. Looks like stately.ai but catered towards agentic state machine workflows. Really interesting!

This would be the closest: https://github.com/GnomesOfZurich/scxml/

I loved this talk!

P lang is close: https://github.com/p-org/P

There is also @xstate/store for simple event-driven stores and atoms; just as simple as Zustand + Jotai: https://stately.ai/docs/xstate-store

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.

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...

Really appreciate you using XState!

Really cool! Love the XState-inspired API ;-)

Re: atoms + learning curve, this is why XState Store exists, which supports both XState-style state updates and atoms: https://stately.ai/docs/xstate-store

I also like the approach of Svelte, and realize that sometimes a full state machine isn't needed. I don't think that atoms should be used everywhere, since updating state freely without guardrails just leads to disaster long-term.

Thank you for the kind words! I somewhat agree that it is complicated and overly engineered for many applications that don't need all of the statechart features, and that it has a sizable learning curve.

I plan on greatly simplifying it for the next major version, mostly to be more idiomatic and flexible without sacrificing the state machine principles.

I remember this! It was one of my inspirations for creating a hierarchical state machine editor [0] and a state machine library with a visualization layer [1].

[0] https://state.new [1] https://github.com/statelyai/xstate

Hey thanks for linking, I'm still working on this and hope to have a beta release soon!

Stately Agent is a completely open-source library for creating (LLM) agents that adhere to state machines.

How does this compare to the state machine editor on https://state.new ?

There are a lot of resources on finite state machines, especially in TypeScript, here: https://stately.ai/docs/state-machines-and-statecharts

(Creator here) Thank you for the mention!

Oh hey it's me!

You don't need to define every possible state. A state machine can serve as a higher-level structure of some of the states (statuses, modes) of parts of your app, for ease of structuring logic. But you can also create a single-state state machine and represent non-finite data as "external state".

XState creator here!

I love that use-case. We have plenty of developers & companies using XState on the backend, and one of our main goals for XState v5 was to enable more backend use-cases, with custom & composable actor logic, deep persistence, inspection APIs, and actor-first statechart features for modeling more complex actor-actor interaction.

Ultimately, we'd love to be an open-source alternative to AWS Step Functions.

This looks awesome!

Thanks for sharing! There's an updated viz at https://stately.ai/viz but that will soon be fully part of the studio at https://state.new (which can export to Mermaid now and PlantUML soon!)

Congrats on the launch, this looks really interesting!

Would love to know more about an example "simple embedding use-case" that you may have in mind.

We're not trying to force state machines as the solution for any state-related problem; they're not a panacea, but instead a useful tool for the appropriate use-cases.

And we're definitely making a huge effort to improve the types.

Yes! Visualizing how different actors communicate with each other in general is a big goal for us this year. We're going to start with sequence diagrams.

Hey, creator of XState here!

Just want to mention that we're very close to releasing XState v5 beta, which brings even more features to the state machines & statecharts you can create, and greatly improves the developer experience, but also makes it more usable as a general-purpose state management library (or orchestration "framework" if you want to consider it that), whether on the frontend or backend.

Hey, XState creator here. What did you not like about XState? Hopefully there are areas we can improve on or questions we can answer. Or maybe it wasn't appropriate for the project?

Creator of XState here - I agree. State machines and statecharts should be used to model parts of your application that need it, and they can potentially communicate with each other. Fitting the entire app in a single state machine is just like fitting all of the app logic in a single function; it's going to be incomprehensible.

Yep, the "stateless" part of the state machine is its transition function.