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)
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.