Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I made a better DOM morphing algorithm

joel.drapper.me

Post reply on HN
Print view View original

51–58 of 58 posts

Re: I made a better DOM morphing algorithm

#51

Post by aatd86 »

harrisi wrote: post #50
aatd86 wrote: post #46

Earlier quoted context omitted.

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.

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…

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.

Re: I made a better DOM morphing algorithm

#52

Post by harrisi »

aatd86 wrote: post #51
harrisi wrote: post #50

Earlier quoted context omitted.

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…

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.

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.

Re: I made a better DOM morphing algorithm

#53

Post by aatd86 »

harrisi wrote: post #52
aatd86 wrote: post #51

Earlier quoted context omitted.

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.

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.

But that wouldn't still explain why searches for the term has decreased. Besides, people in general do look up to the online documentation or links to the documentation from stack overflow.

Seems pretty obvious looking at the graph: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

Re: I made a better DOM morphing algorithm

#54

Post by joeldrapper »

sillysaurusx wrote: post #2

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.

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.

Re: I made a better DOM morphing algorithm

#55

Post by joeldrapper »

dmix wrote: post #12
sillysaurusx wrote: post #2

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.

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 usi…

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

Re: I made a better DOM morphing algorithm

#56

Post by joeldrapper »

originofstorms wrote: post #48

Hi! Idiomorph maintainer here. Congrats on the release! It's very, very cool to see how Morphlex is tackling some of the trickier subtleties of DOM morphing. We're in the R&D phase for the next version of Idiomorph, so its awesome to see how you're pushing things forward. I can see some overlap, like with `isEqualNode` (cheers to D* for cluing me into this API). But some of your ideas seem totally fresh, like your ap…

Thank you so much. Please ping me if you have any questions about these techniques. I’m `joeldrapper` on Discord and GitHub.

Re: I made a better DOM morphing algorithm

#57

Post by joeldrapper »

incrudible wrote: post #47

I don't understand the hate that SPAs get when these are the hoops people will ultimately jump through to render stuff on the server. Maybe you really do have an application at hand, not a "web page" (whatever that is in current year), and then you might as well use the SPA approach to implement it.

I don’t hate SPAs, I just think some apps are better off being MPAs. I wouldn’t build a todo list app as an MPA. But many apps really are just CRUD forms and tables.

Re: I made a better DOM morphing algorithm

#58

Post by joeldrapper »

spankalee wrote: post #25
ricardobeat wrote: post #23

Earlier quoted context omitted.

The reason simple identity is not "better", and the whole reason these libraries and React's virtual DOM exist, is that the DOM is stateful . 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 eas…

I think you misunderstand what I'm saying. If the template identity is the same, you _don't_ replace the DOM - you just update the bound values in the template if necessary. If those are nested templates, you recurse and apply the same logic. This keeps the DOM stable when updating repeatedly from a template, even in very complex applications. From experience, this works in apps like photo editors, video platforms, f…

It can be a mistake though to assume that the DOM hasn’t changed since it was rendered. Browser extensions, ad blockers and other JavaScript can modify the DOM.

I know it’s more expensive, but it’s like 1ms to render a document on the server and 3ms to morph it in the client. If you keep an SSE connection open, Brotli compression is very effective when you send almost the same HTML again and again.

Post reply on HN