Show HN: HyperApp – 1k JavaScript framework for building web applications

[spankalee]

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html

Where JSX would look like this:

    const view = (state, actions) => (
      <div>
        <h1>{state.count}</h1>
        <button onclick={() => actions.down(1)}>-</button>
        <button onclick={() => actions.up(1)}>+</button>
      </div>
    )

The lit-html would be:

    const view = (state, actions) => html`
      <div>
        <h1>{state.count}</h1>
        <button onclick={() => actions.down(1)}>-</button>
        <button onclick={() => actions.up(1)}>+</button>
      </div>
    `;

Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.

[masklinn]

> Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.

So… it's not doing reconciliations and is just replacing the entire tree on every render, losing things like cursor position and forcing the browser to re-render and re-layout the entire thing?

[localvoid]

> so that it doesn't have to do any expensive VDOM diffs.

I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ?

1. https://rawgit.com/krausest/js-framework-benchmark/master/we...

[ricardobeat]

Also check out https://viperhtml.js.org/hyper.html, original inspiration for lit-html.

Same principle, different implementation, takes advantage of special string literal properties to achieve impressive speeds.

[crooked-v]

Template strings loses all the actual benefits of JSX, in that you can have your editor parse it for validity and type hinting in the same way as if it was all createClass class (but more convenient).

[plexicle]

Loving Polymer 3.0 and the new lit-element (which I believe just straight up used lit-html behind).

[gyrgtyn]

That looks just like choo!

choo https://choo.io/ uses tagged templates too.

It's 4kilobytes.

[grrowl]

You should check out https://github.com/choojs/choo (similar framework in 4kb) and other packages in its ecosystem — https://github.com/choojs/nanohtml (template strings to HTML elements)

[JustSomeNobody]

> ... expensive VDOM diffs

Wait, I thought VDOMs were supposed to be fast(er).

Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

[malydok]

Then you need to send lit-html over to the client also. This would be a great alternative if one doesn't already use Babel, but what's the selling point otherwise? Is there an easy way to combine lit-html's render with the HyperApp one?

[always_good]

But then you miss out on html syntax highlighting and jsx eslint.

Or is there tooling that works for the tagged template approach?

[hellcow]

This is an exceptionally simple library to use in place of React. Both its performance and the development experience have been great.

My company's been using it in production for more than a year now without any issues. Highly recommend giving it a look.

[pault]

Just out of curiosity, what was your use case that you deemed this a better option than react for?

[agumonkey]

people should really give it a book

[owlfarm]

It's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/we...

[starbuzz]

Hyperapp is not optimized to be the fastest framework at the expense of worse developer experience. Having said that, we're definitely working on improving our runtime performance (see https://github.com/hyperapp/hyperapp/issues/499). So much to do!

I want to point out that while these benchmarks are very useful to detect underlying, potentially serious runtime and memory performance issues in your algorithm/framework, the implicit idea that even the slowest framework according to this list (e.g. choo) is a poor choice or inadequate for frontend development is ridiculous (the js-framework-bench creates > 80,000 nodes).

Please don't do that to your users, regardless of the framework you are using. Even the most complex user interface will have < 10,000 nodes. Tables/grids may get you there faster, however.

Still, in the case of Hyperapp we're talking about 100 to 200 milliseconds slower in the worst test (i.e., partial update) for a worst-case scenario.

[starbuzz]

This is an old benchmark, we're in the same ballpark as React now. Hyperapp is also not just a virtual DOM, but also a state management "all-in-one" kind of thing.

[gandreani]

Wow kudos to the author! Very nice resource

[ricardobeat]

hyperhtml - which this is based on, similar API - can be found at the left end of the table.

[ninjaturtles]

I've seen "Show HN: HyperApp" type of submissions at least 5 times earlier. Congrats, you made a 1Kb JS library. Please stop spamming HN though.

https://hn.algolia.com/?query=hyperapp&sort=byPopularity&pre...

[romanovcode]

I don't even get why it is important that it's 1kb. Give me a library with great API and easy to use. Nobody cares if library is 1kb or 100kb (minified).

[starbuzz]

Some of those results refer to HyperTerminal, the Electron-based terminal app. Other results refer to Hyperapp-like libraries (not Hyperapp). The most recent submission related to Hyperapp was 8 months ago and Hyperapp has come a long way since then.

Here is another angle to this: go into React type of submissions and ask them to stop spamming HN with that?

https://hn.algolia.com/?query=react&sort=byPopularity&prefix...

[gandreani]

In the same vein there's Mithril. It's 8kb but includes a router and a fetch polyfill!

I love these little JS frameworks :)

https://mithril.js.org/

[dsego]

Mithril is nice. One downside is it doesn't lend itself really well to compound components. Everything has to be passed down through attributes.

[soapdog]

Just want to second Mithril here. It is an awesome and refreshing approach. I love it too.

[Karupan]

I love hyperapp! As someone who thinks Elm’s architecture is ideal for building webapps, it’s great to be able to almost replicate it in JS. It’s simple enough to get started quickly but still robust enough to build actual apps and not just toys.

[fouc]

You might be interested in this: https://github.com/pakx/the-mithril-diaries/wiki/Coming-From...

[mmanfrin]

I got confused thinking this was a new thing from Zeit -- who made Next.js and Hyper.app (https://hyper.is/)

[starbuzz]

HyperTerminal

[coldcode]

This makes me almost want to write web code again - compared to things like React and Angular 1-2-3-4-5-6.

[gramstrong]

Just curious what intrigues you about this framework in ways that React does not?

[dereke]

I agree. The more alternatives to react and angular the better.

React has a massive API for what is something essentially quite simple.

Personally my favourite "alternative" rendering library is hyperdom. Fast, simple and just gets the job done.

https://github.com/featurist/hyperdom/

[matte_black]

Not sure what your problem with React is, is it the configuration?

[czechdeveloper]

I've tried hyperapp and liked it a lot. I loved that can read full source code and actually understand what it is doing under the hood.

[starbuzz]

This is a crucial aspect of Hyperapp that often goes unnoticed because simply no one in their sane judgment expects it.

[no_wizard]

This looks pretty awesome! Inspired by hyperscript I assume?

https://github.com/hyperhype/hyperscript

Question: I was looking over the source and noted that you weren’t building your virtual dom with the document fragment API https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

Is there any particular reason why? I’m curious because it’s my general understanding that creating a document fragment and attaching your vnodes to that and then pushing to the dom is more efficient especially for diffing

[oron]

This is the best thing I discovered since leaving React. x10 dev speed for me, not to speak about loading times. Superb work!

[sAbakumoff]

So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare

[Vinnl]

https://packages.gentoo.org/packages/dev-haskell/shakespeare...

[kapv89]

I'd disagree. React is very much a "Shakespeare" of javascript frameworks. It has solved UI dev by making even the most complex types of UIs predictably programmable. (Note: not including redux in this, which no developer who owns their time would use)

[starbuzz]

> So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare

Not even funny IMO. This is the kind of toxic comment that don't motivate progress in this community.

[devmunchies]

How does this compare to Preact?

[starbuzz]

I replied to another similar comment but the TL;DR is that both are solving different things. Preact is a React 15 clone.

Hyperapp is basically Elm in JavaScript.

[curiousreacter]

Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?

[vtange]

How does this compare to Inferno, which you can also use JSX and Hyperscript with - https://github.com/infernojs/inferno

This seems smaller in footprint, but does it also win in runtime performance and stability?

[c0brac0bra]

I've really enjoyed using Hyperapp so far. Looking forward to building more with it.

[janci]

Does it work well with inputs? (text, checkboxes, radios, selects)

[niksmac]

It looks more like Elm