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)

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

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.

Full page reloads are fine for most CRUD cases. Then layering DOM morphing can be even better UX almost for free

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.

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.

*Edit fixed typo.

(DOM Morph RealTime HyperText)

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?