Hyperapp: does hyperapp's virtual dom support keyed children?

[yelouafi]

Looked at the source (https://github.com/hyperapp/hyperapp/blob/master/src/app.js#L280-L284) and it seems like element's children are only patched by position.

[liadbiz]

@yelouafi yeah, not supported yet...
see also #129

[jorgebucaran]

@yelouafi Correct. I am not sure I can keep the 1kb promise if we implement keyed children too.

On the other hand, hyperapp 0.7.0 already performs "better" than React; this is a local run of js-framework-benchmarks up to date for 0.7.0.

All virtual DOM engines are basically fast.

Related:

• https://github.com/facebook/react/issues/1342#issuecomment-39230939

[zaceno]

This PR is not to support keyed children, but goes a bit of the way to solve the same problem:

https://github.com/hyperapp/hyperapp/pull/135

Specifically, it frees you a little from the positional-only updating of dom nodes, by letting you specify some elements that should be inserted, rather than replacing an existing dom node (in a potentially long chain of unnecessary dom operations)

[zaceno]

@jbucaran: gotta ask about the benchmark table: how did you make that (a tool I could download, or did you put it together yourself?) I thought it would be interesting to check the performance effects of using the _insert flag of PR 135.

[leeoniya]

@zaceno https://github.com/krausest/js-framework-benchmark

[zaceno]

Thanks @leeoniya!

[yelouafi]

@jbucaran
It's more about preserving identity. This can be an issue when you have state in the real DOM that's not in sync with virtual DOM (eg user input, focus, scroll position, animation ...). When you replace that node with a new one all that state goes away (which can lead to undesirable UI effects). Keys prevent this by letting the lib track when old stateful nodes has moved elsewhere.

[jorgebucaran]

Closing in favor of https://github.com/hyperapp/hyperapp/pull/141 🔥