Hi, I played with kvdom a bit and it works pretty ...

# kmdc

[rnentjes]

Hi, I played with kvdom a bit and it works pretty good. I notice that wasm vs js doesn't seem to make much difference with regards to performance. @Big Chungus did you do any comparisons on that yet?

Some remarks:
• It seems to me that adding hashes to the nodes could improve update performance a lot.
• If you have hashes it's also easier to detects inserts and removal of children so you only add/remove those
The next step is probably something with components, is that something you want to do with this?

[Big Chungus]

Class based components are planned for M3

[Big Chungus]

In terms of performance, WASM is waaay slower than js due to slow js interop, so this is essentially a prep for when wasm will get direct access to dom.

[Big Chungus]

Forwarded some of my findings in terms of performance from the other threads

[Big Chungus]

Also I'd be interested in seeing what you've created with kvdom :)

[Big Chungus]

Maybe even adding it to samples as current one is very basic

[Big Chungus]

And finally, I'm not familiar with how node hashing can help diffing, could you elaborate on that?

[Big Chungus]

What I'm long overdue is benchmarking comparison with snabbdom as kvdom is heavily inspired by it, so it should at least be as performant as snabbdom

[Big Chungus]

P.S. Thanks for the feedback

[Big Chungus]

The main issues I had with hashes were event handlers, since in kotlin, two identical lambdas will always return different hashes unless they are the same reference. E.g.
val x = {}
val y = {}
x != y
val z = y
z == y

[rnentjes]

Yeah, I have encountered that problem as well. I think you can either say that events should not change dynamically (put the logic in the event handler, not in the layout). Or you have to update all events always anyway.

In my attempts to do something like this I kept track of the types of events on the node. This way adding and removing event types updates the hash. Only changing a listener doesn't (so that's not supported). And I actually stored the events separately on the dom node so I could remove them using the original reference.

I am not sure yet what the best approach is. Maybe the best trade-off here is so linked to the actual application that this shouldn't be a library.

[rnentjes]

I just played around with the example, so I don't have anything to show you. I'll let you know if I will use it for anything.

[Big Chungus]

Hmm, currently events are wrapped in a single handler that's preserved during diffing and just switched to point to another set of actual handlers, so your proposal would work. Definitely something to explore here, probably for the next version.

[Big Chungus]

Here's an Issue for tracking

[rnentjes]

Btw, this is my own library I use now:

https://github.com/rnentjes/komponent

This started as a simple wrapper around kotlinx-html based on just replacing everything on update, so that's why I am interested in a virtual dom diffing algorithm.

[Big Chungus]

Looks like kvdom can certainly help you here. There's also kotlin-snabbdom

[Big Chungus]

And if you're looking for a full blown kotlin web framework, check out #kvision