[inhumantsar]

> the bulk of the interactivity of SPAs can be achieved via hypertext alone

except that with htmx the backend is supposed to return htmx markup, so now the hypertext is smeared between two systems. this lack of separation is the main thing holding me back from using it in any serious effort.

it feels like the "full stack dev" problem writ large. should my backend devs also be experts in front end? should my front end devs be digging into backend code? I'm a generalist myself but it's not reasonable to expect everyone to be a generalist, nor does it make good business sense.

then there's the backend-for-frontend argument, which the manager in me always reads as "we need to double the number of backend services". it's a bit hyperbolic but still.

[simonbarker87]

You should be using the same templates/partials/fragments/components that render in your initial page load as your responses to page updates.

So to render a table you render each row from a row component - then in response to updating a row in the table your backend end point returns the row component and then htmx swaps it out and rebinds everything.

Also, one big aim of htmx and this approach is to remerge the backend and frontend, like the old days.

This is the aim of HATEOS (hypermedia as the engine of state) and if you came up in web dev in the past 12 years or so then it’s going to feel very alien.

And honestly? Yes I think everyone should be a generalist otherwise you have just siloed your stack in away that increases both tech and business risk. Sure have someone who is an expert where needed but they should also be able to touch the full stack.

Be a T, broad and deep on one thing.

[sahil-kang]

If I was to tackle a simplified view of the problem I think you're describing: your frontend devs should provide the markup template the backend would interpolate and return

In the scenario you've alluded to, your backend devs are currently producing json data and your frontend devs are interpolating that into markup in the browser. In the simplest case then, your frontend devs would just provide a markup template that can be interpolated with the json already being produced. In slightly less simple cases, they can provide a function to be called instead

The gist is that the logic of taking data and producing markup should remain in the frontend dev's wheelhouse

[inhumantsar]

with JSON, frontend devs can ignore chunks of it, or work with the backend devs to modify the payload.

HTML, being a representation of a desired state rather than a neutral information exchange medium. is tricky to do that with. the frontend and backend devs would have to remain in lockstep with any changes made to the payload, ie the frontend and backend applications become tightly coupled.

I don't really see how having front end devs hand off a spec saying "we need this exact result format" is better than a loosely coupled result in a standard format

[_heimdall]

In a team where the backend devs can't work with the HTML templates for whatever reason, the frontend devs would be directly managing those.

I definitely wouldn't ask my frontend dev to write a spec and hand it to me to make their template, the spec spec would effectively have to be the template source code anyway. Just get in there and work with the HTML templates themselves.

[dartos]

The backend is expected to return html. HTMX is not a markup language