Fixed my first issue https://github.com/yippee-fun/morphlex/issues/38
I made a better DOM morphing algorithm
31–40 of 58 posts
Re: I made a better DOM morphing algorithm
#32Earlier quoted context omitted.
[flagged]
How about both of you show metrics so this becomes a fact based discussion?
Look at any Datastar demo, updates in microseconds above half RTT. Look at Andrew's demo above. We are actually working with Joel on possibly moving our already fastest approach to morphing to a version of his morphlex work. Actually try it and measure for yourself
Re: I made a better DOM morphing algorithm
#33Earlier quoted context omitted.
[flagged]
"Sit back down"? What kind of child are you?
So much misunderstanding of the details without actually trying it. I said clearly if you have metrics to back up claims great! Otherwise it's pure FUD which goes against actual metrics in the wild. Back up your assertions with actual code, that'd be great since you are so confident its 99% wrong.
Re: I made a better DOM morphing algorithm
#34Benchmarked Morhplex (this library) against diffHTML:
Morphlex is 8→69× faster and 4× smaller!
Re: I made a better DOM morphing algorithm
#35Is there a website where we can try this out on?
https://dm.rt.ht
The playground you asked for has already helped me file and fix a bug https://github.com/yippee-fun/morphlex/issues/38 in my brief review of Morphlex.
Re: I made a better DOM morphing algorithm
#36I’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.
> the world seems to have settled on using React. The world might have, but I personally have not!!! x( (I don't think the world really has, the same way the world moved on from jQuery at some point :) and jQuery was probably more widespread)
jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library
Re: I made a better DOM morphing algorithm
#37Earlier quoted context omitted.
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, f…
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.
Re: I made a better DOM morphing algorithm
#38I 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]
We already asked you barely more than a month ago to avoid posting flamewar style comments on HN. This is only a place where people want to participate because others make the effort to raise the standards, not drag them down. Please try to be one of the ones to make this place better not worse, otherwise find somewhere else that's more welcoming of that style of behaviour. https://news.ycombinator.com/newsguidelines.html
Re: I made a better DOM morphing algorithm
#39Re: I made a better DOM morphing algorithm
#40Is 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...
Wait but, don't you render the jsx to html? So you you can still perform the diff on the rendered html?
Also, how do you know what you rendered last time? When you do the diff between what's in the browser and what the server just gave you, you have both sides. If you do it server side, you could... Render twice, once before and once after the state change? Or keep a server side cache?