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
  }

    function ResetButton() {
       return (
         r('button', {
           className: CSS.ResetButton,
           onClick: store.reset
         }, 'Reset'))
    }

    function render() {
      document.body.replaceChildren(App())) // but mergeChildren
    }

https://github.com/ericfortis/mockaton/blob/main/src/client/...

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

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.

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

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.

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.

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.

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

The difference is that with morphing they take the trouble of maintaining focus, event listeners, etc.

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!

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.

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

[flagged]

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.

There is one now!

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