Hyperapp: Effort for lit-html

[wesleycoder]

First of all I should say I've looked at the API and I think it looks awesomelly promising.
I'll play with it for a bit in some little personal projects and I think it has huge potential to soon become my lib of choice for some large projects in the future.

But I definitelly couldn't stop thinking that hyperapp (with ~1kb) united with lit-html (with ~1.7kb) in the near future would be one of the best performant choices with the minimal API surface to absorb.

Would be possible to measure the effort to use lit-html with hyperapp?

Any directions for a starting point on how could this be done?

[selfup]

So it seems that lit-html does not build a VDOM no-vdom-overhead.

We can use something similar to lit-html like hyperx: https://github.com/choojs/hyperx

Or we can also use t7: https://github.com/trueadm/t7

These use tagged template literals similar to lit-html but result in proper h pragmas that Hyperapp can then work with.

Are you saying you want to use Hyperapp as a state management mechanism but use lit-html for the view logic? Or do you want to use tagged template literals for composing your views inside of Hyperapp?

I know that @JorgeBucaran can help with this.

Also @andyrj has built a nice Proxy lib for state with his own mix of lit-html _inspired_ libs.

[wesleycoder]

Are you saying you want to use Hyperapp as a state management mechanism but use lit-html for the view logic? Or do you want to use tagged template literals for composing your views inside of Hyperapp?

My idea was boost up performance having Hyperapp as the state management mechanism and use lit-html for the view rendering. That's because lit-html doesn't build a VDOM having less performance cost per node as with other engines like virtual-dom, react or hyperscript.

That won't stop me from using Hyperapp, but I'm excited to think how awesome would be to build high performant apps with these two tiny libs.

[selfup]

Ohh ok I see what you mean! Yea HA can totally be used just for state management 👍

@Swizz knows more on creating VDOMless hyperapps

[leeoniya]

@wescoder do you have any perf numbers for lit-html's keyed updates? the only version submitted here [1] is non-keyed. it does appear that the lit-html supports keys in loops [2]. would be good to get some insight.

[1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
[2] https://github.com/PolymerLabs/lit-html#repeatitems-keyfn-template

[wesleycoder]

@leeoniya I didn't made any benchmark comparisons between hyperapp and lit-html, but I think it would be easy to get the perf numbers by adding a test based on the non-keyed, but changing this lines to use the repeat(items, keyfn, template) function from lit-html (maybe make a PR after).

[leeoniya]

That's because lit-html doesn't build a VDOM having less performance cost per node as with other engines like virtual-dom, react or hyperscript.

this is a claim that keeps being made by non-vdom libraries, library users and various blog posts, but the fastest libs continue to be those based on vdom. these claims of "fast because no vdom" have never been proven except against shitty vdom implementations of 2 years ago.

[wesleycoder]

this is a claim that keeps being made by non-vdom libraries, library users and various blog posts, but the fastest libs continue to be those based on vdom. these claims of "fast because no vdom" have never been proven except against shitty vdom implementations of 2 years ago.

This can be just a "marketing" claim, but think that limiting the use of HA to vdom only is not a thing that would be a sane decision to take deliberately.
I'm not in favor or against vdom usage, I use hyper-html, preact and react and I like them a lot.

I also personally think that the direction that lit-html tries to take is more future prone by relying on the platform (web) instead of abstracting the job the browser already does like vdom. But again performance is not the only point I try to bring to HA.

This issue was started with the spirit of openness and the intuit to bring more flexibility for its usage.

The intent here is not to start a war about performance between vdom and non-vdom libs, but instead bring more value to HA.

[jorgebucaran]

Hi @wescoder! I think it would be interesting to experiment removing Hyperapp's built-in VDOM and replacing it with lit-html's similar DOM manipulating/updating system, but without changing the surface API. If you want to play with this, I'd be happy to help. I'd recommend you hop on Slack to discuss the details.

However, I am not interested in having both libraries work together. I want to use only hyperapp or only lit-html, but not both.

[selfup]

So currently if you do not pass a container (Node/Element) to HA it does not render to the DOM 🎉

You could use exposed actions to change state from lit-html!

Or just use the state and actions given to you in your view 🤔

As you can see however, just depending on exposed actions will only return the return value of said action. It won't include the entire state.

So now I guess you would load hyperapp with a blank view and have some lit-html rendering logic in the view itself? Like:

<div>
  {
    /* since here you will have access to the entire state tree */
    /* write your render calls here */
  }
</div>

Either way, feel free to experiment and let us know what you discover 😄 👍

[wesleycoder]

@selfup @JorgeBucaran
That's the feedback I was hoping to get here! :smile: :+1:
I'll definitely play with what @selfup suggested and return here and in Slack with my findings.
If my results prove to be successful I'll definitely work on a PR or maybe a "plugin-like" lib for hooking lit-html on HA.

[selfup]

@wescoder Glad that helped! 🙏