📚 You don't need a library for state machines
State machines are awesome.
They're a really useful model for complex logic, workflows, processes, statuses, really anything that models state changes over time due to events, which happens to be most of your app logic.
They also happen to be one of the oldest models of computation, going back to at least the 1950s (when Mealy and Moore published their state machine concepts). In fact, computers and electronics really wouldn't exist without them; they're that fundamental.
State machines aren't new, and they also aren't special. In just about every modern programming language, you can use the built-in language control-flow structures, such as switch statements, to implement state machines.
So do you need a library for state machines?
No.
In fact, I would always encourage you to not even think about libraries, or even the code, at first. The best way to get started with state machines is by visualizing them, either with pencil and paper, marker and a whiteboard, or even an online drawing app like Excalidraw.
Then, you can use switch statements to switch on both the finite state and received event to determine what happens next (the behavior), or you can get a bit creative and use functions and/or objects to basically do the same thing.
So then why did I create XState? Because state machines aren't enough.
Like anything else in programming, state machines may look like the hammer that makes everything else look like a nail. Indeed, when programming your app logic, it's never really a question of "should I use state machines?" Rather, it's "I'm already using implicit state machines where I can't clearly understand the behavior; should I make them explicit?"
But state machines are also limited, and can even suffer from the state explosion problem. This is why statecharts were invented in 1987 by Prof. David Harel, to mitigate combinatorial state/transition explosions and add many other useful, practical features to state machines:
- Nested states
- Parallel states
- History states
- Entry/exit actions
- Guarded transitions
- Extended state
- Delayed transitions
- Activities
- Wildcard transitions
- And more!
Statecharts make state machines strictly better (after all, state machines are statecharts and statecharts can be decomposed to equivalent state machines). But they're also very difficult to implement. Trust me; I've been working on XState for the last few years, trying to faithfully adhere to the SCXML spec; it's no easy task!
So, do you need a library for statecharts?
Yes.
📖 I talk more about the ways you can implement state machines yourself, and the benefits/use-cases for statecharts in this post - give it a read!
The last few months have been extremely busy, both in the world and here in the world of state machines and statecharts.
🛠I have been working diligently on creating the next part of Statecharts.io, which will be a visual statechart creator and a repository where everyone can create, share, modify, and collaborate on statecharts. I hope to have a demo out soon, and as always, you'll be the first to know.
💬 We also have a new Stately Discord, where you can stay up to date with everything XState and Stately related, get quick help, and chat with others.
✨ I have also started shipping out exclusive XState stickers to GitHub sponsors. If you've sponsored me, I really, really appreciate it. Every single donation makes working mornings, nights and weekends on XState and current/future tooling worth it, and it pushes me to do even more to make it the best state orchestration/management tool possible. I use the funds to sponsor other maintainers in the community, and to fund projects that will benefit the community as a whole.
📈 XState also showed up in The State of JS survey for the first time this year! It showed 87% satisfaction and the most interest out of all the other comparable state management libraries. It's usage is still relatively low, so let's change that! (If you need a state machine library, that is.)
I'll be sending these newsletters to you less frequently, as you may have noticed, for one simple reason: frequent newsletters are annoying, and I value your time and attention. The next newsletter will likely be a demo of the statechart creator tool 🚀