Hypermedia Systems
hypermedia.systems
hypermedia.systems
This book is the missing tutorial, and it's been very useful to me. It even lead to the "A little taste of HTMX" series (https://www.bitecode.dev/p/a-little-taste-of-htmx-part-1).
After a year of using HTMX, I really like it and would encourage everybody to give it a try.
It's nice for:
- internal tools
- midly dynamic websites
It's not great for any web page you stay a long time on mobile on, though. I made a web app with it, and on my phone, you can't handle the fact the browser plays against you if you stay a long time with a tab open and goes in and out of the app. You really need a lot of control in JS for that.
Also: don't try to avoid JS using it. It's a mistake many people do, and that's not how you get the best out of it.
I regularly sparkle a little vanilla js or alpine in my htmx websites to make them nicer. And in some cases, I even have one lone page that loads a full vue/react because that particular section needs to be way more dynamic. It's not an XOR. You have now a whole spectrum of how dynamic and how much work you want to put in.
Sometimes, I don't write JS at all, but it's not a requirement.
Mobile browsers will do all sorts of optimization, such as interrupting the network, slowing down the vm, putting it to sleep, caching and uncaching things without letting you know, and without a predictable pattern.
If you use raw JS, you can deal with all kinds of errors manually, put in place recovery strategies, bust caches, etc.
With HTMX, you just get sluggish behavior, or no behavior at all in your page, and you don't know why.
Also like another person said, you expect your state to be the same, like the scrolling placement, but chrome might decide that no, you get a page refresh there, or you are somewhere else in the page on next switch.
In this particular app, I have a raw JS counter, which is updated on the client to make it snappy, and by htmx to keep it up to date with other modifications. But the counter will be off randomly because Chrome messes with it. So I had to manually put many rules to know it's out of sync, and request the sync at the right moment. But the sync may not happen because Chromes decided so. So I should try several times, with exponential backoff, differentiates the different reasons of failures and update the DOM manually while handling various interactions with other components.
At this stage, you are basically coding a lot in JS instead of getting the state from the server in HTML, so having VueJS + VueRouter + Pinia is going to be easier to manage, and you'll get more interactivity and optimistic updates on top.
It's not worth it. Right tool for the right job and all that.
It's mostly on mobile though. On Desktop, the HTMX app behaves perfectly.
About the state: there are plenty of ways to have a polymorphic backend responding with fragments or entire HTML pages, depending on state and what's required by the request. Can't see the limitation you guys are talking about.
About the scrolling position, it's actually dynamically loaded content that messes everything. Browsers do a pretty good job keeping scrolling position, as long as the page loads with the same content as before. Which is easy with htmx and very hard to impossible with dynamic content.
For example to implement an infinite scroll, you can use the htmx DSL to load additional rows like this: https://htmx.org/examples/infinite-scroll/
If I did this with react, I can use a session storage caching plugin, so how do you prevent the chain of load events on history back and page refresh with htmx?
Now you are looking at service workers...
I mean with a bit of extra JS and some additional APIs, nothing is strictly impossible but it's often that you go back to the architecture board when you are working with it.
I don't dislike it though, not even close. React (and other similar tools) has (have) a place, so does htmx.
You could use hx-push-url [1] every time the scroll triggers loading more rows, updating the total number of rows loaded. When the browser refreshes the page, the backend will know how many rows to return. No need for complicated JS plugins and service workers. Just basic browser feature, HTTP and HTML. You have fewer ways of shooting your own foot.
I think the modern frontend environment have a tendency to look for over complicated solutions.
Most times I see people proposing JS to manipulate the browser, a simpler browser-based solution would be perfectly good.
In most cases when I browse the web, the JS manipulation leads to very poor UX.
Even when the developer is exceptionally good and can deliver better solution than the browser, the advantage gain is so small that it's not worth the effort. Unless you're Facebook and can dillute the high-quality development cost to billions of users.
HTMX has pretty simple controls for pushing history state from either the client or the server for each request.
Add the current page into the URL every time you load a new section and when someone hits 'back', they can be given exactly the same content as they had before
Developers are taught to overkill everything. They implement things naively, admired of how "smart" their "solution" look, compared to a "dumb" browser.
They shoot themselves in the foot all the time. Users suffer with bad UX. Projects move slowly and expensively. Everyone loses.
Depending on RAM limitations, the mobile browser will kill the tab session. When the user comes back, it'll reload the page. But I don't see how this is different for htmx or JS websites.
I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through / Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)
I see two scenarios:
1. User interacts triggering "/blog/foo", which should return a fragment
You can add a "?fragment=true", or a custom header, or hidden input indicating the backend the desired behavior.
2. User's mobile browser reloads "/blog/foo"
Respond with the entire page, including the fragments as if the user had interacted each step of the way.
Seems doable and not that much of a hassle as fragment replacements should be simple afterall, but I'm simply running my site as a static page for now and I had to hack a redirecting extension for things to sort of work.
Huh? /blog/foo should return the full document. Why did you do it so it depends on the user clicking through links in a certain order?
It was such a pleasant experience compared to the frontend work I'd been doing in react. I never felt like htmx got in the way, it just worked and I almost never needed to think about it. I spent all my time solving problems and learning CSS.
Thanks for writing the book and making it free!
this is a book about how hypermedia systems work in general, and how htmx (augmenting the standard web hypermedia system) and hyperview (a novel mobile hypermedia) work specifically
it's available free online, or for purchase via kindle or hardcover
hope people find it useful
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.
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
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 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>
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 ---
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
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
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.
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:
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
Besides technical merit [1] in this era of tech hypes, manias and virality it helps to engineer some gee-wow moments... 2 cents.
[1] (that htmx and friends definitely have, reminding us once again that "any fool can make something complicated but it takes a genius to make it simple")
Ofcourse there might be valid reasons to choose to deploy statically using adoc (reusing for pdf, minimal maintenance etc.) but my point is about maximizing the impact.
The examples at htmx.org itself are like this (e.g. https://htmx.org/examples/click-to-edit/)
htmx is a straightforward, simple-to-implement javascript library that brings HATEOAS to the top of your development mindset. You can disagree with the HATEOAS philosophy, but the reasoning and purpose of the approach is clearly and professionally explained by the authors.
Yes, the gorilla marketing on x.com may rub some the wrong way, but frankly, it's fun. Humor and a useful product, with a deep rationale & good documentation, are wins in my book.
At the moment the answer to that question is "react" and while react can be cool (I've heard) it has developed into a complex world that requires quite some time to master. Even intuitive JS frameworks like Svelte have been getting a lot bigger in order to be more feature complete.
HTMX is the Pareto answer to building dynamic frontends. It will be great for 80% of all projects that require interactivity while doing that job in 20% of the complexity that react would bring.
https://github.com/guilycst/go-htmx-todo-list/blob/main/inte...
More importantly, quite often the complexity is duplicated for both front end and back end.
I don't want to start another framework flamewar but was it something in particular that people stopped talking about it?
Svelte is still growing. Nothing has happened. React ecosystem is so full of commerce that there're always many voice talking about React. I often think that people praising HTMX are comparing it to React, which is by far the worst of all SPA frameworks.
SvelteKit on the other hand is such a succinct yet powerfull all-in-one framework that HTMX (with the required backend with routing and template) appears clunky compared against it. But as I said, most people coming from React and I fully understand why HTMX appears as such a relief. Because it is in those cases.
I recently took over a flask web app. Using htmx with it to get a more snappier SPA feel in certain places was a true joy.
Will I use it on a greenfield highly interactive webapp? I'm not sure yet. But it's been nice to discover a new tool that worked really well in a recent project I've taken over. The experience was a really good one so I'm not surprised it's been getting attention lately.
Nobody is "hiring for" json either, or for git. Yet they are in incredibly wide use.
The thing is, htmx isn't "the front-end solution" React and co are selling. It's a new component that can be added to any classic/boring server-side stack to help it do more. These stacks are very practical, not "ideological" (lol), they made the web the powerhouse it is today.
If anything, the audience of frontend frameworks is Javascript/front-end developers; the audience of htmx includes anyone who can glue together some html and a http server. People who have been using java, or python with django, or C++, or rust, or OCaml on the backend. That's a lot of people even if they're not explicitly hired based on whether they have learned the docs of htmx.
https://swag.htmx.org/products/floppy
check mate, roger
I think you may be misunderstanding what htmx does
If you send the HTML table over the wire, you can use it as the datasource for the other visualisations, same as you would with JSON. You can extend it with `data-` attributes if necessary to get some extra machine-readable information in there, but I have not needed to do that yet.
On the application I'm currently working on, we do this and then have a listener on the htmx event to turn the table into a d3.js graph. It works pretty well, and has the advantage that if someone is using our application with JavaScript turned off, they still get the table with all the data.
You would do this the same way you would in any other website, have the server send the data required (Hypermedia or not) and use client side JavaScript to do the client side reactivity.
This is like asking why doesn't HTMX allow me to change the colour of a button when I hover over it, why should I have to do this on the client?
The Accept header is there for a reason