Majin Buu as Render Engine #100
Conversation
Based on Levenshtein distance, Majin Buu can transform any collection of nodes into a new collection. It's not by accident that it plays so well with node lists that from a shape would like to become another, performing the least amount of DOM operations.
|
this would fix #98 too |
|
|
|
So this is virtual DOM now? maybe I'm misunderstanding |
|
@pinguxx it isn't, in the sense that hyperHTML doesn't retain a virtual copy of the DOM in memory, which is what VirtualDOM is about. Majin Buu is a simple Levenshtein distance calculator, which is not Virtual DOM, with the ability to retrieve all optimal needed steps to transform List1 to List2. Being JavaScript reference a no-brainer for memory, meaning that if you hold the same thing in various array the cost is not The Levenshtein distance is calculated at close to C performance once, and the amount of operations per DOM node to Yet, not a single abstract, virtual, representation of the DOM is held in memory. |
|
got it, awesome stuff |
hyperhtml.js
Outdated
| // changes needed to show the a new list | ||
| // where there was another one. | ||
| // There is a limit, in terms of performance, | ||
| // on how bug can the optimal computation be, |
test/infinite.html
Outdated
| }, {once: true}); | ||
| </script> | ||
| <style> | ||
| htm, body { |
There was a problem hiding this comment.
a typo in a comment and an error in CSS ... I feel like I'm good at JS 🤣
Thanks, will push new stuff tomorrow !
WebReflection
force-pushed
the
majinbuu
branch
from
6124f63 to
3ff7b77
Compare
latest majinbuu
WebReflection
force-pushed
the
majinbuu
branch
from
f18b754 to
9cf4ad8
Compare
| @@ -334,14 +341,15 @@ tressa.async(function (done) { | |||
| tressa.assert(div.firstChild.firstChild === br, 'one child is added'); | |||
| hyperHTML.bind(div)(_templateObject14, hr); | |||
| tressa.assert(div.firstChild.firstChild === hr, 'one child is changed'); | |||
| debugger; | |||
I have done various tests and created a new demo that shows and proves reason behind this choice.
There is no algorithm whatsoever in hyperHTML when it comes to list of wires or DOM elements.
Until now, it has always been about unpredictable update performance if the list was similar up to a certain index or, in some case, considered fully different if just the first item was not.
This doesn't scale with any sort of big layout, infinite scrolling, pull to refresh, and you can name it story.
The goal of Majin Buu is to put an end to this madness.
It's so fast and efficient, that diverging from
anycontent tovirtualcontent doesn't make sense anymore: everything is virtual and handled as list without actually penalizing performance at all.However, there are O(x*y) use cases that might be too big to compute, which is why there is now an exposed flag called
hyperHTML.MAX_LIST_SIZEwhere if the square root of the Levenshtein grid is bigger than such value, the DOM will simply cleanup the list and append all new nodes.However, this is fully handled now by
.spliceoperations, fully optimized by Majin Buu and invoked through its aura.I'll leave it here for a couple of days in case somebody would like to try and/or raise questions, but I'm looking forward to have this Majin Buu release of hyperHTML which will also change the way viperHTML produces output, simplifying for the future and making absolutely reliable any adoption from the backend.
Thanks for thoughts, if any.