Hacker News Reader

Comment by jph00 | Hacker News Reader

The unique and very special aspect of HTMX's approach is that it changes just 4 things in browser behavior (list from the Hypermedia book):

    - Any element should be able to make HTTP requests
    - Any event should be able to trigger an HTTP request
    - Any HTTP Action should be available
    - Any place on the page should be replaceable

The default behavior of browsers (without HTMX) is that only A and FORM tags can make requests, only GET (A,FORM) and POST (FORM) HTTP actions are available, only click can trigger a request, and only the full can be replaced.

By changing these 4 things, it opens up a huge range of possibilities, but requires learning very few new concepts. And it also lets you work in whatever language you're most comfortable with -- you don't generally have to use JS (e.g very useful for data scientists, who generally know python).

View on HN

The changes you're describing are already here in standard HTML + JS.

Every element can be replaced with custom Web Components that can cause requests. Content can be partially displayed with just a click, tap, keypress, etc. and it doesn't even require scripting!

There are over 200 extant discrete methods that can be used to send network requests in web applications running in modern browsers.

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"

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

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.

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.

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

Which begs the question: Why mix logic with templates?

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/

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.

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.

Accessibility is a royal pain in the ass if you replace every built-in element with a custom element.

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.

Except with htmx you don't have to leave your declarative html and dig into a whole other language.

You might want to read the TFA, it's describing a "whole other language" they call Hyperscript

    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

Hyperscript is totally optional, you can use vanilla js or something like alpinejs for extra stuff

hyperscript is a completely separate technology from htmx, it is designed to be an alternative to javascript and is very speculative

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.

All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.

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

And so on.

i agree

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

I'm convinced you can get most of htmx by extending standard attributes to other elements and using the standard on* attributes. htmx basically acts as a "universal/general event handler" that translates DOM events to requests and back to DOM events and modifications. It breaks down like this:

* 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

So something like:

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

I have ideas for extending beyond this, but this seems like the core of extending HTML to cover htmx semantics.

yep I think you could do a lot in this direction (see Alex’s talk) I would be hesitant to hijack existing attributes for more than a proof of concept at this point but maybe that’s me being too timid.

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

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

sorry! Got you crossed up w sapling-ginger above and thought I was talking w the same person.

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 would love for the authors to consider a book on Hyperscript.

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.

i'd love to write a book on hyperscript, but i should probably get it to 1.0 first :)

maybe next summer

The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.

That literally isn't what I talked about.

3 out of 4 of your examples mentioned using js or a js-like DSL.

Explain your point better

It's enough to read the context of the discussion, don't you think?

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

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

---

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.

https://news.ycombinator.com/item?id=40746543

Nothing in the htmx docs shows it's optional.

It also doesn’t show, at any point, that it’s required.

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 link to attributes on the front page does?

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>

The only place where it talks about anything else is a small section on scripting with a link out to a huge meandering essay with small examples lost in all the philosophical discussions.

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

The example provided is not hyperscript.

It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.

save the best for last!

from the book:

> This gives us our fourth, final and perhaps most important opportunity to generalize HTML: Opportunity 4

> HTML could be extended to allow the responses to requests to replace elements within the current document, rather than requiring that they replace the entire document.

> This is actually a very old concept in hypermedia. Ted Nelson, in his 1980 book “Literary Machines” coined the term transclusion to capture this idea: the inclusion of content into an existing document via a hypermedia reference. If HTML supported this style of “dynamic transclusion,” then Hypermedia-Driven Applications could function much more like a Single Page Application, where only part of the DOM is updated by a given user interaction or network request.

The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary.

To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.

Quite the opposite, at least in some cases. The state lives in the HTML itself, and actual dev reports of large systems rewrites from react to htmx show faster systems as a result, not slower. In practice, it depends on what you're doing with it -- there isn't one right answer for all systems.

> every single interaction requires a separate round-trip HTTP request

Why? It's not like JavaScript stopped existing. If you need something more interactive or dynamic, use JS. The two approaches are not exclusive. Some things can go to the server and some stay in the client. Your use case determines the balance. Easy.

Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend.

Well, you don't. I have been very successful using htmx by using it only in interactions that make changes to my data, that is state. Other user interactions (e.g. strictly visual interactions) remain on the client.

You’re absolutely incorrect.

For a lot of applications, the size of request/response interaction might be comparable with what SPA would do anyway to synchronize data.

If you need purely browser-side state to change, HTMX integrates quite well with writing such parts in JS (personally I like using Alpine.js for that)

Retuning the data as a json object vs sending it back with the relevant html really isn’t that much more data in the grand scheme of things. It’s more data but not very much, it’s not like you don’t need to sync with the backend with a json driven SPA.

Disclaimer, I converted some demo react app to htmx as a learning tool.

I reduced data transmission by about 20 percent. Cut the time to first render of html in half.

Power usage on the client was down ( probably because the test suite finished sooner) and the server was also lower, but likely for the same reason.

The html returned by the demo and my app was identical except for the react lib and htmx library. The selenium test suite only needed minor changes to work with htmx, I tried to keep the layout the same.

I can't speak for the developer experience or time spent writing the react version, but the htmx was not too painful.

I'm not sold in the fact that it doesn't matter in the grand scheme of things.

I should probably spend some time and make a blog post so that people can pick it apart and tell me how bad I am at doing it the react way.

htmx does not require you to make a server request for every interaction:

https://hypermedia.systems/client-side-scripting/

i would note that if you are going to make a server side request, HTML can be faster than the equivalent JSON:

https://github.com/1cg/html-json-speed-comparison

https://github.com/1cg/html-json-size-comparison

Reply on news.ycombinator.com