
Show HN: HyperApp – 1k JavaScript framework for building web applications - starbuzz
https://github.com/jorgebucaran/hyperapp/
======
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](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?

~~~
ithkuil
Highly recommended to watch
[https://youtu.be/Io6JjgckHbg](https://youtu.be/Io6JjgckHbg)

~~~
masklinn
Yeah nah, I'm not watching a 30mn video on something I'm not interested in to
get what amounts to a 2-paragraphs answer.

~~~
anonytrary
30m sends you home? Watch it on 2x and skip parts you aren't interested in.

~~~
itsnotlupus
I really want a way to get a generated voice recognition transcript for all
that content people really think needs to be in video form. 2x playback is
still 14:45 too long in this instance.

~~~
spankalee
It's not that anyone thought it _needed_ to be in video form, it's just a
conference talk. For reading there's the readme here:
[https://github.com/Polymer/lit-html](https://github.com/Polymer/lit-html) and
documentation site here: [http://polymer.github.io/lit-
html/](http://polymer.github.io/lit-html/)

They both go into how lit-html works and how it doesn't just throw away and
recreate the DOM on re-renders, though I admit the docs could still be better.

------
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?

~~~
hellcow
We use Hyperapp to power our most complex UIs (decision trees, onboarding
sequences, etc.). We didn't need any of the existing React ecosystem for that,
and by removing React, we saw several benefits:

1\. Smaller library for faster page loads

2\. Simpler API, docs and library made it easy to get started and understand
what's happening behind the scenes as well as debug any issues we faced

3\. We aren't supporting a project run by Facebook, which I personally view as
a good thing given Facebook's many previous issues. Facebook's patent clause
(while it no longer exists) was a factor in our original decision.

I would choose Hyperapp again for my company, and I use it for personal
projects as well.

~~~
m0meni
Why not Preact?

~~~
hellcow
It came down to preference. I find HyperApp's codebase simpler to read/reason
about (it's a pretty straightforward single file), and I prefer its API over
React/Preact's.

------
owlfarm
It's not very performant compared to other v-doms
[https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

~~~
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.

~~~
bufferoverflow
It's not old, it was last updated two days ago:

[https://github.com/krausest/js-framework-
benchmark/commits/m...](https://github.com/krausest/js-framework-
benchmark/commits/master/webdriver-ts-results/table.html)

~~~
starbuzz
I meant the benchmark is using an older version of Hyperapp.

[https://github.com/krausest/js-framework-
benchmark/tree/mast...](https://github.com/krausest/js-framework-
benchmark/tree/master/frameworks/hyperapp-v1.2.0-keyed)

The js-framework-benchmarks is very much maintained and actively developed.
It's our go-to benchmark when fine-tuning for a new release.

In addition to that, the latest code on master (still unpublished) includes
some notable improvements:

[https://github.com/hyperapp/hyperapp/pull/663](https://github.com/hyperapp/hyperapp/pull/663)

------
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...](https://hn.algolia.com/?query=hyperapp&sort=byPopularity&prefix&page=1&dateRange=all&type=story)

~~~
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).

~~~
RussianCow
> Nobody cares if library is 1kb or 100kb (minified).

You do if your app needs to be mobile-friendly. 100kb can easily add an extra
second or two to the page load on a bad enough mobile connection.

~~~
brlewis
It isn't just on bad connections: [https://medium.com/dev-channel/the-cost-of-
javascript-84009f...](https://medium.com/dev-channel/the-cost-of-
javascript-84009f51e99e)

~~~
romanovcode
Article has 300kb+ of javascript on mobile, loads pretty fast on 3G. I don't
know what you're talking about.

------
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/](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.

~~~
davegauer
True, but by passing the same object as an attribute to a pair of Mithril
components, I can have them share state. (Can be restricted to the scope of a
parent component if desired.) Is there an additional requirement for compound
components?

~~~
dsego
There isn't a built-in way to detect type of component. It would be useful
when you want a parent component to encapsulate certain logic/behavior but not
hard-code the presentation. I know there's name() but it only works if my
component is a function. Otherwise I think I need to assign some special
identifier, which sucks.

You can see a great presentation of the technique in this video:
[https://youtu.be/hEGg-3pIHlE](https://youtu.be/hEGg-3pIHlE)

------
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...](https://github.com/pakx/the-mithril-
diaries/wiki/Coming-From-Elm)

~~~
starbuzz
Hyperapp will be a lot more Elm-like in a future release, see this too:
[https://github.com/hyperapp/hyperapp/issues/672](https://github.com/hyperapp/hyperapp/issues/672)

------
mmanfrin
I got confused thinking this was a new thing from Zeit -- who made Next.js and
Hyper.app ([https://hyper.is/](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?

~~~
starbuzz
Hyperapp is Elm for the rest of us. I wouldn't compare it to React as they are
solving slightly different problems. Hyperapp's state management is built-into
the framework. In this way, Hyperapp is a tad more "high-level" (abstract)
than React.

~~~
agentultra
> Hyperapp is Elm for the rest of us.

Curious who you think Elm is for?

~~~
starbuzz
Elm is for anyone. I love Elm.

"for the rest of us" is a common English language idiom/phrase.

[https://english.stackexchange.com/questions/41687/meaning-
of...](https://english.stackexchange.com/questions/41687/meaning-of-the-
phrase-for-the-rest-of-us)

I know the idiom mostly from For Dummies' books. I'm implying that Elm, while
great, is not as user-friendly, intuitive or easy to use as Hyperapp.

I'm saying that Hyperapp is deeply inspired by Elm, but also designed with
extreme devotion to details, minimalism, and simplicity.

~~~
agentultra
> I'm implying that Elm, while great, is not as user-friendly, intuitive or
> easy to use as Hyperapp

First, Elm is designed to be user friendly. The designers of the language have
put effort into ensuring the error messages are understandable. The messages
even include information on how to potentially resolve them! Elm's error
messages are much more friendly than most Javascript error messages I've seen.

Second, there is nothing intuitive about programming. If there were we
wouldn't need years of training to gain proficiency: you could simply give a
human being a computer and they would be able to do it in the absence of
conscious reasoning. Despite our best efforts and research there has yet to
emerge a language that is intuitive.

> designed with extreme devotion to details, minimalism, and simplicity

I believe Elm is also designed with these concepts in mind.

It sounds like it's not the kind of simplicity you're used to and that may be
why Hyperapp is _for you_.

I interpreted the phrase, _for the rest of us_ , to be a false equivalence
between all programmers that do not use Elm and programmers with the same
opinions and needs as you. I think I understand your point better now but it
would have been clearer if you had left out that phrase and enumerated why
it's better for _people who need X_ instead.

------
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](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...](https://developer.mozilla.org/en-
US/docs/Web/API/DocumentFragment)

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

~~~
dlbucci
I have heard that as long as elements aren't actually in the DOM, they are as
fast as fragments, so you can use document.createElement instead of fragments.
No idea if that's true or not.

------
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

~~~
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)

~~~
sAbakumoff
>>It has solved UI dev by making even the most complex types of UIs
predictably programmable.

What's that they say about each and every framework. IMHO there is no
Shakespeare and all JS frameworks will eventually die once web assembly is in
place.

------
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"}?

~~~
RussianCow
It depends. If you are making a shallow copy every time via `Object.assign` or
the `{...obj}` syntax, then yes, it is rather inefficient. But a) for many
(most?) apps it's Good Enough™, and b) you can always use a specialized
library like Immutable.js to greatly reduce the overhead.

I'm not sure about what would be the benefit of the scheme you are proposing.
Are you proposing that the diff then gets applied directly to the state
(`state.foo += 1`)? If so, you would remove a powerful assumption that Redux
gives you: that a state object will never change from underneath you after
being returned from the store. If, instead, you would make a shallow copy of
every value affected by the diff, then you haven't gained anything over Redux,
and in fact have made the API significantly more complicated for no benefit
(aside from maybe slightly less boilerplate for deep paths).

~~~
curiousreacter
Oh right, immutable data structures are good for exactly this situation. I've
been in mutation land for a while now. :)

However, now I'm newly confused: Yes, I'm proposing that the diff then get
applied directly to the state by the Redux infrastructure, and I don't
understand why that would break any important assumptions provided by Redux.
Is there an example you could give of how this might create a problem?

~~~
RussianCow
You would have to be much more disciplined with your approach. With Redux, if
I store a reference to any part of the state, I am guaranteed that the value
will never be changed by Redux itself (so, unless I manually mutate it, it is
guaranteed to be frozen [0]). Because of this, I can do things like safely
store a value off of the Redux state inside a component, and when the state
changes, I can compare the new value against my stored value to see if it has
changed. If you directly mutate state, then the reference would update in-
place, so there is no way to compare changes locally without first making a
copy.

It also goes the other way: _I can 't accidentally change the state_ by
mutating the object I get back. With your scheme, any "accidental" mutation on
any part of the state will _actually_ change the state. This opens up a whole
world of bugs, because any time you want to store part of the state locally
(inside a component, for instance), you have to remember to make a copy if you
want to guarantee that no unwanted side effects occur. (Plus, getting into the
convention of "everything is immutable" means you can generally be much more
confident about passing objects around without fear of them being mutated
unexpectedly.)

Edit: Now that I think about it, what you are proposing sounds pretty similar
to MobX.[1] You should check it out if you haven't already. I personally
strongly prefer Redux for the reasons I mentioned, but it's a pretty solid
library either way.

[0]: In development, it's very easy to enforce this with Redux by simply
calling `Object.freeze` on the state in the root reducer, completely
preventing the state object from being mutated.

[1]: [https://mobx.js.org/](https://mobx.js.org/)

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

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

~~~
Karupan
Hyperapp can use JSX via the transform-react-jsx plugin.

------
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)

~~~
ricardobeat
Seems so
[https://codepen.io/anon/pen/yjrydY?editors=0010](https://codepen.io/anon/pen/yjrydY?editors=0010)

------
niksmac
It looks more like Elm

~~~
starbuzz
If all goes according to plan, it will look even more like Elm in the next
major release (2.0).

------
cpburns2009
Wow, there's an overwhelming total of 2 comments in the source file. The first
indicates a constant value. The second lacks all context. Looks like typical
JavaScript code.

~~~
dang
This comment violates both the site guidelines ("Please don't post shallow
dismissals, especially of other people's work.") and the Show HN guidelines:
see "In Comments" in
[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html).

~~~
cpburns2009
Understood. I'll refrain from such comments in the future.

~~~
dang
Appreciated!

------
madmaniak
Another Virtual DOM thing - which is obviously wrong.

~~~
czechdeveloper
Can you explain (or link some source) why is Virtual DOM wrong? Actually
curious.

~~~
lhorie
Hi. I'm the author of Mithril (one of the virtual dom frameworks mentioned
elsewhere in this thread), so I think can answer that.

To be honest, there's nothing inherently "wrong" with it. There are various
techniques to implement templating engines and they all have pros and cons.

Lately, VDOM performance in micro benchmarks has sort of plateaued, and
recently non-vdom systems like Svelte (an AOT compilation system) and Surplus
(a KVO system) have been making some splash as potential candidates to surpass
vdom performance. One could argue that it would be "wrong" or "a waste of
time" to try to one-up template performance by attempting to make a new vdom
implementation because existing ones are pretty much as optimized as they can
be. Since there hasn't been nearly as much effort put into alternative
algorithms, it probably would be more fruitful to explore a non-vdom approach
instead.

Do note though that I'm talking about R&D sort of stuff above. For people
building actual apps, vdom performance is generally good enough for a vast
majority of real-world use cases (evidenced by React's popularity) and one of
its appeals is that it lends itself to being manually optimizable it if you do
end up with a ridiculously ginormous DOM.

~~~
localvoid
> Since there hasn't been nearly as much effort put into alternative
> algorithms

Angular2+ team is actually have done an awesome job at experimenting in this
problem space. And they've moved away from generating code that is similar to
what Svelte does long time ago.

------
mychael
Why?

------
isakkeyten
This one is 25 bytes gzipped [http://vanilla-js.com/](http://vanilla-js.com/)

~~~
no_wizard
You do realize that this is simply a page that advocates using plain
JavaScript and isn’t an actual “framework” right?

I mean I can see the point you are trying to make, but it feels mildly
disingenuous to link to this without explaining what you really mean.

~~~
danlugo92
It's just a joke really.

~~~
cpburns2009
I have a better one.

Knock knock... blank page... <Ctrl>+<Shift>+<I>: "Uncaught TypeError: cannot
read property 'a' of undefined."

