Skip to content

XState comparison

Cassio Zen edited this page Jun 5, 2021 · 4 revisions

I’m a huge XState fan and this library obviously took a lot of inspiration from it. XState is the golden standard for state machines in JavaScript, but this library has a more niche use case:

  • It's React specific: it follow react idiomatic patterns (like naming the transition "effect" and following the same useEffect cleanup pattern). Being React-specific also means it can use React’s built-in hooks, useReducer and useEffect do most of the heavy lifting, and as a good consequence this lib is small.

  • It contains only subset of features from XState: I only added to this library functionality that I used over an over again in state machines.

  • It is a little less strict: You can call send from effects, effects can be inlined in the state machine config. I think this makes it more "practical" for daily use at the cost of strict correctness.

Finally, it has a heavy focus on type inference - it's nice when a library can provide autocompletion and type checking without requiring you to manually provide typing definitions.

And how does it compare to @xstate/fsm?

The gist is:

  • Right now both libs are similar in feature set. I’d say XState/fsm is more mature.
  • They're both small, so if size is your main consideration you can't go wrong with any.
  • Pros: This is more react idiomatic, and has great TypeScript support with automatic type inference.
Clone this wiki locally