Hyperapp only makes sense if you want to write immutable, purely functional SPAs in JavaScript. There's no Web API or native abstraction for that. And if your site was only content, then I'd say why even bother with JavaScript.
Okay, so there's no Web API or native abstraction for what? Immutability? There is, but it's somewhat semantically obtuse to express natively with Object freezing, not even to mention some other variably-efficient jiggery-pokery with proxies or something (or maybe there's a new language feature for this that I've forgotten about, so many after all, or was it a proposal?). Purely functional single-page application: oof, such a mouth-full. Can mean so many things too. So this entire new abstraction is for a front-loaded SPA?
Maybe the Web should be reinvented, slightly at least. Maybe it would be a good thing if Web Assembly in conjunction with HTTP3 or something akin to it ate the whole beast, ecmascript and all.
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.
Can't use DOM events to create side effects. What we do is define UI interactions as state transitions. Transitions allow you to say [nextState, myEffect] to update the state and create a "controlled" effect (just an object representation of a side effect, very much like how VDOM uses objects to represent DOM nodes). Effects in Hyperapp are the same as Elm commands.
