Hyperapp – A tiny framework for building web interfaces

There’s not many. I used it for several years on theoutline.com and it was great

> So...don't use CRA?

Sure, I can get by fine without that, but then I've got to educate 2 other members of my team, both who can program in numerous languages but are quite inexperienced with web development, how to correctly set up each project using the React/Redux/Sass/Typescript/Jest. I can do it myself and hand them a project template, but then no-one else will learn how to do it. The reason for CRAs existence is (more than any argument I might make) an implicit acknowledgement that setting up new webapps is a far more painful experience than it should be.

> it's kind of a surprise to see the claim that Webpack encourages its use.

It was React that recommended CRA, not Webpack recommending CRA, apologies for my misleading description.

> Or - a much easier tradeoff - just don't use Sass.

I'm already quite familiar with plenty of reasons to not use -or to use- SASS. The point is that as a tech choice it's hardly a minor player, and yet the experience of setting up / migrating a project using easily recognisable tech (React/Redux/Sass/TypeScript) is a long way from a straightforward. In my example, I already had SASS on existing related projects. My team members were already familiar with it. Create-React-App was at the time was also actually already built to include support for SASS - the problem IIRC was that the fork of CRA that added Typescript support was forked from a CRA version before SASS was supported, so (at the time) it was a "one or the other" situation before I forked it and fixed it myself.

> Keeping up with that kind of change, and knowing how to recognize and take advantage of the good, is one of the things it's an engineer's job to do.

It's also part of our jobs to look at processes and procedures identify areas of inefficiency, and to ask questions about what a better way of doing things would look like.

Finally, the trajectory of this discussion is pretty absurd. I'm offering examples of what happens in web development to illustrate that there is a massive difference between treating developer tools like Webpack / CRA as though they're similar to text-editors that you don't have to invest a bunch of time to understand and keep up to date with (a point that if I'm understanding you right, you likely agree with). My comment above's central claim is: that while critiques on size of dependency chain of developer tool like CRA or WebPack might be misguided, they are hardly lightweight cognitively, and the choice to use these tools (or not use them) isn't something to just take lightly because we clarified that our deployed artefacts didn't balloon in size.

When I'm not using JSX, I often do something like this

    const define = (componentDefinition) => (props, ...children) => isReactNode(props) ? React.createElement(componentDefinition, {}, props, ...children) : React.createElement(componentDefinition, props, ...children);
    const elements = new Proxy({}, {get: (target, tagName, _) => define(tagName)});
    // ...
    const {div, h1, button, input} = elements;

But although I really disliked JSX at first, once I tried it a little, I realised that it's about making the code describe what you want rather than how to get it. That mind set shift is actually valuable, even if underneath it's still turning into function calls.

While the backend (src directory) is certainly ferp, the frontend (unbundled js in public) is 100% Hyperapp.

I'm familiar with Elm but i think the model of Hyperapp is better than the [state command] pattern. This is how i see Hyperapp, the event part of Hyperapp is not about commands, it's about transition functions, functions that takes a before state and returns an after state. Hyperapp doesn't let the user to control the state by itself.

But there is worst, the problem with the pattern [state command] is that it doesn't work well with async method, because at the time the command is called, the state which is passed alongside the command and the state maintained by Hyperapp may be different.

With your example, the issue is that Decrement may be called on a previous state and not on the actual state.

The idea of the updater is to provide the function that takes the transition function as parameter, so delay will be written that way

  function delay(updater, timeout, fun) {
    window.setTimeout(() => updater(fun), timeout);
  }

If you want to decrement the state after a delay using the state at that time

  h("button", {
    onclick: (state, _, updater) => delay(updater, 100, Decrement),
    }, "subtract")

(from the Hyperapp perspective, the event listener return undefined so you don't have to update the state at the time the event listener is called)

and if you want to decrement the state using the state at the time the user click

  h("button", {
    onclick: (state, _, updater) => delay(updater, 100, _ => Decrement(state)),
    }, "subtract")

The other benefit is that because delay() takes an updater as first argument, it's clear that the function delay does a side effect. Conceptually, the idea is that instead of trying to hide the side effect, you make it clear to the developer (more like Haskell does).