I'm not exactly very well acquainted with the theoretical underpinnings of Computer Science (except where they intersect with other fields that are more my specialty like Operations Research and Economics), but Finite State Machines have always struck me as incredibly intuitive modeling structures for thousands of real life phenomenon. And I'm continuously surprised that professional SDEs with academic training in CS are so reluctant to use them to model their domains. I realize that avoiding state has its benefits in a lot of areas of software design, but the world is stateful and if you are avoiding state just to make your job easier, you are doing it wrong.
One area that absolutely baffles me is UI Framework design. Every single UI in the world can be modeled as an FSM because they are FSMs. And yet, when you go to any common framework for UI design, you are forced to use concepts that only tangentially touch the idea of modeling a UI as an FSM. And while the new breed of Reactive Functional Programming approaches have incredibly useful concepts (like reducers and signals), they still require incredibly imperative approaches to state transitions.
And unfortunately the worst part of web design is the language. Javascript is terrible for modeling FSMs: recursion is an afterthought, state can be so shapeless and dynamic to the point where you need to query your state to be able to identify where you are in it, and listening to events is a chore of epic proportions. The closest that I've found to actual FSM design on the web has been React.js, and even then it only seems like they accidentally stumbled onto the idea of using FSMs to model UIs. The state of the art in modeling state in React (Redux) eschews component local state religiously, forcing you towards modeling every possible DOM event through a gigantic global structure. It ends up being a gigantic pain in the ass.
I really wish I could find a cross platform UI framework with a true FSM approach to modeling UIs. It doesn't need to be complicated: All you need is a component model and you program a component by describing each component's state transition table (state0 * event=> action * state1), and the mapping of the state to its immutable and pure renderer. There literally is nothing more to it than that. Some day I'm just gonna lose my shit enough to compel me to write my own framework and model it correctly. Until then, I'm gonna bitch about it on the internet.
Yes, I've encountered many instances of developers reinventing FSMs poorly because they never studied them,
over the course of my career. I try to counter that by giving a short presentation on them at each place I work.
Your FSM UI sounds interesting. It would be a lot of work to accomplish fully, but perhaps instead a blog post on what it would/should look like would be enough to get people interested in the idea.
I'm pretty sure that ember had an internal object called Ember.State at one point and another called Ember.StateManager to (naturally) manage the relationships between states. This was a few years back so I can't say what's happened internally since then, but as far as I remember the router was intended to basically encapsulate the logic of an FSM.
Yep, you are right. There was Ember.State and Ember.StateManager, but it was extracted from the final v1.0.0. Instead of having one universal State Manager, router, views, etc got they own.
After spending 15 minutes in the source code, it is ready to use... for example, it is brilliant to manage states in a component tree, where the original router would overkill.
Please correct me if I'm wrong, but I think the approach of your final paragraph could be very straightforward to implement in Elm (a purely functional language that also has one of the best implementations of FRP that you can find anywhere, in any language). See this article on "the Elm architecture", which I think could be very naturally extended in the way you propose:
Elm's approach involves having completely declarative, purely functional UI code (with efficient update computations resolved via a virtual DOM in the background), where individual components are highly composable and referentially transparent.
In terms of just web programming, Elm is amazingly close to my dream. I have some beefs with the language (Ports are unintuitive, generics higher kinded polymorphism are non-existent, haskell syntax), but they are pretty small beans. The big part that I find missing is the cross platform abilities (I'm talking web, mobile, and desktop platforms without the slow/hacky do-everything-in-html5 methods).
And to be honest, if I were to start from scratch, I'd probably be re-implementing 90% of Elm anyway. Which maybe says to me that instead of starting from scratch, I should just join the Elm community and start hacking on the compiler backends (for compiling to platform-native code) and front end libraries (to target native UI framework code), and hope the language grows closer to what I would like.
The states exist whether you model them or not, but yes using one FSM for entire UI would potentially grow too large and cumbersome to be practical. They do, however, make more sense targeted at particular levels of abstraction: system, component, etc.
One area that absolutely baffles me is UI Framework design. Every single UI in the world can be modeled as an FSM because they are FSMs. And yet, when you go to any common framework for UI design, you are forced to use concepts that only tangentially touch the idea of modeling a UI as an FSM. And while the new breed of Reactive Functional Programming approaches have incredibly useful concepts (like reducers and signals), they still require incredibly imperative approaches to state transitions.
And unfortunately the worst part of web design is the language. Javascript is terrible for modeling FSMs: recursion is an afterthought, state can be so shapeless and dynamic to the point where you need to query your state to be able to identify where you are in it, and listening to events is a chore of epic proportions. The closest that I've found to actual FSM design on the web has been React.js, and even then it only seems like they accidentally stumbled onto the idea of using FSMs to model UIs. The state of the art in modeling state in React (Redux) eschews component local state religiously, forcing you towards modeling every possible DOM event through a gigantic global structure. It ends up being a gigantic pain in the ass.
I really wish I could find a cross platform UI framework with a true FSM approach to modeling UIs. It doesn't need to be complicated: All you need is a component model and you program a component by describing each component's state transition table (state0 * event=> action * state1), and the mapping of the state to its immutable and pure renderer. There literally is nothing more to it than that. Some day I'm just gonna lose my shit enough to compel me to write my own framework and model it correctly. Until then, I'm gonna bitch about it on the internet.