Live data from Hacker News

Show HN: HyperApp – 1k JavaScript framework for building web applications

github.com

61–70 of 169 posts

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#61

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

> Nearly identical. lit-html uses ` `s and cloning, so that it doesn't have to do any expensive VDOM diffs. 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?

Highly recommended to watch https://youtu.be/Io6JjgckHbg

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#64
post #37

It's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/we...

hyperhtml - which this is based on, similar API - can be found at the left end of the table.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#65

Wow, there's an overwhelming total of 2 comments in the source file. The first indicates a constant value. The second lacks all context. Looks like typical JavaScript code.

This comment violates both the site guidelines ("Please don't post shallow dismissals, especially of other people's work.") and the Show HN guidelines: see "In Comments" in https://news.ycombinator.com/showhn.html.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#66

Another Virtual DOM thing - which is obviously wrong.

It's not ok to post like this to HN, and especially not in Show HN threads. Here are some of the rules it breaks:

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.

https://news.ycombinator.com/showhn.html

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#68

This makes me almost want to write web code again - compared to things like React and Angular 1-2-3-4-5-6.

Just curious what intrigues you about this framework in ways that React does not?

Also curious.. Wwat would you miss from React if you only used hyperapp?

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#69
post #50
post #19

This is an exceptionally simple library to use in place of React. Both its performance and the development experience have been great. My company's been using it in production for more than a year now without any issues. Highly recommend giving it a look.

Just out of curiosity, what was your use case that you deemed this a better option than react for?

We use Hyperapp to power our most complex UIs (decision trees, onboarding sequences, etc.). We didn't need any of the existing React ecosystem for that, and by removing React, we saw several benefits:

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.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#70

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

> ... expensive VDOM diffs 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.

It ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1].

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.

Post reply on HN