Show HN: HyperApp – 1k JavaScript framework for building web applications
github.com
github.com
Where JSX would look like this:
const view = (state, actions) => (
<div>
<h1>{state.count}</h1>
<button onclick={() => actions.down(1)}>-</button>
<button onclick={() => actions.up(1)}>+</button>
</div>
)
const view = (state, actions) => html`
<div>
<h1>{state.count}</h1>
<button onclick={() => actions.down(1)}>-</button>
<button onclick={() => actions.up(1)}>+</button>
</div>
`;
Web Components and Shadow DOM make this possible. You can mix and match components that use lit-html, Polymer, Preact, etc., and mostly likely HyperApp.
I think within your own components it makes sense to stick with a single library setup for this reason, but atleast if you want to use a third-party component you don't have to rule out components that use different rendering machinery. You just have to weigh that additional download penalty.
Same principle, different implementation, takes advantage of special string literal properties to achieve impressive speeds.
Wait, I thought VDOMs were supposed to be fast(er).
Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.
Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings.
1. See e.g. https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.
So… it's not doing reconciliations and is just replacing the entire tree on every render, losing things like cursor position and forcing the browser to re-render and re-layout the entire thing?
They both go into how lit-html works and how it doesn't just throw away and recreate the DOM on re-renders, though I admit the docs could still be better.
Relevant part is at 8:30: "at first it will render the DOM and after that it will update what's already there"
choo https://choo.io/ uses tagged templates too.
It's 4kilobytes.
Or is there tooling that works for the tagged template approach?
I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ?
1. https://rawgit.com/krausest/js-framework-benchmark/master/we...
1. benchmarks have zero information value
2. be careful about wording, react does effective DOM update, but effective does not always mean fast - what I mean is that compiled templates are usually much faster than doing vdom diffing along with all of that destructuring and other unoptimizable (prepack might help, but it's far from being usable) stuff
Statements without any proof is more valuable than "benchmarks with zero information value"?
> what I mean is that compiled templates are usually much faster than doing vdom diffing
If they are usually much faster, why it is so hard to make them perform faster than vdom libraries in this benchmark? Or maybe any other benchmark, please just show me something that I can measure.
My company's been using it in production for more than a year now without any issues. Highly recommend giving it a look.
1. Smaller library for faster page loads
2. Simpler API, docs and library made it easy to get started and understand what's happening behind the scenes as well as debug any issues we faced
3. We aren't supporting a project run by Facebook, which I personally view as a good thing given Facebook's many previous issues. Facebook's patent clause (while it no longer exists) was a factor in our original decision.
I would choose Hyperapp again for my company, and I use it for personal projects as well.
Hyperapp is Elm-like state management (and soon effects and subscriptions in 2.0) on top of an ultra-lightweight virtual DOM diff engine.
Preact is a React 15 clone at best. Check out also https://github.com/NervJS/nerv for another React clone that is closer to React 16 (but still no fiber).
There's a book though: https://booth.pm/ja/items/825889 (Japanese)
https://github.com/krausest/js-framework-benchmark/commits/m...
https://github.com/krausest/js-framework-benchmark/tree/mast...
The js-framework-benchmarks is very much maintained and actively developed. It's our go-to benchmark when fine-tuning for a new release.
In addition to that, the latest code on master (still unpublished) includes some notable improvements:
I want to point out that while these benchmarks are very useful to detect underlying, potentially serious runtime and memory performance issues in your algorithm/framework, the implicit idea that even the slowest framework according to this list (e.g. choo) is a poor choice or inadequate for frontend development is ridiculous (the js-framework-bench creates > 80,000 nodes).
Please don't do that to your users, regardless of the framework you are using. Even the most complex user interface will have < 10,000 nodes. Tables/grids may get you there faster, however.
Still, in the case of Hyperapp we're talking about 100 to 200 milliseconds slower in the worst test (i.e., partial update) for a worst-case scenario.
https://hn.algolia.com/?query=hyperapp&sort=byPopularity&pre...
You do if your app needs to be mobile-friendly. 100kb can easily add an extra second or two to the page load on a bad enough mobile connection.
Plenty of people do care about frontend performance (as evidenced by the plethora of efforts ranging from small alt vdom libs by solo devs to large corporate efforts like AMP or m.uber.com[1])
So large library size == mediocre?
Jesus christ, HN is full of extremists.
If your problem space requires a lot of code, then off course not.
Also, library size !== mediocrity at all. No one builds an unreasonably large framework on purpose either.
And I, as a user, am left waiting several seconds waiting for pages larger than the original Doom executable to load. It's gotten so bad that my wife had to be selective of when to use her phone because browsing normally without wifi from starbucks etc would get her over the plan limit by mid-month. I mean, how much browsing are you really supposed to be able to do when every page is several MBs of JS alone, and you have a 300MB/mo plan to work with? Not every country has cheap/good mobile plans.
Here is another angle to this: go into React type of submissions and ask them to stop spamming HN with that?
https://hn.algolia.com/?query=react&sort=byPopularity&prefix...
Show HN: 1 KB JavaScript library for building front end apps 242 points jbucaran 8 months ago 2 comments (https://github.com/jbucaran/hyperapp)
Show HN: 1 KB JavaScript framework for building front-end applications 216 points jbucaran 8 months ago 42 comments (https://github.com//hyperapp/hyperapp)
Show HN: 1kb JavaScript library for building front end applications 187 points jbucaran a year ago 40 comments (https://github.com/hyperapp/hyperapp)
Show HN: 1 KB JavaScript library for building applications 116 points jbucaran 7 months ago 8 comments (https://github.com/JorgeBucaran/hyperapp)
Show HN: 1 KB JavaScript library for building front end apps 40 points jbucaran 5 months ago 0 comments (https://github.com/hyperapp/hyperapp/releases/tag/1.0.0)
Show HN: (1KB) JavaScript library for building fast and feature-rich web apps 9 points jbucaran 5 months ago 4 comments (https://github.com/hyperapp/hyperapp#hyperapp)
Show HN: 1kb JavaScript library for building front end applications 4 points jbucaran a year ago 0 comments (https://github.com/hyperapp/hyperapp)
1kb functional JavaScript library for building UI applications 3 points jbucaran a year ago 2 comments (https://github.com/hyperapp/hyperapp)
Show HN: Less is More (1KB) JavaScript library for building user interfaces 2 points JorgeBucaran 4 months ago 0 comments (https://github.com/hyperapp/hyperapp#hyperapp)
JavaScript meets Elm 2 points jbucaran a year ago 0 comments (https://github.com/hyperapp)
Wow, so you're right. Do you need to be so rude about it?
I love these little JS frameworks :)
You can see a great presentation of the technique in this video: https://youtu.be/hEGg-3pIHlE
I also avoid keeping state on components. I know this is controversial and it requires a bit of overheard. However, the simplicity offered by having all state in a single object is worth it for me.
Curious who you think Elm is for?
"for the rest of us" is a common English language idiom/phrase.
https://english.stackexchange.com/questions/41687/meaning-of...
I know the idiom mostly from For Dummies' books. I'm implying that Elm, while great, is not as user-friendly, intuitive or easy to use as Hyperapp.
I'm saying that Hyperapp is deeply inspired by Elm, but also designed with extreme devotion to details, minimalism, and simplicity.
First, Elm is designed to be user friendly. The designers of the language have put effort into ensuring the error messages are understandable. The messages even include information on how to potentially resolve them! Elm's error messages are much more friendly than most Javascript error messages I've seen.
Second, there is nothing intuitive about programming. If there were we wouldn't need years of training to gain proficiency: you could simply give a human being a computer and they would be able to do it in the absence of conscious reasoning. Despite our best efforts and research there has yet to emerge a language that is intuitive.
> designed with extreme devotion to details, minimalism, and simplicity
I believe Elm is also designed with these concepts in mind.
It sounds like it's not the kind of simplicity you're used to and that may be why Hyperapp is _for you_.
I interpreted the phrase, for the rest of us, to be a false equivalence between all programmers that do not use Elm and programmers with the same opinions and needs as you. I think I understand your point better now but it would have been clearer if you had left out that phrase and enumerated why it's better for people who need X instead.
> https://www.theatlantic.com/education/archive/2016/02/will-t...
> https://jelastic.com/blog/functional-programming-is-a-ghetto...
The concept is that placing a focus on a specific technology is a path to decay (poverty, obsolescence, self-destruction, etc).
React has a massive API for what is something essentially quite simple.
Personally my favourite "alternative" rendering library is hyperdom. Fast, simple and just gets the job done.
https://github.com/hyperhype/hyperscript
Question: I was looking over the source and noted that you weren’t building your virtual dom with the document fragment API https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...
Is there any particular reason why? I’m curious because it’s my general understanding that creating a document fragment and attaching your vnodes to that and then pushing to the dom is more efficient especially for diffing
Not even funny IMO. This is the kind of toxic comment that don't motivate progress in this community.
What's that they say about each and every framework. IMHO there is no Shakespeare and all JS frameworks will eventually die once web assembly is in place.
Hyperapp is basically Elm in JavaScript.
I'm not sure about what would be the benefit of the scheme you are proposing. Are you proposing that the diff then gets applied directly to the state (`state.foo += 1`)? If so, you would remove a powerful assumption that Redux gives you: that a state object will never change from underneath you after being returned from the store. If, instead, you would make a shallow copy of every value affected by the diff, then you haven't gained anything over Redux, and in fact have made the API significantly more complicated for no benefit (aside from maybe slightly less boilerplate for deep paths).
However, now I'm newly confused: Yes, I'm proposing that the diff then get applied directly to the state by the Redux infrastructure, and I don't understand why that would break any important assumptions provided by Redux. Is there an example you could give of how this might create a problem?
It also goes the other way: I can't accidentally change the state by mutating the object I get back. With your scheme, any "accidental" mutation on any part of the state will actually change the state. This opens up a whole world of bugs, because any time you want to store part of the state locally (inside a component, for instance), you have to remember to make a copy if you want to guarantee that no unwanted side effects occur. (Plus, getting into the convention of "everything is immutable" means you can generally be much more confident about passing objects around without fear of them being mutated unexpectedly.)
Edit: Now that I think about it, what you are proposing sounds pretty similar to MobX.[1] You should check it out if you haven't already. I personally strongly prefer Redux for the reasons I mentioned, but it's a pretty solid library either way.
[0]: In development, it's very easy to enforce this with Redux by simply calling `Object.freeze` on the state in the root reducer, completely preventing the state object from being mutated.
[1]: https://mobx.js.org/
Redux can be complicated, but Redux is way simpler and easier to reason about than the Meiosis patterns.
Undelivered promise.
Basically, I'm not certain exactly what you're getting at.
This seems smaller in footprint, but does it also win in runtime performance and stability?
To be honest, there's nothing inherently "wrong" with it. There are various techniques to implement templating engines and they all have pros and cons.
Lately, VDOM performance in micro benchmarks has sort of plateaued, and recently non-vdom systems like Svelte (an AOT compilation system) and Surplus (a KVO system) have been making some splash as potential candidates to surpass vdom performance. One could argue that it would be "wrong" or "a waste of time" to try to one-up template performance by attempting to make a new vdom implementation because existing ones are pretty much as optimized as they can be. Since there hasn't been nearly as much effort put into alternative algorithms, it probably would be more fruitful to explore a non-vdom approach instead.
Do note though that I'm talking about R&D sort of stuff above. For people building actual apps, vdom performance is generally good enough for a vast majority of real-world use cases (evidenced by React's popularity) and one of its appeals is that it lends itself to being manually optimizable it if you do end up with a ridiculously ginormous DOM.
Angular2+ team is actually have done an awesome job at experimenting in this problem space. And they've moved away from generating code that is similar to what Svelte does long time ago.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
https://news.ycombinator.com/newsguidelines.html
Be respectful. [...] Instead of "you're doing it wrong", suggest alternatives. [...] don't be gratuitously negative.
Woosh
I mean I can see the point you are trying to make, but it feels mildly disingenuous to link to this without explaining what you really mean.
Knock knock... blank page... <Ctrl>+<Shift>+<I>: "Uncaught TypeError: cannot read property 'a' of undefined."
I say this as someone whose entire job is writing "vanilla JS" without any sort of framework!
People do have a tendency to overdo tooling and lean too heavily on frameworks to get things done, but if you're building something without one you end up creating a lot of abstractions and boilerplate yourself to do anything relatively advanced and end up with a micro-framework of sorts at the end of the day, not unlike what was posted here! There's a lot of value in taking something small like this and building off of it.
Just linking to that vanilla JS site is snarky and unproductive.
https://nodejs.org/dist/v8.11.2/
Or 30 MB for the client side