Hyperapp – A tiny framework for building web interfaces

No, it's niche with a French accent

It’s pronounced “NEE-chuh”.

Good content.

We are very close to the official V2 release, but right now that page is still a WIP.

The link works fine, though.

Ouch, yes, that's also a WIP, thank you for checking in, though.

Some problems are hard, common and already solved. Sometimes solving these problems yourself adds no unique value to your product. In that case, you should just use a well-reviewed external ecosystem package.

A large project will run into many of these problems. It is a waste to re-invent the wheel because a cool new framework has too few pre-made wheels.

Lack of libraries, as sibling says. Any libraries that exist are not generally well supported relative to similar libs for popular frameworks. Much smaller community, much less ease at finding others who may have had similar issues. Fewer eyes on, fewer bugs picked up. Fewer contributors, slower fixes/updates. Docs there are tend to atrophy faster.

Developed with Hyperapp on big prod apps about three years; was used to inject small amounts of interactive functionality into existing apps (.Net with jQuery powered frontends). Sorta worked, nice, simple idea, but docs almost nonexistent at the time (to be fair there's very little to it), was in process of being dumped for React just as I was leaving (to work on apps with Elm frontends, which Hyperapp takes a lot from, and suffers from similar issues, heh)

I interpret this as you need to do everything yourself rather than using off-the-shelf libraries.

Thank you. That's a marquee haha.

I do not have anything that is open as of now (but about to start a new project soon)

I would check out https://medium.com/hyperapp/a-walk-through-hyperapp-2-b1f642...

to get your toes wet though, good resource, also feel fee to join the hyperapp slack https://hyperappjs.herokuapp.com/ nice community and super helpful.

Yeah, I should have split things into a reply and a separate thread for the other stuff. That said, I didn't have any comment on the ecosystem - there's definitely a lack of userland things for Hyperapp, and that's for a number of reasons, the biggest being the latest is still in a bit of a transition period from v1, and as a community we didn't think someone would be posting about Hyperapp and make it to the top of hacker news. That really put us on the spot to try and get on here and explain the state of Hyperapp since we're probably more in a release candidate/late-beta situation rather than a full blown release.

You are absolutely correct!

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

I wouldn't necessarily say we're moving one way or another. React technically released before Mithril. It just so happens React became more popular and JSX is idiomatic in React. But hyperscript is usually compatible w/ JSX (in fact, in Mithril you can choose whether you want to use JSX or hyperscript)

Personally, I think indentation w/ hyperscript tends to look more natural for large sets of props, e.g.

    h('div', {
      id: 'hello',
      title: 'hello'
      onclick: () => {
        console.log('hello')
      },
    }, [
      // hi
      'hello'
    ])

    // vs

    <div
      id="hello"
      title="hello"
      onclick={() => {
        console.log('hello')
      }}      
    >
      {/*hi*/}
      hello
    </div>

Many projects still predominantly use Hyperscript with the option to use JSX (including Mithril and Hyperapp, and others like RE:DOM, snabbdom to name a few). Even React has an option to use it if you want to skip the JSX compile-step. So I wouldn't say we're necessarily moving away from it.

Personally, I prefer Hyperscript. It took maybe a day for me to get over its perceived ugliness and actually appreciate that it's plain, valid JavaScript.

Going back to PHP and ASP you mean.

Not sure of the reason, but it's a godsend comparatively. The reaction against JSX I find to be largely by people who've never actually used it.

If you keep your components small, as is best practice, whatever gut reaction one feels to it (which IMO is misplaced to begin with) is minimized, and quite readable.

100% agree, that's exactly what @hyperapp/html package attempts:

- https://www.npmjs.com/package/@hyperapp/html

Please don't. Not everyone uses these additional libraries or preprocessors, and it was a big hurdle to figure out what was actually being generated behind the scenes in the v1 docs.

A good approach is to show us what we need to do with no other dependencies (i.e. just as you're doing now with this h() function), and link to alternative syntaxes/libraries that may be optionally used instead.

the tutorial is great this way. it's gradually introducing concepts and shows what's possible with very few building blocks. at the end, it would be nice to mention that at the cost of some extra code and learning a few more functions/concepts, you can gradually make application code either more concise with @hyperapp/html or having a different aesthetic or more familiarity - similar to JSX - with htm or the hyperapp-tailored variant of it, hyper-lit.

but please keep the current didactic of piecemeal introduction of concepts, providing clear reasons for their existence!

A nice flourish would be to have every example with both, and have a global switch to pick which one you prefer.

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

I read about it but it just did not click as V1 did. Also I will not rewrite old code just for sake of change and I want all system to be on same framework if possible. I may actually do my own fork where only difference will be passing root state and root actions in addition to partial ones, which will fix great amount of issues I have.

Glad you found it useful.

I had sort of neglected it for a while, but during the course of the lockdown, I have started working on a major rewrite - replacing Gulp with Webpack, adding support for Edge, etc. Will release it soon :)