The transitions between states in the Svelte example are also completely uncontrolled and there is no guaranteed flow from state A => B => C. That is completely fine in many cases, most cases I would say. The problem is when you encounter a scenario where predetermined flow and guaranteed state transitions matter and you're trying to cobble it together. Robot and XState aren't React libraries, they're just Javascript libraries. Not every solution needs them but to dismiss the idea as overengineering or React specific because you can assign to variables in Svelte is missing the point.
Sure; but you can handle that as we do in other programs: if it makes sense to do so, make a single method responsible for modifying a state variable and call that instead of assigning directly. And that can manage side effects. Alternately, trigger other changes off the state variable changing using svelte’s reactive code blocks. This style of programming can scale up and down in complexity like any other code you write, and you can scope it and refactor it along with everything else.
What is your argument here? That we already work with state machines implicitly in UI code so there's no point in making it explicit with a library? That Svelte's reactive mechanics are so good that it doesn't make sense to use an external library even if it is specialized for modelling things as a state machine?
Because I agree with you that Svelte is great and reactive programming is powerful but if you had a problem that looked and acted like a state machine, why you wouldn't just use a state machine? And if someone had a library ready to go that managed it for you, so much the better.
