Built-in support for HOA: Should it stay or should it go? 🎶

Should we keep built-in support for HOAs (higher order apps) or shall we encourage you to roll your own DIY solution? For example using a right to left function reducer like compose or good old f(g(..)).

The tradeoff is more flexibility & less bytes for one less selling point.

---

Some facts about HOAs:

• 99% users will never need to author a HOA.
• You don’t even need to use a HOA, but some of you may want to in order to facilitate debugging.
• HOAs are ought to be used primarily for adding debugging functionality to your apps, enable logging of actions / state updates, add Developer Console support (devtools), TimeTravel, HMR, bypass the VDOM to target a different renderer, e.g., a terminal. Other valid uses, but not strongly encouraged include augmenting Hyperapp “core features”, e.g., introducing new app props to enable pre-wired component views, etc.
• HOA is not a unique Hyperapp cooncept. You can create a higher order function of any function in the universe. Hyperapp does go out of its way to make slightly more convenient for you if you want to author a HOA, but we are not bending the laws of physics or being too unique.
• You can do and abuse HOAs as much as you want with this feature built-in or not (in case we decide to remove it).

/cc @pspeter3 @okwolf @zaceno

[jorgebucaran]

Now with init and modules landed in core and with the recent realization that the built-in support for authoring a HOA is not particularly that helpful, I propose we remove this from core and encourage users to DIY! 🔥

[Mytrill]

Ah ok, got it, thanks! I’m all for removing the support then!