6 ms·

I made a better DOM morphing algorithm

96 points by joeldrapper 10mo ago

At least I think it’s better, but also I could also be missing something obvious.

cetinsert 10mo ago
Benchmarked Morhplex (this library) against diffHTML: https://dm.rt.ht/perf https://dm.rt.ht/perf Morphlex is 8→69× faster and 4× smaller!
sillysaurusx 10mo ago
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.
- nzoschke 10mo ago
  I’m doing agentic coding on a bunch of web apps and server side rendering HTML is so much easier than building APIs and React components. Full page reloads are fine for most CRUD cases. Then layering DOM morphing can be even better UX almost for free
- hatefulheart 10mo ago
  If you read the first 5 sentences of the article you’d see there are at least 3 popular front end libraries that do morphing. I think suggesting the world has settled on anything when it comes to technology is very silly. *Edit fixed typo.
- aatd86 10mo ago
  > 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)
  - harrisi 10mo ago
    jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library https://w3techs.com/technologies/overview/javascript_library
    - aatd86 10mo ago
      But if you compare google trends you will find that the crossover point of react vs jQuery was somewhere around 2018. In other terms, jQuery usage was much more widespread but it is not used for new projects anymore.
      - harrisi 10mo ago
        The trends of Google search doesn't imply anything by itself, just that less people search Google for jQuery than React. Which isn't entirely surprising in my view - people use search engines to learn about something they're unfamiliar with. That doesn't necessarily correlate with increased usage. I've searched for React (although not on Google) but never used it. It wouldn't be too much work to understand a bit more about the comparative usage. Looking at recent commits of projects on GitHub would be a good start, but also skewed towards open source projects which doesn't represent all actual usage of course. Another way would be to look through historic changes to websites to see if there's any changes to the source. It'd be a bit complicated because content changes don't necessarily mean anyone is touching jQuery or React pieces. This also ignores any sort of private usage, which you won't get any reliable data on, and may represent a significant amount of actual usage. At the end of the day, there's only so much accurate data available to make accurate conclusions about usage of software libraries that don't phone home. The best data available, as far as I'm concerned, is what I posted earlier - and it's still not perfect and doesn't support any claims other than what the data shows. As a side note, I don't have any dog in this race. I do think it's interesting to get a better understanding of what pieces of software are being used, by whom, in what amount, etc. but it's difficult.
        aatd86 10mo ago
        No, you see the trends. You see that people have been looking less and less for jQuery and more and more for React. But React hasn't reached the height of jQuery at its peak. It is the more reliable proxy.
- efortis 10mo ago
  Although the OP created it for SSR, these libraries are handy for SPAs as well. Rendering the whole DOM tree (instead of VDOMs) is a fast process. The slow part is attaching (committing) elements to the doc. e.g., I have a test of 20,000 elements which takes <30ms to render, while attaching them takes 120ms. Since the performance is mainly bound to the commit phase, libraries like these (and hopefuly a native API) help for creating simple UI frameworks. For example, a helper such as: function createElement(tag, props, ...children) { const elem = document.createElement(tag) for (const [k, v] of Object.entries(props || {})) if (k === 'ref') v.elem = elem else if (k === 'style') Object.assign(elem.style, v) else if (k.startsWith('on')) elem.addEventListener(k.slice(2).toLowerCase(), ...[v].flat()) else if (k in elem) elem[k] = v else elem.setAttribute(k, v) elem.append(...children.flat().filter(Boolean)) return elem } could be used, like: function ResetButton() { return ( r('button', { className: CSS.ResetButton, onClick: store.reset }, 'Reset')) } function render() { document.body.replaceChildren(App())) // but mergeChildren } Here's an example of using that helper: https://github.com/ericfortis/mockaton/blob/main/src/client/app.js https://github.com/ericfortis/mockaton/blob/main/src/client/...
- dmix 10mo ago
  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.
  - joeldrapper 10mo ago
    I enjoy writing mostly SSR apps with just a few specific Svelte components mounted as custom elements. It works really well.
- 65 10mo ago
  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 <template> 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.
  - fpsvogel 10mo ago
    Do you have an example of this technique that you can link to, or a fuller discussion of it? I have a soft spot for Alpine and I’m always on the lookout for things I can do with just Alpine.
- joeldrapper 10mo ago
  My specific use case was building a form where each change to an input would fetch a new copy of the form from the server and morph it in place. It means the server-side code can be really simple. You can make parts of the form depend on the values of other parts. For example you can show/hide a section based on a checkbox or fill a select with options based on a previous selection. Because it was a form, it was really important to maintain object identity and state perfectly so the user would not be interrupted.
rtcode_io 10mo ago
Can you see if you can support the input-to-output sync of the examples you see on https://rtcode.io https://rtcode.io ? Does your library support the new state-preserving moveBefore method?
- rtcode_io 10mo ago
  Sorry, I was excited to see something newer than diffHTML and asked questions before reading the full article! You do use moveBefore with lots of effort to match elements, which makes Morphlex a very interesting library to try! I will test your library extensively and update you via GitHub in case of questions/issues! Thank you for releasing Morphlex!
Uptrenda 10mo ago
Is there a website where we can try this out on?
- cetinsert 10mo ago
  There is one now! See https://dm.rt.ht 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.)
- cetinsert 10mo ago
  https://dm.rt.ht 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 https://github.com/yippee-fun/morphlex/issues/38 in my brief review of Morphlex.
dmix 10mo ago
I recently turned on View Morphing via upgrading Turbo 7->8 [1] in production and man it really does feel faster. Like a free performance upgrade. I looked it up on Github and they seem to be using the idiomorph package. [1] https://dev.37signals.com/turbo-8-released/ https://dev.37signals.com/turbo-8-released/
jdthedisciple 10mo ago
Wouldn't 'DOM Merging' be a more descriptive term?
- JSR_FDED 10mo ago
  The difference is that with morphing they take the trouble of maintaining focus, event listeners, etc.
- kevincox 10mo ago
  I don't think merging is an accurate term here. Merging makes me think you take the union of both. But in this case you have two DOM structures and want to make one exactly like the other. And morphing is a good term because you want to change it into the other, not just replace it.
spankalee 10mo ago
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.
- sudodevnull 10mo ago
  [flagged]
  - spankalee 10mo ago
    "Sit back down"? What kind of child are you?
    - 10mo ago
cetinsert 10mo ago
See https://dm.rt.ht 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+↓!
conartist6 10mo ago
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 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
- ricardobeat 10mo ago
  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.
  - conartist6 10mo ago
    The vdom idea isn't new to me but doing it with structural identity hashes is a bit different that what React does, no?
geon 10mo ago
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-react-node.test.tsx https://github.com/geon/react-node-diff/blob/main/src/diff-r...
- cetinsert 10mo ago
  See https://github.com/tbranyen/diffhtml?tab=readme-ov-file#features https://github.com/tbranyen/diffhtml?tab=readme-ov-file#feat...
- igor47 10mo ago
  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?
  - geon 10mo ago
    The server would keep a copy of the virtual dom during the session. Each change would be diffed and the diff sent to the client to apply. The client would only apply apply changes from the server, not change the dom on its own, so they wouldn’t get out of sync. I can render to html, but then I’d need to parse the html back do diff it. Seems stupid. I tried building a redux-style spa like that. Worked fine. https://github.com/geon/server-side-spa/tree/main/src/server https://github.com/geon/server-side-spa/tree/main/src/server
cetinsert 10mo ago
Filed my first issue https://github.com/yippee-fun/morphlex/issues/38 https://github.com/yippee-fun/morphlex/issues/38 with its own dedicated lite playground.
Nathanba 10mo ago
What I don't understand is why you don't just save your own id in memory on all those nodes? It's still not a virtual dom because there is no separate dom tree, you are still just walking the dom itself.
cetinsert 10mo ago
Fixed my first issue https://github.com/yippee-fun/morphlex/issues/38 https://github.com/yippee-fun/morphlex/issues/38
igor47 10mo ago
Super interesting, I'm just getting into DOM morphing libraries to try to patch around what I've found so far as the main limitation of the htmx approach: losing DOM on swaps. I started a discussion around some of the issues here: https://github.com/bigskysoftware/htmx/discussions/3501 https://github.com/bigskysoftware/htmx/discussions/3501 Someone proposed using ideomorph, but it doesn't seem to address the issues I've encountered. Curious if you think a different morphing approach would help?
- rtcode_io 10mo ago
  You can try Morphlex (this library) over at https://dm.rt.ht https://dm.rt.ht (DOM Morph RealTime HyperText)
incrudible 10mo ago
I don't understand the hate that SPAs get when these are the hoops people will ultimately jump through to render stuff on the server. Maybe you really do have an application at hand, not a "web page" (whatever that is in current year), and then you might as well use the SPA approach to implement it.
- joeldrapper 10mo ago
  I don’t hate SPAs, I just think some apps are better off being MPAs. I wouldn’t build a todo list app as an MPA. But many apps really are just CRUD forms and tables.
originofstorms 10mo ago
Hi! Idiomorph maintainer here. Congrats on the release! It's very, very cool to see how Morphlex is tackling some of the trickier subtleties of DOM morphing. We're in the R&D phase for the next version of Idiomorph, so its awesome to see how you're pushing things forward. I can see some overlap, like with `isEqualNode` (cheers to D* for cluing me into this API). But some of your ideas seem totally fresh, like your approach to solving the reordering problem. I'm looking forward to investigating whether any of these ideas would make sense in Idiomorph, and over all, I'm very pleased to see energy being put into making turn-key SSR more viable!
- joeldrapper 10mo ago
  Thank you so much. Please ping me if you have any questions about these techniques. I’m `joeldrapper` on Discord and GitHub.

96 points by joeldrapper 10mo ago

At least I think it’s better, but also I could also be missing something obvious.

Benchmarked Morhplex (this library) against diffHTML: https://dm.rt.ht/perf https://dm.rt.ht/perf Morphlex is 8→69× faster and 4× smaller!

sillysaurusx 10mo ago

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.

nzoschke 10mo ago
I’m doing agentic coding on a bunch of web apps and server side rendering HTML is so much easier than building APIs and React components. Full page reloads are fine for most CRUD cases. Then layering DOM morphing can be even better UX almost for free
hatefulheart 10mo ago
If you read the first 5 sentences of the article you’d see there are at least 3 popular front end libraries that do morphing. I think suggesting the world has settled on anything when it comes to technology is very silly. *Edit fixed typo.
aatd86 10mo ago
> 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)
- harrisi 10mo ago
  jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library https://w3techs.com/technologies/overview/javascript_library
  - aatd86 10mo ago
    But if you compare google trends you will find that the crossover point of react vs jQuery was somewhere around 2018. In other terms, jQuery usage was much more widespread but it is not used for new projects anymore.
    - harrisi 10mo ago
      The trends of Google search doesn't imply anything by itself, just that less people search Google for jQuery than React. Which isn't entirely surprising in my view - people use search engines to learn about something they're unfamiliar with. That doesn't necessarily correlate with increased usage. I've searched for React (although not on Google) but never used it. It wouldn't be too much work to understand a bit more about the comparative usage. Looking at recent commits of projects on GitHub would be a good start, but also skewed towards open source projects which doesn't represent all actual usage of course. Another way would be to look through historic changes to websites to see if there's any changes to the source. It'd be a bit complicated because content changes don't necessarily mean anyone is touching jQuery or React pieces. This also ignores any sort of private usage, which you won't get any reliable data on, and may represent a significant amount of actual usage. At the end of the day, there's only so much accurate data available to make accurate conclusions about usage of software libraries that don't phone home. The best data available, as far as I'm concerned, is what I posted earlier - and it's still not perfect and doesn't support any claims other than what the data shows. As a side note, I don't have any dog in this race. I do think it's interesting to get a better understanding of what pieces of software are being used, by whom, in what amount, etc. but it's difficult.
      - aatd86 10mo ago
        No, you see the trends. You see that people have been looking less and less for jQuery and more and more for React. But React hasn't reached the height of jQuery at its peak. It is the more reliable proxy.
efortis 10mo ago
Although the OP created it for SSR, these libraries are handy for SPAs as well. Rendering the whole DOM tree (instead of VDOMs) is a fast process. The slow part is attaching (committing) elements to the doc. e.g., I have a test of 20,000 elements which takes <30ms to render, while attaching them takes 120ms. Since the performance is mainly bound to the commit phase, libraries like these (and hopefuly a native API) help for creating simple UI frameworks. For example, a helper such as: function createElement(tag, props, ...children) { const elem = document.createElement(tag) for (const [k, v] of Object.entries(props || {})) if (k === 'ref') v.elem = elem else if (k === 'style') Object.assign(elem.style, v) else if (k.startsWith('on')) elem.addEventListener(k.slice(2).toLowerCase(), ...[v].flat()) else if (k in elem) elem[k] = v else elem.setAttribute(k, v) elem.append(...children.flat().filter(Boolean)) return elem } could be used, like: function ResetButton() { return ( r('button', { className: CSS.ResetButton, onClick: store.reset }, 'Reset')) } function render() { document.body.replaceChildren(App())) // but mergeChildren } Here's an example of using that helper: https://github.com/ericfortis/mockaton/blob/main/src/client/app.js https://github.com/ericfortis/mockaton/blob/main/src/client/...
dmix 10mo ago
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.
- joeldrapper 10mo ago
  I enjoy writing mostly SSR apps with just a few specific Svelte components mounted as custom elements. It works really well.
65 10mo ago
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 <template> 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.
- fpsvogel 10mo ago
  Do you have an example of this technique that you can link to, or a fuller discussion of it? I have a soft spot for Alpine and I’m always on the lookout for things I can do with just Alpine.
joeldrapper 10mo ago
My specific use case was building a form where each change to an input would fetch a new copy of the form from the server and morph it in place. It means the server-side code can be really simple. You can make parts of the form depend on the values of other parts. For example you can show/hide a section based on a checkbox or fill a select with options based on a previous selection. Because it was a form, it was really important to maintain object identity and state perfectly so the user would not be interrupted.

rtcode_io 10mo ago

Can you see if you can support the input-to-output sync of the examples you see on https://rtcode.io https://rtcode.io ? Does your library support the new state-preserving moveBefore method?

rtcode_io 10mo ago
Sorry, I was excited to see something newer than diffHTML and asked questions before reading the full article! You do use moveBefore with lots of effort to match elements, which makes Morphlex a very interesting library to try! I will test your library extensively and update you via GitHub in case of questions/issues! Thank you for releasing Morphlex!

Uptrenda 10mo ago

Is there a website where we can try this out on?

cetinsert 10mo ago
There is one now! See https://dm.rt.ht 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.)
cetinsert 10mo ago
https://dm.rt.ht 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 https://github.com/yippee-fun/morphlex/issues/38 in my brief review of Morphlex.

dmix 10mo ago

I recently turned on View Morphing via upgrading Turbo 7->8 [1] in production and man it really does feel faster. Like a free performance upgrade. I looked it up on Github and they seem to be using the idiomorph package. [1] https://dev.37signals.com/turbo-8-released/ https://dev.37signals.com/turbo-8-released/

jdthedisciple 10mo ago

Wouldn't 'DOM Merging' be a more descriptive term?

JSR_FDED 10mo ago
The difference is that with morphing they take the trouble of maintaining focus, event listeners, etc.
kevincox 10mo ago
I don't think merging is an accurate term here. Merging makes me think you take the union of both. But in this case you have two DOM structures and want to make one exactly like the other. And morphing is a good term because you want to change it into the other, not just replace it.

spankalee 10mo ago

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.

sudodevnull 10mo ago
[flagged]
- spankalee 10mo ago
  "Sit back down"? What kind of child are you?
  - 10mo ago

cetinsert 10mo ago

See https://dm.rt.ht 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+↓!

conartist6 10mo ago

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

ricardobeat 10mo ago
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.
- conartist6 10mo ago
  The vdom idea isn't new to me but doing it with structural identity hashes is a bit different that what React does, no?

geon 10mo ago

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-react-node.test.tsx https://github.com/geon/react-node-diff/blob/main/src/diff-r...

cetinsert 10mo ago
See https://github.com/tbranyen/diffhtml?tab=readme-ov-file#features https://github.com/tbranyen/diffhtml?tab=readme-ov-file#feat...
igor47 10mo ago
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?
- geon 10mo ago
  The server would keep a copy of the virtual dom during the session. Each change would be diffed and the diff sent to the client to apply. The client would only apply apply changes from the server, not change the dom on its own, so they wouldn’t get out of sync. I can render to html, but then I’d need to parse the html back do diff it. Seems stupid. I tried building a redux-style spa like that. Worked fine. https://github.com/geon/server-side-spa/tree/main/src/server https://github.com/geon/server-side-spa/tree/main/src/server

cetinsert 10mo ago

Filed my first issue https://github.com/yippee-fun/morphlex/issues/38 https://github.com/yippee-fun/morphlex/issues/38 with its own dedicated lite playground.

Nathanba 10mo ago

What I don't understand is why you don't just save your own id in memory on all those nodes? It's still not a virtual dom because there is no separate dom tree, you are still just walking the dom itself.

cetinsert 10mo ago

Fixed my first issue https://github.com/yippee-fun/morphlex/issues/38 https://github.com/yippee-fun/morphlex/issues/38

igor47 10mo ago

Super interesting, I'm just getting into DOM morphing libraries to try to patch around what I've found so far as the main limitation of the htmx approach: losing DOM on swaps. I started a discussion around some of the issues here: https://github.com/bigskysoftware/htmx/discussions/3501 https://github.com/bigskysoftware/htmx/discussions/3501 Someone proposed using ideomorph, but it doesn't seem to address the issues I've encountered. Curious if you think a different morphing approach would help?

rtcode_io 10mo ago
You can try Morphlex (this library) over at https://dm.rt.ht https://dm.rt.ht (DOM Morph RealTime HyperText)

incrudible 10mo ago

I don't understand the hate that SPAs get when these are the hoops people will ultimately jump through to render stuff on the server. Maybe you really do have an application at hand, not a "web page" (whatever that is in current year), and then you might as well use the SPA approach to implement it.

joeldrapper 10mo ago
I don’t hate SPAs, I just think some apps are better off being MPAs. I wouldn’t build a todo list app as an MPA. But many apps really are just CRUD forms and tables.

originofstorms 10mo ago

Hi! Idiomorph maintainer here. Congrats on the release! It's very, very cool to see how Morphlex is tackling some of the trickier subtleties of DOM morphing. We're in the R&D phase for the next version of Idiomorph, so its awesome to see how you're pushing things forward. I can see some overlap, like with `isEqualNode` (cheers to D* for cluing me into this API). But some of your ideas seem totally fresh, like your approach to solving the reordering problem. I'm looking forward to investigating whether any of these ideas would make sense in Idiomorph, and over all, I'm very pleased to see energy being put into making turn-key SSR more viable!

joeldrapper 10mo ago
Thank you so much. Please ping me if you have any questions about these techniques. I’m `joeldrapper` on Discord and GitHub.