[HN Gopher] Show HN: I made a better DOM morphing algorithm
___________________________________________________________________
Show HN: I made a better DOM morphing algorithm
At least I think it's better, but also I could also be missing
something obvious.
Author : joeldrapper
Score : 31 points
Date : 2025-11-07 12:02 UTC (8 days ago)
(HTM) web link (joel.drapper.me)
(TXT) w3m dump (joel.drapper.me)
| sillysaurusx wrote:
| 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.
| nzoschke wrote:
| 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
| hatefulheart wrote:
| 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.
| aatd86 wrote:
| > 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)
| efortis wrote:
| 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, with 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
| }, t`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/...
| rtcode_io wrote:
| 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?
| rtcode_io wrote:
| 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!
| Uptrenda wrote:
| Is there a website where we can try this out on?
___________________________________________________________________
(page generated 2025-11-15 23:00 UTC)