# Goals

# API Goals

  • Adherence to the W3C SCXML Specification and David Harel's original statecharts formalism
  • Promote an Actor model event-based architecture
  • Compatibility with all frameworks and platforms
  • Ability to completely serialize machine definitions to JSON (and SCXML)
  • Pure, functional Machine(...) API
  • Zero dependencies

# Choosing XState

If you're deciding if you should use XState, John Yanarella summed up his reasons really well (links and emphasis mine):

When I was making that same choice as to whether to use and advocate for the use of XState where I work, the things that stood out for me were:

  1. The committment to understanding the relevant prior art and informing the implementation based on existing research papers (Harel's original paper on statecharts), books (Horrocks' "Constructing the User Interface with Statecharts"), and standards (W3C's SCXML).

Many of the other libraries I reviewed along the way are projects that stop at the point of implementing simple finite state machines. (If that's all you need - and it might be - David's been quick to point out how few lines it takes to just roll your own.) Their reach is shortened, since they don't address the subsequent limitations that can be overcome via a statechart.

XState stands on the shoulders of giants by embracing W3C's SCXML spec - it gets the benefit of that working group's research into edge cases.

  1. It's a refuge from the "shiny object syndrome" of embracing the latest flavor-of-the-month "state management library". It faithfully implements a 30+ year old formalism. You end up putting your most important logic into something you can take with you to any UI framework (and potentially to other statechart implementions in other languages). It's a zero-dependency library.

The front-end development world is the wild west, and it could stand to learn from what other engineering disciplines have known and employed for years.

  1. It has passed a critical threshold of maturity as of version 4, particularly given the introduction of the visualizer. And that's just the tip of the iceberg of where it could go next, as it (and its community) introduces tooling that takes advantage of how a statechart can be visualized, analyzed, and tested.

  2. The community that is growing around it and the awareness it is bringing to finite state machines and statecharts. If you read back through this gitter history, there's a wealth of links to research papers, other FSM and Statechart implementations, etc. that have been collected by Erik Mogensen over at statecharts.github.io.