Show HN: 1kb JavaScript library for building front end applications
github.com
github.com
- Code examples: https://glitch.com/edit/#!/hyperapp
- Browser demos: https://hyperapp.glitch.me/
- README: https://github.com/hyperapp/hyperapp/blob/master/README.md
This is a good example of what an open source project should do. Straight forward. And also, refreshing to see a lite javascript framework.
One suggestion to authors: Include a link to the demonstration's code on pages like https://hyperapp.glitch.me/slider.
html`<button onclick=${() => alert("Hi")}>Click</button>`
I've done something slightly similar in the past:
dom.body.html = `<button ${evt.on.click(e => console.log(e))}>Click me</button>`;
Honest question as the author seems the submitter, what are the target developers for your library? It seems (to me) that virtual dom + JSX is overkill for simple websites, while the big webapps seems to want the enterprise-backed React/Angular/Ember/Etc.
[1] https://github.com/hyperapp/hyperapp/blob/master/docs/hyperx...
[2] https://github.com/hyperapp/hyperapp/blob/master/src/app.js#...
Anyone. Big app devs, small app devs. For the record, you can user hyperapp with any of the following technologies:
- JSX
- A string template literal based solution like hyperx or t7.
- The built-in hyperscript-style `h` function (https://goo.gl/da3U3P).
Edit: already found example in project github.
Looks promising. Currently I'm looking for solution to replace jquery for one small popup for Chrome KeePassXC extension. HyperApp seems like good match. Thanks.
The thing that got me sold on the idea is how simple actions are. You can have them work like thunk by calling an action as a callback in another action or just return a promise. No middlewares to install, all by design of a 1kb lib.
[edit] when using, be careful with the recent API changes - it's not much, just some names, but took me a while to notice I'm reading docs to a newer version than what I've installed.
Looking forward to 1.0
Hyper.app: https://hyper.is/
hyperapp: https://github.com/hyperapp/hyperapp
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.
In Mithril:
The hyperscript function supports Emmet/Zencoding syntax: `m('input.myClass#myId[type=radio]')`
There's a stream library for state management (not an out of the box solution, but a robust building block).
The Mithril router
- supports `path`, `search` and `hash` modes
- supports asynchronous resolution (for lazy module loading)
- parses the current route at mount time and launches the app at that route if possible
The renderer
- has lifecycle hooks (that fire when nodes are created, updated, and removed, before and after the DOM is mutated),
- supports fragments (components can return arrays) and raw HTML nodes (the former with keys support).
- optimizes keyed diff for insertion/deletion of contiguous nodes
- AFAICT Mithril handles the attribute/property dichotomy better
Mithril also comes with a querystring parser and builder.
There are probably a lot of other small things that I didn't notice (and there may as well be errors in my assessment of hyperapp)
Edit: I take back what I said about forms. Either Chrome got their act together or hyperapp is doing something that I don't understand yet... Anyway, the naive app works well: https://flems.io/#0=N4IgTgpgZpDOAWAhArgF1QewHYgFxQEMAbWCAGhF...
My one complaint is that firing actions within actions feels imperative and could become hard to reason about. Perhaps observables could help here.
- https://github.com/substack/hyperx - https://github.com/trueadm/t7
> import { h, app } from "hyperapp"
I might be misunderstanding here, but isn't `import` unavailable in ES5? (I.e., just a future reserved word?)
> 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...
Originally it was just hyperapp, but many people asked for only the virtual DOM, so picodom was born.
FWIW I like Elm, and hyperapp seems a delightful port of the TEA idea ... plus for being a js library, with immediate access to JS and DOM. I'll look for examples using 3rd party visual widgets, and animation libraries.
That said IMO TEA is only a convenience. What I find supremely empowering about Elm is its type inference/system. If we got that in JS-land I likely wouldn't look at another language for some time to come :)
That said, you can totally use Flow or TypeScript with hyperapp.
Yes, of course, re using TypeScript or Flow. However ... I'm not a fan of TypeScript -- if I'm going to use a different "language" (albeit one that's a transpile-able thin veneer over JS) I may as well switch to a language w/ an even better type system.
Flow, from the little I know, is closer to what I want -- still JS, but an annotation or "compilation switch" makes everything typecheck.
See: http://thejameskyle.com/adopting-flow-and-typescript.html
The link works when copy/pasted. Let me read.