morphdom VS diffhtml

morphdom

And sure enough, it works! So what's going on here? Well, clicking the link invokes our reflex, which gets executed right before our current controller action runs again. It allows us to execute any kind of server-side logic, as well as play with the DOM in various ways, but with ruby code. Then, the DOM gets morphed over the wire.

It's super simple actually. And that is in large part to (Morphdom)[https://github.com/patrick-steele-idem/morphdom] which I'm using to compare the output of render() to what is already on the DOM. Morphdom will patch the differences.

I'm using morphdom to patch our DOM. Its a very simple library that compares two DOM elements and updates only the differences. It is extremely performant and does not even use a Virtual DOM, just the DOM you already have!

using HTML-diffing libraries like morphdom to efficiently update elements on the page

no it actually looks like morphdom is what i'm looking for.

It tries to morph into existing DOM (with https://github.com/patrick-steele-idem/morphdom). In case of fail, there is fallback to HTML replacement with outerHTML. All DOM operations after action occurs on component level, not the whole page.

Today, we’re going to build a live search experience once more. This time with StimulusReflex, a “new way to craft modern, reactive web interface with Ruby on Rails”. StimulusReflex relies on WebSockets to pass events from the browser to Rails, and back again, and uses morphdom to make efficient updates on the client-side.

Whenever the JavaScript on the browser-side receives new HTML, it will update the current page using a DOM-diff approach (using morphdom). So only DOM nodes that have actually changed between the initial page load and the updated HTML will be updated.

Updating the DOM is not slow. In fact, there are libraries and frameworks that emphatically reject the virtual dom approach. morphdom is one such example of a DOM modification library. Svelte's author Rich Harris has been proclaiming for a while that virtual dom is an overhead (see e.g. this article). Google's lit-html and lit-element do much of what react does without the virtual dom.

diffhtml

Hi floodfx, we should chat at some point if you're on slack/discord/etc. I'm building something extremely similar and there's potential opportunity to share some code/learnings. Personally I feel this design paradigm is the real web 3.0.

My project is https://diffhtml.org/ and I have started experimenting with middleware to bridge to server and client workers: https://github.com/tbranyen/diffhtml/pull/251. For the server worker, it uses a WebSocket to ferry the VDOM diff patches, custom events, and property access/function calls. A big goal is to allow synchronous "main thread" access from workers, including on the server-side. This would allow you to write your UI code as if you were a client side app. It does this the same way as partytown using a SharedArrayBuffer and Atomics. You can see demo source code here: https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13....

I've also toyed around with hot reloading components without the need for a pre-processor like Babel, and the results are hugely promising. Stateful live UI updates from saving a component file to seeing in the browser without all the fuss with complex build steps is liberating.

I'm probably a few months out from having a usable beta, but I'm going to follow your project closely. Thanks for sharing!

I suggested one such idea (a diffing version of innerHTML) years ago to Mozilla. Ironically, the React team was against it and it fizzled out. In more ironic twists of events, someone eventually wrote a JS implementation of it: https://github.com/tbranyen/diffhtml/tree/master/packages/di... and nowadays people are talking about HTML-based rendering engines again, making this idea somewhat relevant once more.

To be fair to standards bodies, they have done some work. Element.append now exists to make hyperscripts a bit more straightforward, and a lot of reactivity semantics can be implemented on top of Proxy.