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
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>
})For the comparison example you did, don't post it anywhere officially :P because I can use babel with jsx preset (I am sure hyperapp is using too) and then do the stylish lambdas to make code look cleaner. That would be a fair comparison.
In my experience over the past few months, HyperApp works very well, the documentation is solid, the performance is great, and we've encountered no bugs so far.
If I had to do it over again, I would choose HyperApp again. Great work, folks.
Show HN: 2 MB JavaScript library for building front end applications with a lot of useful interactive ui components.
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.
I sure missed the simple, small, usable, multi page site we used before the "upgrade" to the single page app competitor! (On top of that, the old one worked fine on mobile. The new one, not at all.)
Everything old is new again...
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 :)
Coincidentally, the h() function up there looks very similar to what we used to render HTML in a 15-year-old Perl application that I maintained at work.
The whole library would be documented on one page which is a fairly low entry barrier for new developers. Thanks for this awesome project!
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/
If you are interested have a look here:
https://gist.github.com/jbucaran/8dc33b7947f3193eb2ea3d5700e...
https://news.ycombinator.com/item?id=13605673
It only works in modern browsers supporting Proxy.
https://facebook.github.io/react/docs/lists-and-keys.html#ke...
(Great project, BTW!)
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 :]
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.
I was an on-site support tech for a software company who wrote software for tracking market data for trading companies around Wall Street. The company used a huge MS Access "app" to track our knowledge base and customer support requests. The app obviously took a ton of time to develop but was slow and difficult to use and required a weekly upload / merge to the main office in Colorado.
So one day while strolling around downtown after lunch, I randomly happened upon some guy selling business and programming books on a table on the sidewalk (on Broad Street for those familiar). I bought a book on Cold Fusion 4 for $20 and over the next two months put together a prototype in my spare time that was a slick interface on top of the Access Database.
It was a hit with the NY office, and after about a year of working on it in my spare time, the whole company started using it. They replaced the Access app with my intranet and hired a SQL server guy to manage the database behind it. They didn't want me to leave my on-site support position because I was doing really well with it, so I ended up splitting my job - half time as a tech, half as a programmer.
That company, which was incredibly successful at the end of the 90s, has since shrunk from 150 or so employees around the world to less than 10. From what I understand they're still using that old Cold-Fusion based intranet I wrote all those years ago.
After I got laid off I moved on to PHP because I couldn't afford CF on my own.
AS3 remains, to this day, one of my favorite programming languages. I had really hoped JavaScript would start to resemble it eventually.
Still, I can't help but think that the real low-hanging fruit is the slow VPN. How much time was wasted waiting for the network? So many companies are penny-wise pound-foolish.
It's not impossible but it's a tough sell arguing for a 50k expenditure for better hardware for the VPN will actually save the company time worth >50k.
I'd say that there's a point where the overhead of spending money becomes high enough that companies will waste a lot of expensive employee time to avoid requisitioning something.
And although companies track high level time costs in a project management context, I'm not sure whether they're conscious of the way that time use can be driven by bits of waste.
That sorta fits "penny wise, pound foolish", but sorta doesn't.