It seems like you're just unfamiliar with state machines. They're not a "new, weird abstraction", they're a core concept of computer science in general, and it can be argued that most code we write is itself an abstraction on top of state machines; not the other way around.
For more information on state machines and statecharts, I recommend reading this great resource: https://statecharts.dev/
From your examples: https://xstate-catalogue.com/machines/confirmation-dialog
I’ve written a million confirm-dialogs in my lifetime, and that example is one of the most convoluted things I’ve ever seen.
Guys, just because it’s in Computer Science, doesn’t automatically mean it’s a more sophisticated solution. The term for this is over-kill.
EDIT: Okay, didn't mean to interpret criticism as negativity; I apologize.
So, in a lot of cases in the UI, we are turning what is very recognizable and traditionally understood code into a new form to fit the state-machine world view in a more 1:1 way.
Again, it’s a trade off. What did we gain from this transformation? I don’t think we get enough back from this trade to structure our code in this new way.
Or to be clear, why would I trade my ability to read a few simple fetch calls that update a simple DOM element for this version? What is the outsized return here?
Just my 2 crypto.
I think using state machines is just a very different way of looking at code, and it does take some mind bending to think that way; but once you do, it's much easier to blend the code together the same way you'll see imperative and functional code blended together these days and not think twice about it.
However, some things just _are_ state machines. You don’t usually see them in the GUI (except for example wizards), but many parsers can trivially be implemented with state machines.
You're saying that he doesn't know computers? Computers are state machines. Presumably he used one to post his comment.