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

[aatd86]

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

jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library

[aatd86]

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]

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]

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.

[harrisi]

I would not be surprised if you're right in your assertion of what's used more for new projects. I still don't think the evidence you provided is enough to be so certain.

If I want to look up documentation for jQuery, I don't google the term "jquery" to find their docs. I just go straight to the docs directly. For a lot of situations, people's IDEs do enough work to not google something.

[efortis]

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

[dmix]

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]

I enjoy writing mostly SSR apps with just a few specific Svelte components mounted as custom elements. It works really well.

[nzoschke]

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

[65]

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]

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]

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.

[hatefulheart]

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.