Statecharts: Some Critical Observations (2004) [pdf]

I agree with some of the criticisms even though I'm not 100% familiar with all variation of the statechart semantics. I use xstate and it works pretty well for all my use cases.

One important thing to note is that statecharts is just a specific runtime. So it compiles down to code - that code just runs the same way you'd expect any other code to run. Main differences is that it's mainly event-driven and that you execute functions only in response to the statecharts changes - but at the end of the day you're still just executing functions.

A very simple example is:

doorOpened -> ringBell()

ringBell() is only called when the door is opened.

What statecharts adds is simply an extra level of indirection where instead of being event -> action(), it's event -> state -> action(). Meaning that the state is always checked before executing a function:

doorOpened -> opened -> ringBell()

This is crucial because emitting doorOpened again may yield different results based on the state of the chart! Let's emit it again:

doorOpened -> closed -> keepDoorOpen()

This extra level of "check" before executing functions may seem trivial but opens the doors to designing quite complex event-driven reactive behavior using a drawing! Quite powerful stuff.

All kinds of logic is hierarchical. Some use cases are mutually exclusive, which translates to them being nested under different states.