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 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.
I have a soft spot for Alpine and I’m always on the lookout for things I can do with just Alpine.
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.
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?
(DOM Morph RealTime HyperText)
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
https://github.com/geon/react-node-diff/blob/main/src/diff-r...
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?
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
I looked it up on Github and they seem to be using the idiomorph package.
Does your library support the new state-preserving moveBefore method?
I will test your library extensively and update you via GitHub in case of questions/issues!
Thank you for releasing Morphlex!
To see `moveBefore()` in action:
try moving the clock.gif line up/down with Alt+↑ and Alt+↓!
Morphlex is 8→69× faster and 4× smaller!
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.
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.)
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.
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.
From experience, this works in apps like photo editors, video platforms, forums, app stores, home automation, application builders... It's just extremely rare to have two totally different templates with a shared element in them that you want to keep stable - the literally 99.9% case is that if the template identity changes, the DOM should be cleared.
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.