Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I made a better DOM morphing algorithm

joel.drapper.me

Post reply on HN
Print view View original

21–30 of 58 posts

Re: I made a better DOM morphing algorithm

#21

Post by ricardobeat »

conartist6 wrote: post #19

I'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 immu…

The novelty here is identifying nodes in a list more consistently vs existing options like morphdom. There is a ton of prior art you can draw from, this is called a virtual DOM and is the approach used by React and many contemporary libraries.

Re: I made a better DOM morphing algorithm

#22

Post by JSR_FDED »

sudodevnull wrote: post #18
spankalee wrote: post #14

I 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]

How about both of you show metrics so this becomes a fact based discussion?

Re: I made a better DOM morphing algorithm

#23

Post by ricardobeat »

spankalee wrote: post #14

I 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…

The reason simple identity is not "better", and the whole reason these libraries and React's virtual DOM exist, is that the DOM is stateful.

This approach works for simple stuff, until it doesn't. Form inputs will lose values, focus will be lost (ruining accessibility in the process), videos will restart, etc. You need the diffing to prevent unnecessary changes to the DOM. Even worse, in complex applications you easily end up in situations where the trivial approach causes vast swathes of the page to rerender at once, either because of unplanned dependencies or simply because you have three, seven or forty teams working on the site at the same time.

Re: I made a better DOM morphing algorithm

#25

Post by spankalee »

ricardobeat wrote: post #23
spankalee wrote: post #14

I 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…

The reason simple identity is not "better", and the whole reason these libraries and React's virtual DOM exist, is that the DOM is stateful . This approach works for simple stuff, until it doesn't. Form inputs will lose values, focus will be lost (ruining accessibility in the process), videos will restart, etc. You need the diffing to prevent unnecessary changes to the DOM. Even worse, in complex applications you eas…

I think you misunderstand what I'm saying. If the template identity is the same, you _don't_ replace the DOM - you just update the bound values in the template if necessary. If those are nested templates, you recurse and apply the same logic. This keeps the DOM stable when updating repeatedly from a template, even in very complex applications.

From experience, this works in apps like photo editors, video platforms, forums, app stores, home automation, application builders... It's just extremely rare to have two totally different templates with a shared element in them that you want to keep stable - the literally 99.9% case is that if the template identity changes, the DOM should be cleared.

Re: I made a better DOM morphing algorithm

#28

Post by cetinsert »

geon wrote: post #24

Is there a library that can work with JSX? I'd like to render JSX on the server and only send the diff to the client. I started writing some experimental code, but it was a lot of work. https://github.com/geon/react-node-diff/blob/main/src/diff-r...

See https://github.com/tbranyen/diffhtml?tab=readme-ov-file#feat...

Re: I made a better DOM morphing algorithm

#29

Post by 65 »

sillysaurusx wrote: post #2

I’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.

I've written SSR SPA frameworks with basic DOM "morphing" - e.g. I need to keep a sidebar from changing the HTML content/state when you click on a link, and I've always found advanced DOM morphing to be sketchy/bug prone and unnecessary.

The way I do it is to update everything _except_ for the DOM nodes that need to be excluded (via data attributes), e.g. the sidebar or a video player. I have found no problems with this approach as I maintain state since the JS is already running before clicking a link, and everything else is updated.

I think this is for if you absolutely have to SSR your markup at all times (e.g. using HTMX), but with something like Alpine.js and using elements, there is no reason to DOM morph.

And like you say, if you need to use crazy advanced DOM morphing, you should probably be using a client side framework anyway. If not, I've gotten away with some very tricky state updates with just Alpine.js.

Post reply on HN