Wouldn't 'DOM Merging' be a more descriptive term?
I made a better DOM morphing algorithm
11–20 of 58 posts
Re: I made a better DOM morphing algorithm
#12I’m curious, what got you interested in solving this particular problem? I.e. what was your specific use case? Most websites work fine with plain html. If you need something fancier, the world seems to have settled on using React. I get that this is to let you render html on the backend and then stream it to the site so that JS can update the dom. But why? Genuine question; I’m not saying there’s no good reason.
Both Elixir Phoenix and Ruby on Rails use plain HTML by default but they both support view morphing (phoenix via LiveView and rails via Hotwire Turbo). It really doesn't cost anything to add it. Clicking links with a bit of caching can make it feel near instant the way a (small) SPA does. Adding link prefetching algo on top of the that and it will seem even faster.
If anything it removes a ton of the argument for using React absent maybe a small subset of highly complex UI subcomponents which may need it, but rarely required for a whole SaaS app. Frontend teams just want React so they can use a single tool not because it's the best solution.
Re: I made a better DOM morphing algorithm
#13Is there a website where we can try this out on?
There is one now!
See https://dm.rt.ht
Just updated to demonstrate what `moveBefore()` brings to the table!!
Try moving the clock.gif line up/down with Alt+↑ and Alt+↓!
(it is very nascent, and I am on a plane with shaky Wi-Fi, so I will give it the love it deserves in a couple of days: compare all libraries with each other, add a benchmark, etc.)
Re: I made a better DOM morphing algorithm
#14I really have questions about this, for two reasons:
1. Coming from a client-side rendering perspective, DOM morphing/diffing is 99% of the time a bad idea, except in the case of reordering a list of keyed items where you can use a simpler, more specialized algorithm.
It's much better to use template identity to compare the source template of the current DOM with the source template of the incoming DOM (or description of DOM) and completely re-render if the source template changed. It's a very simple and fast check, and nearly all the time you change templates you want new DOM state anyway.
This technique works with SSR'ed HTML as well. You leave marker comments in the HTML that bracket the nodes created from a template and carry with them a template ID (e.g. a hash of the template). When updating the DOM, as you traverse the template instance tree, you check IDs and replace or update in-place as needed. Again, simple and fast.
2. But... If you're morphing the existing DOM, this seems to eliminate many of the benefits of sending HTML in your server responses in the first place. The HTML is just data at that point - you parse it only to crawl it as a set of instructions for updating the DOM.
HTML is an expensive way to do this. It's a larger format and slower to parse than JSON, and then you have to do this diffing. You'd be better off doing client-side rendering if possible. Data + templates is usually a very compressed format compared to the already expanded HTML you get from rendering the templates client-side.
And if the reason to morph is to keep things like event listeners, templates would let you attach those to the new DOM as well as preserve them in the unchanged DOM. With DOM morphing you need a way to go set things up on the new DOM anyway.
...
The big advantage of this is the architectural simplicity of only ever returning HTML from the server, as opposed to HTML for first render and data for updates, but it's not going to have good network and rendering perf compared to CSR for updates.
Re: I made a better DOM morphing algorithm
#15See https://dm.rt.ht - a playground for this library!
To see `moveBefore()` in action:
try moving the clock.gif line up/down with Alt+↑ and Alt+↓!
Re: I made a better DOM morphing algorithm
#16I really have questions about this, for two reasons: 1. Coming from a client-side rendering perspective, DOM morphing/diffing is 99% of the time a bad idea, except in the case of reordering a list of keyed items where you can use a simpler, more specialized algorithm. It's much better to use template identity to compare the source template of the current DOM with the source template of the incoming DOM (or descriptio…
This has lots of client-side only use cases too!
Re: I made a better DOM morphing algorithm
#17I really have questions about this, for two reasons: 1. Coming from a client-side rendering perspective, DOM morphing/diffing is 99% of the time a bad idea, except in the case of reordering a list of keyed items where you can use a simpler, more specialized algorithm. It's much better to use template identity to compare the source template of the current DOM with the source template of the incoming DOM (or descriptio…
This garbage demo uses a morphing library (Datastar which may switch to using morplex in future) to morph in around 12k divs per frame on any change by any user.
The event listener part is easy use a top level event handler and bubble up events.
The network part is also easy brotli compression over an SSE stream. Even though this demo returns around 180kb per frame uncompressed, a single check between frames will compress to 13bytes on the wire.
Re: I made a better DOM morphing algorithm
#18I really have questions about this, for two reasons: 1. Coming from a client-side rendering perspective, DOM morphing/diffing is 99% of the time a bad idea, except in the case of reordering a list of keyed items where you can use a simpler, more specialized algorithm. It's much better to use template identity to compare the source template of the current DOM with the source template of the incoming DOM (or descriptio…
[flagged]
Re: I made a better DOM morphing algorithm
#19I'm very interested in this!
I've been working on some prototypes for possible immutable DOM APIs and though I haven't gotten that far in experimenting with it I've been expecting to encounter the same problem that this library is designed to solve: in my system the DOM will be represented as a deeply immutable tree of JS objects, arrays, and such, so a state update might consist of being given references to two immutable trees, the current state and the desired state, and from there you need to compute a minimal set of changes so that you don't redo layout and drawing work that doesn't need to be redone for parts of the DOM that are unchanged. This sounds like exactly the algorithm you'd want to do that! So basically it could allow me to use the immutable DOM representation as the source of truth and then diff and sync the new state onto the mutable DOM
Re: I made a better DOM morphing algorithm
#20I really have questions about this, for two reasons: 1. Coming from a client-side rendering perspective, DOM morphing/diffing is 99% of the time a bad idea, except in the case of reordering a list of keyed items where you can use a simpler, more specialized algorithm. It's much better to use template identity to compare the source template of the current DOM with the source template of the incoming DOM (or descriptio…
[flagged]
"Sit back down"? What kind of child are you?