Hacker News Reader

Comment by sahil-kang | Hacker News Reader

If I understand correctly, the main selling point of htmx is that _html_ is extended with the attributes from GP: the idea being that a bulk of the interactivity of SPAs can be achieved via hypertext alone

I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"

View on HN

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

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

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

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.

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.

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

Which begs the question: Why mix logic with templates?

htmx mixes logic with "templates" in the same manner that HTML mixes logic with templates: hypermedia control information is embedded in the hypermedia in the form of attributes

Maybe I should clarify the type of logic I mean. Standard HTML contains instructions for how content should be rendered. But it has no control flow structures to control what content should be rendered.

Embedding loops and if/else logic in htmx tags creates scenarios where the content is potentially modified in the rendering step, meaning you can't rely on just looking at the data the backend sent over the wire to determine the source of a result that renders incorrectly. Instead of having control flow in one place, and a single source of truth, it creates an additional point of failure.

Stock price showing up wrong? That might now be a problem in your backend logic or in your complex htmx engine, buried in some template tag.

I think this htmx essay [1] addresses the tradeoffs you may be getting at if you're thinking "why html vs js+json": the gist is that html is self-describing to the browser, so the backend can make changes to the html it produces and the browser will understand it without the frontend code needing to be updated

If you're instead thinking more broadly in terms of "structure vs layout", I think the same reasoning for using something like tailwind css or higher-level web components may apply: i.e. the material you interact with is closer to your problem domain

[1] https://htmx.org/essays/two-approaches-to-decoupling/

You don't need to mix logic with templates. I just produce a context (result from database queries and some such) and pass it to a function that produces HTML from the data in the context. The data must not be changed in the templating function. This is something I try to avoid as well in order to maintain separation of concerns in the backend code.

Edit for clarification: The context holds the data that is rendered as-is by the templating function. So any transformations from the "raw" database data and the context data happens beforehand and the templating function just turns it into HTML.

Reply on news.ycombinator.com