41–50 of 58 posts
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?
Super interesting, I'm just getting into DOM morphing libraries to try to patch around what I've found so far as the main limitation of the htmx approach: losing DOM on swaps. I started a discussion around some of the issues here: https://github.com/bigskysoftware/htmx/discussions/3501 Someone proposed using ideomorph, but it doesn't seem to address the issues I've encountered. Curious if you think a different morphi…
(DOM Morph RealTime HyperText)
Is there a library that can work with JSX? I'd like to render JSX on the server and only send the diff to the client. I started writing some experimental code, but it was a lot of work. https://github.com/geon/react-node-diff/blob/main/src/diff-r...
Wait but, don't you render the jsx to html? So you you can still perform the diff on the rendered html? 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'm very interested in this! 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 immu…
The novelty here is identifying nodes in a list more consistently vs existing options like morphdom. There is a ton of prior art you can draw from, this is called a virtual DOM and is the approach used by React and many contemporary libraries.
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.
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 t…
I have a soft spot for Alpine and I’m always on the lookout for things I can do with just Alpine.
Earlier quoted context omitted.
> 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)
jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library
Wouldn't 'DOM Merging' be a more descriptive term?
Earlier quoted context omitted.
jQuery is used far more than React. https://w3techs.com/technologies/overview/javascript_library
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.
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.