Show HN: 1 KB JavaScript framework for building front-end applications

OK, we'll s/library/framework/ the above.

I like and agree a lot with this definition too. Thanks!

One thing I like about the Hyperapp approach though is use of plain JavaScript objects and pure functions to build your app. This means that it's possible to only have a dependency on Hyperapp in one place as part of assembling the overall app.

I tried Vue.js and thought it was pretty nice. As someone who only dabbles in modern front end in their spare time, it'd be great to see someone with more experience do a good comparison write-up of all the "post-React" alternatives.

I honestly love that these libraries keep getting smaller and faster. People have really started to hate these newer libraries, but as long as they are getting better, I'm fine with experimenting with them.

Vue even has a lighter alternative called Moon[1], which was on HN a while back. I'm curious as well about the performance of HyperApp. Looking at the JS frameworks benchmark[2], it's not the best, but not the worst either (pretty good for squeezing it all into 1kb).

[1] http://moonjs.ga

[2] https://github.com/krausest/js-framework-benchmark

Thanks for the comment :)

Hyperapp doesn't outperform DIO.js, but that was never the mission I embarked on with this project. You can see it benchmarked <https://rawgit.com/krausest/js-framework-benchmark/master/> among many other frameworks and you can see it's on the same ballpark as React.

The goal of this project is to minimize the concepts you need to learn to write a modern frontend app while staying on par with what other libraries can do; deliver good performance, but not at the sake of a clumsy or awkward API; reduce the boilerplate and still follow our "simplified" take on Flux or the Elm architecture if you prefer.

Hyperapp is unreservedly functional, we don't have stateful components, use `this`, classes or have more than one way to do the same thing.

We are not just about saving bytes either, but size and our brutally small code base is important for a few reasons. The idea behind the entire thing being 300 LOC is that _anyone_ can understand how everything works within a few hours. It's genuinely possible to understand not just what it does, but how it does it.

IMHO a normal person can't do that with React, or DIO, or most of the other large-ish frameworks out there. Even Preact, I found it too large for my taste. Yes, minified and gzipped is like 3.4 KB, but that translates to almost 800 LOC. It's an outstanding achievement considering it's just a fraction of React, but you are only getting React+ReactDOM.

Hyperapp is not perfect, but you are getting React+ReactDOM+Redux+ReduxThunk out of the box.

Just for a light (and harmless) comparison, this is a +/- counter in DIO.js:

    class Counter {
      getInitialState () {
        return {
          count: 0
        }
      }
      increment () {
        return {
          count: this.state.count + 1
        }
      }
      decrement () {
        return {
          count: this.state.count - 1
        }
      }
      render () {
        return [
          this.state.count,
          h('button', {onClick: this.increment}, '+'),
          h('button', {onClick: this.decrement}, '-')
        ]
      }
    }

    dio.render(Counter);

    app({
      state: 0,
      actions: {
        add: state => state + 1,
        sub: state => state - 1
      },
      view: (state, actions) =>
        <div>
          <button onclick={actions.add}>+</button>
          <h1>{state}</h1>
          <button onclick={actions.sub}>-</button>
        </div>
    })

I agree.

The fight for really small frameworks is most relevant for consumer apps, especially ones consumed on mobile.

But even on mobile, it's primarily relevant because customers get minimal value from your app or are bad at accurately assessing the value they get.

In my day job, I work on a system where business users spend several hours a day using it. Loading a MB of minified JS has such a limited effect on the overall time it takes users to get their work done, it's almost irrelevant. Though, per the point about accuracy above, I wonder how it affects our demos.

Don't think that will catch on ;)

What you are looking at is called JSX[1]. It's not valid JavaScript, but is turned into function calls by transpilers such as Babel[2]. It's used as a more HTML-like syntax of writing function calls that output a representation of the DOM known as a "virtual DOM". You can embed JavaScript inside of JSX by using single curlies.

[1] https://facebook.github.io/jsx/

[2] http://babeljs.io/

It's JSX which is basically PHP reborn as a front end technology.

Everything old is new again...

It doesn't, that's not valid ES{4,5,6,2016,2017} code.

It's called JSX. I used it in the example because it's popular among the JavaScript crowd, popularized by React.

That code is not directly consumed by the browser, instead, it's compiled into the code below by a compiler like Babel, minified and bundled into a tiny blob of code we ship to the browser.

    app({
      state: {
        count: 0
      },
      view: (state, actions) =>
        h("main", {}, [
          h("h1", {}, [state.count]),
          h("button", { onclick: actions.down }, "-"),
          h("button", { onclick: actions.up }, "+"),
        ]),
      actions: {
        down: state => ({ count: state.count - 1 }),
        up: state => ({ count: state.count + 1 })
      }
    })

Hope that helps :)

I like this approach a lot, especially as implemented in [1].

Perhaps a tutorial, or some examples can be documented in that style. Hyperapp + hyperscript-helpers[2] is my favorite combo at the moment.

1. http://dave.kinkead.com.au/modelling-the-boundary-problem/

2. https://github.com/ohanhi/hyperscript-helpers

That would be so nice! I am working on a "how it works" post, but it's still not finished.

If you are interested have a look here:

https://gist.github.com/jbucaran/8dc33b7947f3193eb2ea3d5700e...

Looks really cool, other than Object.assign, Proxy and Symbol I think this is quite an achievement for that size, but I am pretty sure it doesn't support keyed DOM updates. Hyperapp was also under 1 KB before we introduced the keyed VDOM.

We've come a long way since then. We are super close to 1.0 now and while the API hasn't changed much, there have been numerous breaking changes and we've also added new features, documentation, examples and seen the ecosystem grow too.

I have made a few simple sites with hyperapp in its various stages of development. I am not advocating that any of these projects represent the _proper_ way to build a hyperapp (or a web app in general for that matter, I am learning too) but they are hyperapps.. in production!

Site: https://audiostream.world Repo: https://github.com/joextodd/audiostream

Site: https://browses.io Repo: https://github.com/browses/frontend

Site: https://plural.video Repo: https://github.com/lukejacksonn/plural

Site: https://hyperapp-hn.deployable.site Repo: https://github.com/lukejacksonn/hyperapp-hn

There is also https://github.com/hyperapp/awesome-hyperapp which is full of much community goodness.

Hope that helps! Join us on slack if you have questions :]

I can't take credit for this one, but there's a HN clone: https://github.com/traducer/hypernews