You can't implement things like infinite scroll or active search in plain HTML because plain HTML only supports hypermedia exchanges based on two hypermedia controls, links & forms, with two events, clicks and submits, and your target options are limited to the current window, an new window, iframes and a few other obscure options. htmx generalizes this, allowing you to implement more dynamic user interfaces within the hypermedia paradigm.
- 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
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).
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.
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 mehtmx 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>
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
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
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>
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
--- start quote ---
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 think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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:
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.
There’s nothing special about it other thab doing pretty much exactly what you’d want.
Do you want to do that? I'd rather use what other people have done