Comment by spankalee | Hacker News Reader

Comment by spankalee | Hacker News Reader

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

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.

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.

Ah, I did misread your comment. What you describe is conceptually similar to Svelte's approach in the client, or even signals; keeping a reference directly to the node that used a certain value, though the client-side libraries have the luxury of keeping a pointer to the actual node.

With DOM state being thrown away, it would still not be possible to build as-you-type input validation for example. For SSR + streaming server updates I get the feeling it would also have limited utility, how do you track dependencies across more complex template conditions, loops? Is querying for comment markers any faster than traversing DOM elements? If using generated IDs, do you keep node IDs in memory for each user session in the server when dealing with dynamic content? Are you using an existing open source solution for this?

The DOM diffing/morphing approach is popular because it's in fact extremely fast to run, has small memory requirements, and is a low complexity implementation. In the SSR case, you don't need anything special on the server side, it can be completely ignorant of what is happening in the client. It's hard to beat.

It can be a mistake though to assume that the DOM hasn’t changed since it was rendered. Browser extensions, ad blockers and other JavaScript can modify the DOM.

I know it’s more expensive, but it’s like 1ms to render a document on the server and 3ms to morph it in the client. If you keep an SSE connection open, Brotli compression is very effective when you send almost the same HTML again and again.

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.

https://checkboxes.andersmurphy.com/

This has lots of client-side only use cases too!

See https://news.ycombinator.com/item?id=45941553

Reply on news.ycombinator.com