A few times I've seen someone on HN bring up the idea of using statecharts for UI implementation. Many years ago there was a book around this idea, but I wasn't able to get a copy before it became very rare.

"Constructing the User Interface with Statecharts" https://www.amazon.com/Constructing-User-Interface-Statechar...

I've always wondered if statcharts were a powerful enough abstraction to handle everything I needed, and would like to read more about its specific application to implementing UIs. Does anyone have any other references, books, etc?

Thanks, ordered it. For those having trouble searching like I did, it appears the correct title is Constructing not Designing.

https://www.amazon.com/Constructing-User-Interface-Statechar...

Cool, I wasn't aware of that book but I'll look into it!

Other resources folks might want to check out are:

+ David Harel's original paper on the statecharts formalism (which Sketch.systems implements): http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...

+ Ian Horrock's "Constructing the User Interface with Statecharts" book: https://amzn.to/2sT1e4x

It's also worth noting that Sketch.systems doesn't do any kind of formal analysis or checking of invariants. If you're interested in that sort of thing, look into TLA+ (video intro: https://lamport.azurewebsites.net/video/videos.html) or Alloy (http://alloytools.org/).

I think the big misconception here is that statecharts _have_ to be framework-y. They don't, and their biggest benefit (in my opinion) is how they shift the mental model of creating UIs from "bottom-up" to "top-down", so that even if you're not explicitly using finite state machines or statecharts, your UI benefits from better maintainability.

Here's the thing. As developers, we write implicit state machines in our UIs all the time, in the form of boolean flags, or enums if we're feeling disciplined, or peppered if-else statements everywhere. Arguably, most (if not all) UIs can be represented as explicitly classifiable states, and actions that can occur that can transition those states into other states.

So I'd argue that having _some_ sort of declarative formalism for describing your app's states and transitions is much more beneficial than having an ad-hoc way of imperatively changing states, which most of us developers are wont to do, since it's "easier" to implement.

Since statecharts are hierarchical graphs, there's also the possibility for automatically analyzing, optimizing, and generating full integration tests for user flows given a statechart spec.

I agree that trying to use statecharts everywhere is fitting a round peg into a square hole, but thinking about the UI in terms of states, and actions in terms of something that is simply emitted instead of something where application logic is stuffed into, will greatly improve how UIs are developed in the future.

Relevant must-read: https://www.amazon.com/Constructing-User-Interface-Statechar...