I am almost sure "in fact" is always two words.
HN user
jbucaran
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.
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.
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.
It's being worked right now! :)
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...
I like and agree a lot with this definition too. Thanks!
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.
I remember I was perhaps 17 and while I really didn't understand very well what ColdFusion was about, I wanted to try it out so badly. Unfortunately, it wasn't free, so I was never able to get do anything with it. I enjoyed AS3 to the fullest though.
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>
})Thanks! Here is the release notes page of the last dozen of versions for now.
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.
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 :)
Diff and patch does happen via a virtual DOM, which is included in the source code. State management is also built-in.
Check out: https://github.com/picodom/picodom
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.
This is helpful to me because I want to learn how to explain (complex) systems.
Incidentally, this complexity is what led me to build my own little vdom utility <https://github.com/hyperapp/hyperapp>.
I'll be drawing inspiration from this chart to explain it.
Same here. Flow is great though and you can use it without annotations too, just not as useful.
See: http://thejameskyle.com/adopting-flow-and-typescript.html
Thanks! I love Elm too. Elm is functional programming for the masses! Recently I'm kind of more curious about ClojureScript.
That said, you can totally use Flow or TypeScript with hyperapp.
tl;dr Yes.
Originally it was just hyperapp, but many people asked for only the virtual DOM, so picodom was born.
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...
=IE10
Thanks! You can find more examples on CodePen.
What are the target developers for your library?
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).
Yes. It supports JSX and also ES6 template literals via hyperx or t7:
- https://github.com/substack/hyperx - https://github.com/trueadm/t7
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.
So, that's what "Show HN" was for. Thanks!
Depending on the application needs, I'd try something new:
- https://github.com/hyperapp/hyperapp
- https://github.com/KingPixil/moon
- https://github.com/pakastin/redom
And, if you must use React, then I'd choose Preact instead.