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

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.

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.

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

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

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.

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/

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.

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.

We'd be in a much better spot if browsers supported extending the built-ins. Without that, every custom element can only extend HTMLElement and all accessibility features in things like select menus are entirely up to you to reimplement.

    on click send htmx:abort to #contacts-btn
    on htmx:beforeRequest from #contacts-btn remove @disabled from me
    on htmx:afterRequest from #contacts-btn add @disabled to me

htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like: AlpineJS, hyperscript (if you are brave), vanilla js, etc.

  <!-- Some kind of inline DSL in an attribute? Check -->
  <div hx-get="/example" 
       hx-swap="innerHTML show:#another-div:top">
    Get Some Content
  </div>


  <!-- Some kind of inline DSL that is sorta kinda JS? Check -->
  <div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div>

  <!-- Some kind of inline DSL that is marked as Javascript and with magic values passed in? Check -->
  <div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'>
    <input type="text" />
  </div>


  <!-- Is it Javascript? Jinx, it's custom DSL  -->
  <button hx-get="/info" hx-on::before-request="alert('Making a request!')">
    Get Info!
  </button>
  <button hx-get="/info" hx-on="htmx:beforeRequest: alert('Making a request!')
                              htmx:afterRequest: alert('Done making a request!')">
    Get Info!
  </button>

we are tentatively working on a proposal with the chrome team that takes the most important concepts of htmx and integrates them into HTML using more standard attributes. Alex Petros, a core htmx dev, gave a talk at Big Sky Dev Con on this idea here:

https://www.youtube.com/watch?v=inRB6ull5WQ

this will obviously be a much longer and more difficult process, but hopefully it will give HTML enough oomph that htmx will often be unnecessary

all of that doesn't change the fact that the code above is hyperscript, not htmx

* use on* html attributes to delegate events to a universal event handler

* event handler pulls out the form attribute (if set), then pulls out action, method, target from element, or from the form if unset on the element (elements inherit these from the form they are tied to)

* if action is a URL, then initialize a fetch request using specified URL and method; if method is POST, then add a FormData payload for the specified form

* on fetch complete, the returned MIME type should match with the target attribute, which is extended to also accept a css selector:

   target=_self|_blank|_top  <=> content-type:text/html           => redirect | morph/hx-boost + push-url

   target=css selector       <=> content-type:text/html-fragment  => morph    | innerHTML

    <a action="/url" method="post" onclick="universalHandler(event)" form="someForm" target="_self">click me</a>

--- start quote ---

https://htmx.org/

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes: https://htmx.org/reference/#attributes

--- end quote ---

All my examples come directly from htmx documentation

agree that htmx has a regular language core for config options but, as hyperscript indicates, I’m not afraid of even a recursive language when I think it’s useful.

Hopefully we can get some of the ideas into HTML in a more standard form!

I initially dismissed wanting to add another scripting language to an app, but after some experimenting I have used it to replace 100s of lines of JS. Mainly for UI animations.

It’s not for the faint of heart, but enjoyable to learn.

I find the docs difficult to follow and would enjoy another hardback manual to sit next to this book, which is superb.

maybe next summer

Explain your point better

Original complaint: "it's describing a "whole other language" they call Hyperscript"

Response: hyperscript is a completely separate technology. htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like

My response:

In reality [1] htmx defines its own non-optional DSL that you have to use.

---

I will add that as with any organically grown nice-to-have utility DSLs it's quite haphazard (it's hyperscript-like in one place, js-like in another place, both in some other places etc.). But that's the nature of such ad-hoc informally specified DSLs

[1] which can be easily verified by just visiting https://htmx.org

---

I don't use hyperscript with my htmx, ergo it IS optional in objective reality. Citing a use with it does not prove it can't be used without it.

Nothing in the htmx docs shows it's optional.

There’s no magic abstractions going on. Everything is regular html elements. You can just use the regular js api.

Reading the docs and having an understanding of how frontend works would give you that information.

What do you think the whole reference is about?

What do you think the docs that use and show all that do?

> Reading the docs

https://htmx.org/docs/

Literally the first example uses htmx's DSL:

  <button hx-post="/clicked"
    hx-trigger="click"
    hx-target="#parent-div"
    hx-swap="outerHTML"
  >
    Click Me!
  </button>

Edit: Don't forget also that this is entirely non-optional because if you use htmx, you will load the full support for it whether you use it or not