i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option)
hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more relevant for modern development
we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here:
I didn’t know what HTMX was and couldn’t figure it out from the comments here, so I went to htmx.org. This is what I saw at the top of the landing page:
> introduction
> htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext
> htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react
This tells me what htmx does and what some of its properties are, but it doesn’t tell me what htmx is! You might want to borrow some text from your Documentation page and put something like the following at the top of your homepage:
“htmx is a dependency-free, browser-oriented javascript library that allows you to access modern browser features directly from HTML.”
Can be achieved in MPAs and SPAs alike. I'd also argue that having state floating around in HTTP requests is harder to reason about than having it contained in a single piece in the browser or in a server session. Granted this is not a problem of HTMX, but of hypermedia. There is a reason why HATEOAS is almost never observed in REST setups.
> two-codebase problem
This is a non-problem. In every part of a system, you want to use the right tool for the job. Web technologies are better for building UIs, if only by the sheer ammount of libraries and templates that already exist. The same splitting happens in the server side: you would have a DB server, and a web service, maybe a load balancer. You naturally have many parts in a system, each one being specialized in one thing, and you would pick the technologies that make the most sense for every one of them. I'd also argue that backend developers would have a hard time dealing with the never ending CSS re-styling and constant UI change requests of today. This is not 2004 where the backend guys could craft a quick html template in a few hours and went back to work in the DB unmolested. The design and UX bar is way higher now, and specialists are naturally required.
> There is a reason why HATEOAS is almost never observed in REST setups.
I saw the HTMX creator floating around the thread so hopefully he can confirm, but my understanding is HATEOS is a specific implementation of a REpresentstional State Transfer API. JSON is often used for the API, HTMX uses HTML instead but it is indeed still a REST API transferring state across the wire.
My shift key really doesn't appreciate all these abbreviations
Just started using HTMX on a new project and have been a big fan. I’d go so far as to say that it’s the best practical case for the theory of hypermedia in general. Like others have mentioned, this is the sort of thing that prob _should_ be in the HTML spec but, given what I’ve personally seen about the standards process, I have little expectation of seeing that. Thx again!
it's implemented in js because that's what's available, but there's no reason this functionality couldn't be folded into HTML itself and then implemented in browsers without requiring js
It's not clear to me, but how and where is state managed?
In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?
Serverless and static are different. Static sites will likely be limited to maintaining state in the browser. Serverless is terribly named but still have a short lived server with access to request query parameters, cookies, headers, and a database depending on your setup
A possible extension to HTMX would be to allow this kind of offloading to pure JS functions instead of requiring hacky intercepts.
You would still have a clear separation of responsibilities between frontend rendering (by the browser only) and application logic (which only generates HTML as output).
I've done the same thing with vanilla JS in a service worker. I did it with my HTMF library -- similar to HTMX -- but not production ready and based on forms rather than being able to put your attributes everywhere. I'll have to create a simple to do app with HTMX that shows this same functionality. The Rust one is cool as you can do it with 150kB library. But I can do the same thing with 10kB with just simple JS.
That's because you are using in a JSON API context, where it doesn't make any sense.
HATEOAS (or, as Fielding prefers to call it, the hypermedia constraint) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up.
The article under discussion here appears to be saying that HTMX can work without Javascript enabled. But HTMX itself is a Javascript library, correct? So how can it work without Javascript enabled?
the article says it is possible to build web applications that use htmx for a smoother experience if javascript is enabled, but that properly falls back to vanilla HTML if js is not enabled
this is called progressive enhancement[1], and yes, htmx can be used in this manner although it requires some effort by the developer
unpoly, another hypermedia-oriented front end library, is more seamless in this regard and worth looking at
Adding the form element allows it to post to the server without javascript, just like olden times. Since the htmx header is not included, the backend was instructed to return a full page instead of a fragment.
Every company I've been a part of has redesigned their front end at least once.
These redesigns would be a lot more difficult if we had to edit HTML on the client and the HTML that a server returns.
Also, HTMX is best styled with semantic classes. Which is a problem for companies using Tailwind and utility classes in their HTML. With class-heavy HTML it's nearly impossible to redesign in two different places. And performance suffers and returning larger chunks of HTML.
Despite all that, I want HTMX to be the standard way companies develop for the web. But these 2 problems need to be addressed first, I feel, before companies (like mine) take the leap.
Complete novice here; what are the advantages of hyperview over something like flutter?
I looked at a bunch of frameworks before settling on dart/flutter for my own cross platform projects. I did look at htmx but since I wasn't really wanted to create a web app I moved on. But I like the idea of a true rest style of app.
hyperview uses the hypermedia approach, which means the client and server are decoupled via the uniform interface
so you can, for example, deploy a new version of your mobile app without updating the client, a big advantage over needing users to update their mobile apps
It doesn't feel like hypermedia to me. It just feels like a vue-like language that is an internal DSL for HTML instead of an external DSL for HTML like svelte and handlebars.
have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards?
When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of those features natively. :)
i haven't heard of any browsers implementing these features, but that's the right thing: they would be far more effectively implemented by the hypermedia client and it wouldn't be too much work technically
my sense is that HTML is constrained by social/organizational issues rather than technical ones at this point
hopefully someone on the chrome team notices htmx at some point and HTML starts making progress again
question - which parts of htmx would be better from an end-user-perspective if they were built into the browser? i assume "all features" might be a bit faster, but is there anything which would be night and day better if it wasn't a js library?
the browser vendors have been more than happy to use experimental features to chart their own course, which I think can be a good thing to spawn innovation and healthy competition. (given the standards bodies will be slower and more prudent - similar to how python doesn't want "pedantic" to be part of python core, because that would hurt pedantic's innovation, not improve it)
Maybe the way someone from the chrome team could tap into "business value" of "let's build these htmx features in chrome" would be that it allows developers to write "internal/developer/crud apps" where a "only supported in chrome" is acceptable.....
HTMX makes heavy use of replacing branches of the DOM with HTML partials fetch wit get/post requests
There a ton of additional features builtin to HTMX, but I'd love to see just this basic primitive built into browsers. It's related to the element transitions API that has been working it's way into browsers, but approaches it from the angle of HTML partials instead of diffing two full pages durn SPA navigation.
if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach.
what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly.
it is a different approach to building web applications than the JSON/RPC style that is popular today
You’ve mentioned unpoly in a couple of your comments. I’m a beginner dev and have used HTMX successfully and quite easily, so thank you for making it. What does it offer that Unpoly doesn’t and vice-versa? Or do they basically do the same things?
I don't really see how progressive enhancement works if every element is a hypermedia control. Without JS/HTMX you just have a page that does nothing:
<div hx-get="/example">Get Some HTML</div>
This will never do anything without HTMX because the semantic of that markup is wrong. You'd really have to write everything in a vanilla HTML approach to begin with, and never make use of the idea of adding hypermedia to other elements.
you do have to structure things properly to make progressive enhancement work with htmx
for your example, you wouldn't have a div, you'd use an anchor:
<a hx-get="/example" href="/example">Get Some HTML</a>
or, more likely, just boost it:
<a hx-boost="true" href="/example">Get Some HTML</a>
and then on the server side you'd need to check the `HX-Request` header to determine if you were going to render an entire page or just some partial bit of HTML
if you go down the progressive enhancement route you need to think carefully about each feature you implement and how to make it compatible w/ no-js. Some patterns (e.g. active search) work well. Others (drag and drop) don't and you'll have to forgo them in the name of supporting noJS
nb: unpoly is a more seamless progressive enhancement experience due to its design goals
HTML forms absolutely do function without htmx since it's a part of browser standard. By default, htmx sends forms using same content type as browser does (application/x-www-form-urlencoded). The server will receive same requests, as if the browser sent them and can differentiate by presence of HX-Request HTTP header.
That's the properly part. If you make a form and the output is supposed to go in a particular place and it doesn't (hx-swap), then it isn't functioning properly. The degree to which it is improperly functioning depends on the UI and the user. In many cases it's improperly enough that it may as well either work or not work.
As mentioned, htmx will attach a `HX-Request: true` header to the request[1]. The server can check this header and either return a partial for swapping, or a full page/redirect like in good old days. Same with any request. This is one way of how htmx provides "progressive enhancement". Sure, this may not be as transparent, as other JS-first frameworks implement it, but it's not complex at all.
The only thing that might cause trouble is non-standard (as in HTML standard) HTTP methods, which basically means any method other than GET and POST, I admit that. However, the fact that these methods are not supported even in HTML5 is a huge miss.
I know they work at some level. That's why I'm comparing them to HTMX.
They don't work fine if the users/stakeholders don't find it acceptable to render the result to the full window instead of the hx-swap style area, or to spend extra time on the backend making it render the whole thing.
Actually, this is one area were SvelteKit has it beat, because the backend is done by SvelteKit, and you don't have to manually deal with hx-swap not taking effect.
hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more relevant for modern development
we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here:
https://hypermedia.systems
[1] - https://htmx.org/essays/when-to-use-hypermedia/
[2] - https://hyperview.org/