HN user

jbucaran

158 karma
Posts24
Comments32
View on HN
medium.com 8y ago

Show HN: Introducing Hyperapp 1.0 – 1KB JavaScript library for building web apps

jbucaran
6pts2
github.com 8y ago

Show HN: (1KB) JavaScript library for building fast and feature-rich web apps

jbucaran
9pts4
github.com 8y ago

Show HN: 1 KB JavaScript library for building front end apps

jbucaran
40pts0
medium.com 8y ago

Introducing Hyperapp 1.0 – 1 KB JavaScript library for building front end apps

jbucaran
13pts0
github.com 8y ago

Show HN: 1 KB JavaScript library for building applications

jbucaran
116pts8
github.com 8y ago

Show HN: Tiny (300B) and 20x faster alternative to React classNames

jbucaran
12pts0
gist.github.com 8y ago

Show HN: The Elm Architecture in 10 LOC

jbucaran
6pts0
github.com 8y ago

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

jbucaran
216pts42
github.com 8y ago

Show HN: Tiny (320B) JavaScript function for conditionally concatenating class names

jbucaran
5pts0
github.com 8y ago

Show HN: 1 KB JavaScript library for building front end apps

jbucaran
242pts2
github.com 8y ago

A tiny Node.js dependency installer

jbucaran
5pts1
github.com 8y ago

Show HN: Hyperapp – 1 KB JavaScript library for building front end apps

jbucaran
69pts7
codepen.io 9y ago

Show HN: HyperApp on CodePen. HyperApp Is a JavaScript Library Inspired by Elm and Redux

jbucaran
1pts0
github.com 9y ago

Show HN: 1 KB VDOM library with focus on minimalism and user friendliness

jbucaran
4pts0
codepen.io 9y ago

Show HN: D3.js/HyperApp-powered interactive fractals

jbucaran
5pts0
github.com 9y ago

Show HN: 1kb JavaScript library for building front end applications

jbucaran
187pts40
github.com 9y ago

Show HN: picodom – 1 KB Virtual DOM builder and patch algorithm

jbucaran
2pts0
github.com 9y ago

Show HN: 1kb JavaScript library for building front end applications

jbucaran
4pts0
github.com 9y ago

JavaScript meets Elm

jbucaran
2pts0
github.com 9y ago

Build your own next generation view library: 1kb vDOM builder and patch function

jbucaran
2pts1
glebbahmutov.com 9y ago

Blog: Pure functional programming with HyperApp

jbucaran
2pts0
www.infoworld.com 9y ago

HyperApp takes functional JavaScript to Web applications

jbucaran
3pts0
github.com 9y ago

1kb JavaScript UI Library HyperApp Benchmarks on par with InfernoJS

jbucaran
3pts0
github.com 9y ago

1kb functional JavaScript library for building UI applications

jbucaran
3pts2
Perl 6 Optimism 9 years ago

Yeah, but I think it's because they have the same name, only the number on the right is different and people tend to assume that Perl 6 is the one after 5.

[dead] 9 years ago

This milestone means the API has reached stability and the churn is finally over, which is one of the main reasons we haven't had time to work on the ecosystem.

[dead] 9 years ago

IIRC, it's the authors who get to post in "Show HN", that's the whole point of it and is what I did here.

Sorry, I am sure you could use JSX with DIO.js too. To be honest, I wasn't even looking at the JSX. I grabbed it from where I found it. The takeaway is not JSX, but the fact that they use classes and that's all.

Personally, if I was going to go with this kind of architecture, I'd choose Preact (or React if I can't help it) to tap into the massive React ecosystem.

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

And here is the same in Hyperapp:
    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>
    })

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 })
      }
    })
So, I used JSX for "familiarity", but you don't need to use it to build your own apps. You can just write the code shown in the snippet above and you'd do just as well. You can also minimize and bundle your code to tap into the JavaScript ecosystem, code using a modular style and still not have to use JSX at all.

Hope that helps :)

This is great. Let me say it again, great!

My feedback would be to make it easier to discover fonts. Right now I only have a few fonts to choose from the select box.

Another issue is that once a font is selected, I must erase the text in the select to get the select items drop down again.

If you grab hyperapp from the CDN https://unpkg.com/hyperapp@latest, you'd use it like this:

const { h, app } = hyperapp

If you setup a simple build pipeline using npm/yarn + browserify you would instead:

const { h, app } = require("hyperapp")

And if you compile your app with babel using babel-preset-es2015, etc., then you can use the ES6 import syntax.

===

Here are some gists to help you on your journey:

- hyperapp + hyperx + rollup minimal boilerplate https://gist.github.com/jbucaran/fac2c3de24e5171596fb189f9c1...

- hyperapp + hyperx + webpack minimal boilerplate https://gist.github.com/jbucaran/c6a6bdb5383a985cec6b0ae4ebe...

- hyperapp + jsx + rollup + buble minimal boilerplate https://gist.github.com/jbucaran/f714dd6d64041591e5e53dbff85...

- hyperapp + jsx + rollup minimal boilerplate https://gist.github.com/jbucaran/0c0da8f1256a0a66090151cfda7...

- hyperapp + jsx + webpack minimal boilerplate https://gist.github.com/jbucaran/6010a83891043a6e0c37a3cec68...

- hyperapp + hyperx + browserify minimal boilerplate https://gist.github.com/jbucaran/48c1edb4fb0ea1aa5415b6686cc...

- hyperapp + jsx + browserify minimal boilerplate https://gist.github.com/jbucaran/21bbf0bbb0fe973455056648831...

How does this compare to Mithril etc?

I am the author of HyperApp and also a big fan of Mithril. I'll try to compare both as fairly as I can. This is not a full or even adequate comparison, I'm just adding to the thread.

Mithril has something called auto-redrawing, that IIRC re-renders the application after DOM events by default. This can be seen as inefficient, but Mithril throttles rerenders, which ameliorate any issues caused by it.

Mithril has no state management solution out of the box.

This may be desirable if you want to experiment with different state management architectures until you find one that you like.

HyperApp has its own built-in state management solution which is inspired and draws a lot from the Elm Architecture. In this way, it's a lot like React and Redux, but since everything is built-in, there's essentially 0 boilerplate.

The drawback is that there's no other state management available for HyperApp.

Mithril has stateful components, which is a simple and useful way to reuse code across your app and easily port to other apps.

HyperApp has custom tags, which are pure functions and stateless. They only accept props and know how to render themselves. If you are coming from React, Backbone, Angular (basically everywhere else), scaling applications will seem difficult at first, but it's not, it's just different.

We are currently working on a component abstraction which is based on the idea of a fragmented state. We'll release 1.0.0 when that's done.

Mithril is bundled with m.request, which simplifies making HTTP requests.

HyperApp has no built-in facilities to help you make HTTP requests. I am not interested in a custom xhttp solution when there is a `fetch` standard.