Just saying "purely functional SPAs" was lazy, but it's usually enough to convey what makes Hyperapp different from other frameworks like React, etc. Let me try harder.

There's no native API for representing apps as finite-state-machines (Moore style) [1]. Admittedly, we could do a better job at explaining why you should care.

Hyperapp actions (Elm messages) correspond directly to FSM "events". Hyperapp effects (Elm commands) correspond directly to FSM "actions". The "single-global-state" corresponds to the fact that an FSM is always in just one of a number of "states".

Hyperapp is FSM architecture for JavaScript apps.

It is also bundled with a VDOM implementation optimized for immutability, e.g., you must derive your UI from the state, can't produce uncontrolled side effects, and can't use traditional DOM events, instead you think of every UI interaction as a state transition.

One more cool thing about Hyperapp is subscriptions. An abstraction to toggeable event streams: think bidirectional effects, e.g., global mouse/keyboard events, time, animation frames, geolocation.

[1]: https://en.wikipedia.org/wiki/Moore_machine