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

1–10 of 58 posts

Re: I made a better DOM morphing algorithm

#2

Post by sillysaurusx »

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.

Re: I made a better DOM morphing algorithm

#4

Post by rtcode_io »

rtcode_io wrote: post #3

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

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!

Re: I made a better DOM morphing algorithm

#5

Post by nzoschke »

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

Re: I made a better DOM morphing algorithm

#7

Post by hatefulheart »

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.

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.

Re: I made a better DOM morphing algorithm

#8

Post by aatd86 »

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.

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

Re: I made a better DOM morphing algorithm

#9

Post by efortis »

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.

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

Post reply on HN