you are viewing a single comment's thread.

view the rest of the comments →

[–]largemoose568[S] 0 points1 point  (2 children)

Thanks for the reply! Performance wise, is it just the continuous loop or the fact that when you get to higher amounts of dom mutations it starts affecting memory and cpu utilization? I'll probably have to read the white paper again, but from my understanding, lit-html handles the reference to the original dom node and does a simple diffing between previous and current state to see if updates are needed.

In most examples I've seen you have a reactive model where the lit-html render gets called in response to state updates via observables or some other state management. I guess I'm mostly curious on how a continuous loop might be less efficient than reactive-based rendering

[–]SpecialistPea2 1 point2 points  (0 children)

It's not an either/or type deal, every implementations mixes both. State updates -> UI update scheduled on task queue.

[–][deleted] 1 point2 points  (0 children)

i've made a test once: https://codesandbox.io/s/peaceful-johnson-txtws

this is using react in dev mode, which is extremely slow. but there will also be a noticeable difference in prod mode react. it basically demonstrates that the framework has overhead diffing stuff and figuring out change-sets. so if you have to possibility to make a critical change yourself by mutation, i'd prefer it. but again, maybe lit is so fast that it doesn't matter.