The discussion about Library vs. Framework misses the core objective of the HTMX project.
What do you mean by "moving the boundary of hypermedia client"?
HTMX tries to claim that hypermedia to only applies to HTMX because something something browsers and html.
Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent.
You can create a client that only accepts base32-encoded cat gifs, and that will be a hypermedia client (in its infancy).
No, anything that understands hypermedia responses is a hypermedia client.
Cat GIFs are not hypermedia so a cat GIF viewer is not a hypermedia client
Maybe I'm overly grumpy this morning but words do actually have meanings that we can look up and refer to
It's odd to insist on strict word choice when transferring GIF images using the hypertext transfer protocol.
As such, they're ancillary sub-resources to hypermedia but not themselves hypermedia.
Hypermedia starts with the client, not with the file format.
How you transfer the data is irrelevant BTW. I don't get why you include that in your argument.
https://htmx.org/essays/hypermedia-clients/
https://hypermedia.systems/hypermedia-components/
On the other hand, there is a real difference between plain text and HTML (or HXML, don't shoot!) which is a subset of text with additional concepts layered on top of it. This is akin to how JSON (or XML) is not hypermedia, but can be used to create hypermedia such as Siren or HXML.
So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client, whereas it doesn't make sense to claim it is being used as hypermedia unless it is being consumed by a properly written hypermedia client. To make my thinking concrete, I believe Siren would continue to be hypermedia, even if it wasn't be consumed properly by a client, but then also you could not describe that pairing as a hypermedia system. (This is one reason I focus on the systemic nature of hypermedia, rather than solely on hypermedia formats)
Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
So, HTML is different from plain text because it "has concepts layered on top of text" where as JSON is not hypermedia despite "having concepts layered on top of text". And the only reason is because you said so.
> So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client
Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
> Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
No, the reason is because HTML qua HTML has hypermedia controls and JSON qua JSON does not. Recall that, before I pointed out the widely used and accepted definition of hypermedia controls, and in particular that links and forms are hypermedia controls, you did not understand that concept, so you might spend some time quietly reflecting on that idea. It may help clarify things for you.
> Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
As I have said and written previously (https://htmx.org/essays/hypermedia-clients/, https://hypermedia.systems/hypermedia-components/) I agree that a hypermedia client is necessary for a properly functioning hypermedia system that adheres to the uniform interface. However, I think that there is a good argument that Siren, for example, is hypermedia, even if it isn't being consumed correctly, just as I think HTML is hypermedia, even if someone is screen scraping it (i.e. not using a hypermedia client to consume it).
I don't think you can call those uses a hypermedia system, but I also don't think that changes the fact that the underlying formats, Siren & HTML, are hypermedia, due to the fact that they have hypermedia controls. That might be a subtle distinction, but I think it is a valid one. Again, perhaps as you reflect more on this concept, new to you, of hypermedia controls, the distinction will become easier to understand.
> They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
I'm very sorry you that feel that way.
I would call HTML, "a natural hypermedia", rather than "the natural hypermedia". I would also call HXML & Siren natural hypermedia, due to the presence of hypermedia controls (a concept new to you) in their specifications.
But I wouldn't be surprised if there's a crazy project somewhere using GIFs as a way to render HTML pages with clickable links :D
That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look like if we had it in the spec
Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"
Does he? Evidence or it didn't happen.
If that doesn’t convince you, then I’ve got nothing and suggest we both just go and enjoy some lazer horse/buffalo/pickle memes in the htmx twitter account
Of course you're not. And I already pointed it out to you elsewhere. Your entire writing and marketing revolves around one idea, and one idea only: HTML is "natural hypermedia", and everything else is not.
There are many other hypermedias, such as Siren, which uses JSON as a base, and I have never claimed otherwise. Mark Amundsen, perhaps the worlds expert on hypermedia, wrote the forward to my book, Hypermedia Systems, and found nothing objectionable and much worthwhile in it.
I hate to be rude but you didn't understand, or refused to acknowledge, the basic meaning and usage of the term 'hypermedia control' until I cited a W3C document using it. While I certainly understand people can dislike the conceptual basis of htmx, its admittedly idiosyncratic implementation or the way we talk about it, at this point I have tried to engage you multiple times in good faith here and have been rewarded with baseless accusations of things I haven't said and don't believe.
At this point, to be an honest person, you need to apologize for misrepresenting what I am saying multiple times to other people. It is dishonest and it makes you a liar, over something as dumb as a technical disagreement.
Just because you were correct in one small detail (citing a 2019 standard retrofitting definitions for the use in RDF etc.) doesn't make you correct in the grand scheme of things.
> with baseless accusations of things I haven't said and don't believe.
I literally quoted your own words at you.
> you need to apologize for misrepresenting what I am saying multiple times to other people.
I will not apologize for things that I even quoted from your own writing and words.
the presence of hypermedia controls is a defining characteristic of a hypermedia format
> I literally quoted your own words at you.
You took an essay I wrote in which I defined the term HDA specifically to contrast with the term SPA in the context of web development and spun that into an imagined philosophy where HTML is the only hypermedia in the world. You persisted in this after I pointed out that I included HXML in my book on hypermedia, and gave a clear definition of what I consider the defining characteristics of hypermedia & clarified specific examples of other formats that are hypermedia.
You have confused "X is A" with "Only X is A" and then, when large gaps in your understanding of hypermedia have been brought to your attention, you have dismissed them as small details.
> I will not apologize
I did not expect you to.
At this point I think I have taken goodwill as far as it can go. I encourage any other readers who have made it to this point in this hellthread to simply read my essays & perhaps my book, and judge them on their own merits:
Another question in the same vein: In your view, why is it so important for the project to advance the HTML spec?
By the way I am actually curious about this, I am an avid user of HTMX, but have never contemplated this.
Edit: Ok I think I get it now. HTMX provides hypermedia controls that should have been in the standard from the beginning. It also more-or-less maintains the current semantics of the web as defined in the HTML spec. Therefore it is logical to eventually include it into the standard. That it?
A good date input would cover at least like 80-90% of use cases in my opinion. From experience it's currently more something like ~40% or so.
the beauty of HTML markup is that it's declarative. at least from the tutorials I've seen, WebComponents drag you firmly back into imperative land with document.addChild everywhere.
When you merely import it. you can use it as declaratively as any other HTML tag. Basically Web COmponents allow you to add your own tags that are rendered as components, and freely mix "built-in" and "custom" DOM nodes in your document.
But there is a widespread desire for better native HTML elements.
E.g., a date range input.
Instead I expect the industry to stabilize around a few widespread sets of web components, much like a lot of CSS for controls stabilized around Bootstrap's styles.
No, industry should not and will not stabilize around "few widespread sets". For the simple reason: it's extremely difficult to create a proper userland UI control in the browser. How many custom drop downs fail even the most basic keyboard behaviours? How many custom UI elements fail even the most basic screenreader interactions? etc. etc.
What you really truly need is a rich browser-native set if controls, and https://open-ui.org/ is slowly working towards that.
Related: You can't capture the nuance of my form fields https://web.archive.org/web/20230208235009/https://drewdevau...
On the other hand, now we have auto-playing videos on every other page.
In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get <form> to target a section of the page that isn't an <iframe> has been argued about and hashed out for years.
Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. https://github.com/whatwg/html/issues/new?assignees=&labels=...
It asks three main questions:
* What problem are you trying to solve?
* What solutions exist today?
* How would you solve it?
The goal of these questions is to focus primarily on the problem, and only secondarily on the solution.
For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding <if> <while> and <set-variable> elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually.
So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better?
HTMX doesn't have really great answers to the "what problem?" question. Look at the home page:
* Why should only <a> and <form> be able to make HTTP requests?
* Why should only click & submit events trigger them?
* Why should only GET & POST methods be available?
* Why should you only be able to replace the entire screen?
Those questions are all solution-oriented, not problem-oriented.
Instead, let's look at the examples. https://htmx.org/examples/
Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility.
For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.)
Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates.
Some of the HTMX examples already have recent new HTML features that support them directly, like <dialog>, declarative form validation, using <details> as an accordion (which you can use to support tabs).
In the future, I expect to see HTML features landing like these:
* Editable data tables
* Infinite scroll / lazy loading
* Combobox
* Skeleton UI / Loading
If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding <if> <while> or <set-variable> elements, the problems it solves seem to all have better solutions at a different level.
And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution.
But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)
I think the problem is at it's core, "how do I add rich interactivity and dynamism to an HTML document without scripting?"
A general event-driven document model where document events can automatically issue server requests whose replies then trigger more document events and/or updates makes sense. htmx is one way to do this, but probably not the only or best way, but it has the core idea right: generalize hypermedia and extend the event model.
Simple answer: yes.
I don't think the point is for HTMX to get standardised, but rather for HTMX to drive conversation and evolutions in the spec.
After all jQuery did not get standardised. Rather the issues solved by subsets of jquery were looked at, and considered for solving in the standard.
> <button hx-post="/clicked" hx-swap="outerHTML">
There is concrete value in stating unambiguously "this is a <form>" versus "this is a blob of imperative code that I swear acts like a <form>".
how do you feel about the href, method and action attributes in HTML?
And add HTMX as an "extension"