Comment by gwd | Hacker News Reader

Comment by gwd | Hacker News Reader

I feel like this would have been a bit better with some sort of "recap" at the end, to summarize where he got to. The README on the MESH page is a good summary:

> MESH is a fun project intending to demonstrate the kinds of concepts embodied by HTMX - without using HTMX. Specifically, we're rendering modular elements on the server, and hydrating them on the client, swapping them out as needed instead of reloading the whole page. Component updates are swapped in place. Out-of-band updates are sent to all connected clients via SSE (server-side events), meaning all users see updates in real time.

(To expand that for people not familiar with HTMX's out-of-band updates: Basically, in MESH, on the client you hook up something listening to updates sent from the server via SSE. What the server sends are basically snippets of HTML with an ID in them; the listener on the client replaces the HTML in the DOM with that ID with the HTML sent over the wire. This allows the server to arbitrarily update the client's UI.)

So it shares one of the mechanisms of HTMX, which is to do SSR with the ability to replace individual elements.

The concept of MESH sits somewhere between course grain components and server islands.

React is for fine grain components and HTMX is for lightweight interactivity — update part of a page.

The classic React use case is an editable, filterable drop down. The classic HTMX use case is click a button and load some text.

The overlap comes in the middle, with a simple form validation. React says make each field a component that handles its own validation and error messages. HTMX says just return a re-rendered form with the error messages. MESH says make the form a component with its own endpoint.

> HTMX says just return a re-rendered form with the error messages. MESH says make the form a component with its own endpoint.

HTMX can do the same thing: you can do `hx-trigger="changed delay:500ms"`, and make an endpoint for that component that will do validation, update an error message status area (adding or removing an error as appropriate), and even potentially enable / disable the "submit" button.

It seems to me that the main difference in approach is whether the "source of truth" for the state of the page is on the client or the server. HTMX is designed to be flexible (which is one of TFA's complaints actually), but its primary vision is HATEOAS (Hypertext as the Engine of Application State); which to my understanding of reading HTMX's documentation, is meant to mean that everything important about the client state should be kept on the client; the server should be able to be entirely reactive. What I see skimming through MESH (and data-star.dev) is that the "source of truth" is on the server.

Not an authority in this area, so happy to be corrected on all those points. But I am in the middle of building a dynamic query form using HTMX, trying to design it with HATEOAS principles, so it is something fresh in my mind at any rate.

> but its primary vision is HATEOAS (Hypertext as the Engine of Application State); which to my understanding of reading HTMX's documentation, is meant to mean that everything important about the client state should be kept on the client; the server should be able to be entirely reactive. What I see skimming through MESH (and data-star.dev) is that the "source of truth" is on the server.

Well, the thing about HATEOAS is that it's REST, REpresentational State Transfer. And nothing in REST says "you should store client state on the client". You store state where it's convenient (in reality, mostly on the server for lightweight interactive apps, mostly on the client for SPA-like apps), and exchange representations of it between the server and the client (as long as both understand the data format being exchanged)

Reply on news.ycombinator.com