News for hackers. Stuff that matters.
Re:Hyperapp – A tiny framework for building web interfaces by jorgebucaran on Wednesday July 01, 2020 @03:07PM (#23705192)
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

Re:Hyperapp – A tiny framework for building web interfaces by RyanGoosling on Wednesday July 01, 2020 @03:56PM (#23705798)
> can't use traditional DOM events

Wtf are you doing man?

Re:Hyperapp – A tiny framework for building web interfaces by jorgebucaran on Wednesday July 01, 2020 @04:04PM (#23705893)
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.