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.

Hypermedia advances would be microformats and RDF and the like. http://microformats.org/wiki/faqs-for-rdf

it absolutely is hypermedia

we generalize HTML's hypermedia controls in the following way:

- any HTML element can become a hypermedia control

- any event can drive a hypermedia interaction

- any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML)

all server interactions are done in terms of hypermedia, just like w/links and forms

it also makes PUT, PATCH and DELETE available, which allows HTML to take advantage of the full range of HTTP actions

htmx is a completion of HTML as a hypermedia, this is its design goal

Links and forms are the bread and butter of many frameworks.

Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

if you read the article, you can use htmx as progressive enhancement quite easily

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

i encourage you to read the linked article, and, if it is interesting to you, the essays at https://htmx.org/essays, and then potentially https://hypermedia.systems

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

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?

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.

[1]: https://htmx.org/reference/#request_headers

SvelteKit forms work fine with Javascript disabled -- Rich Harris is a big proponent of progressive enhancement.

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.

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

maybe I'm too close to it, but htmx feels like a hack to address things that really should be part of the HTML spec

if browsers got into the game I would assume they could do things much faster and integrate things like preload (https://htmx.org/extensions/preload/) and idiomorph (https://github.com/bigskysoftware/idiomorph/) much more cleanly w/ the rest of the browser infrastructure

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.

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!

How would this be in HTML standard if it requires JS to work?

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

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

Doesn't this make serverless read-only apps (that only require a fileserver) effectively impossible?

In a serverless read-only app, all business logic and state is maintained on the browser.

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

You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service

This is cool!

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.

I hate HATEOAS with a passion.

Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot.

If htmx has anything to do with HATEOAS it's going to be ignored out of principle.

Mind sharing why you have such strong opinions on HATEOAS?

Is you problem that there aren't many implementations of it today or concerns with the architecture itself?

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 constrain) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up.

I try to explain why this is here:

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

and I try to explain what HATEOAS really is here:

https://htmx.org/essays/hateoas/

and I try to explain why HATEOAS has been, by and large, a failure outside of true hypermedia clients presenting directly to humans here:

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

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

[1] - https://developer.mozilla.org/en-US/docs/Glossary/Progressiv...

I think the point is that by using HTMX your site can degrade gracefully for non-JS users.

A site for a project of mine [1] is built with HTMX and operates more or less the same for JS and no-JS users.

I’m aiming to add some bells and whistles for JS users but the version you see there is more or less the experience non-JS users gets too:

1. https://www.compactdata.org

H̶T̶M̶X̶ e̶m̶b̶r̶a̶c̶e̶s̶ t̶h̶e̶ i̶d̶e̶a̶ o̶f̶ p̶r̶o̶g̶r̶e̶s̶s̶i̶v̶e̶ e̶n̶h̶a̶n̶c̶e̶m̶e̶n̶t̶ [̶1̶]. Y̶o̶u̶ s̶t̶a̶r̶t̶ w̶i̶t̶h̶ a̶ f̶u̶n̶c̶t̶i̶o̶n̶a̶l̶, j̶a̶v̶a̶s̶c̶r̶i̶p̶t̶-̶f̶r̶e̶e̶, w̶e̶b̶ a̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶. H̶T̶M̶X̶ l̶a̶y̶e̶r̶s̶ o̶n̶ t̶o̶p̶ o̶f̶ t̶h̶i̶s̶ t̶o̶ ̶m̶a̶k̶e̶ t̶h̶e̶ e̶x̶p̶e̶r̶i̶e̶n̶c̶e̶ b̶e̶t̶t̶e̶r̶, b̶u̶t̶ i̶t̶'s̶ e̶f̶f̶e̶c̶t̶i̶v̶e̶l̶y̶ o̶p̶t̶i̶o̶n̶a̶l̶.

[1] https://developer.mozilla.org/en-US/docs/Glossary/Progressiv...

Whoa... I was very slow apparently

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.

Out of curiosity, have you used hyperview? Do you consider it production ready?

I use htmx on my personal site and I love it so much. Thank you!

>simplicity

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

REST is almost always a misused term:

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

HATEOAS (or the hypermedia constraint) is a requirement for a REST-ful system, as the creator of the term (Roy Fielding) says here:

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

I have an rewritten wikipedia article on HATEOAS here:

https://htmx.org/essays/hateoas/

And I agree it doesn't make much sense outside of a hypermedia system (like the web), being consumed by humans:

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

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

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.