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].
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".
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.
I plan on greatly simplifying it for the next major version, mostly to be more idiomatic and flexible without sacrificing the state machine principles.