No, I know what state machines are. What I’m contesting is the argument that this is an intuitive way to structure code. It could be intuitive to reason about, or even white board the states your application can be in, but this doesn’t look like concise and elegant code.

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.

I think your problem is that many things don’t have to be a state machine. And you’re right. It’s simply not a good idea to create a confirmation dialog like that.

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.

I actually believe there would be fewer UI bugs if more UI was modeled as a state machine. After all, all diagrams and design is often based on "when X is shown and Y is pressed, we go to Z". But in code that's expressed in a way that makes it possible to have a mismatch between multiple half baked states.

Nobody's forcing you to use this library. Please take your negativity elsewhere.

EDIT: Okay, didn't mean to interpret criticism as negativity; I apologize.

Criticism is not negativity. It's valuable when someone in the room challenges ideas and pushes back over-abstraction (if done respectfully and constructively).

Can you even describe the use of a state machine for UIs as "over-abstraction"? To me it seems more like an "under-abstraction", since one usually compiles a more abstract definition into a state machine - often a regular expression or some kind of grammar.

Was just discussing this with a friend this morning. It might be better to describe it in terms of trade-offs versus the overuse of the ‘over-abstraction’ allegation.

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.

Did you start programming with OOP or Functional programming? Did learning how to programming in the other form seem difficult to understand why you would do things that way, or seem obtuse vs just using the ways you already know?

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.

How are state machines "a very different way of looking at code"? It's basically assembly with jumps as state transitions. A decent programmer already understands this from assembly lessons (and avoids doing it by hand, leaving it to the compiler).

Fair enough, but the echo chamber is why stuff like this gains prominence. I’m abrasive for sure, but I need to see some push back on these ideas in all of these threads.

> It seems like you're just unfamiliar with state machines.

You're saying that he doesn't know computers? Computers are state machines. Presumably he used one to post his comment.