[DonHopkins]

Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state.

If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refer to a user interface as a finite state machine is like referring to a car as a pulley, just because the engine requires several pulleys to work, and ignoring all the rest of the engine and car. You can't make a car out of just pulleys, and you can't make a user interface out of just finite state machines.

[saosebastiao]

React, as it is presented to the programmer and for all practical reasoning, is programming with finite state machines. Sure, javascript is Turing complete and capable of much more (behind the scenes in React there is plenty going on that does not qualify as FSMs), and within a react application or even a component you might use Turing complete semantics to describe actions, data structures, effects, or whatever...but constrained to the API and idioms of react it is perfectly acceptable to call it FSM programming. In fact, Facebook already says this about react, that UIs are state machines and react is a way to declaratively describe them that way.

A better analogy for the equivalence of Finite State Machines and User Interfaces is the equivalence of human arms and levers. Just because it is one doesn't mean it isn't the other. One is abstract and the other is concrete, but there is still an equivalence. And not just computer user interfaces either...you could take pretty much any real world user interface: analog, mechanical, digital, whatever. Hell, tubas and vending machines are finite state machines. They fit the definition of a finite state machine because they are.