When I was reading “The future of htmx” blog post which is also being discussed on HN [1], the “htmx is the new jQuery” idea jumped out at me. Given that jQuery has been gradually replaced by native JavaScript [2], I wondered what web development could look like if htmx is gradually replaced by native HTML.
Triptych could be it, and it’s particularly interesting that it’s being championed by the htmx developers.
this is a set of proposals by Alex Petros, in the htmx team, to move some of the ideas of htmx into the HTML spec. He has begun work on the first proposal, allowing HTML to access PUT, DELETE, etc.
https://alexanderpetros.com/triptych/form-http-methods
This is going to be a long term effort, but Alex has the stubbornness to see it through.
In the meanwhile, I found that enabling page transitions is a progressive enhancement tweak that can go a long way in making HTML replacement unnecessary in a lot of cases.
1) Add this to your css:
@view-transition { navigation: auto; }
Well, not so fast haha. There are a few details that you should know [1].
* Firefox has not implemented this yet but it seems likey they are working on it.
* All your static assets need to be properly cached to make the best use of the browser cache.
Also, prefetching some links on hover, like those on a navbar, is helpful.
Add a css class "prefetch" to the links you want to prefetch, then use something like this:
document.addEventListener("mouseover", ({target}) => {
if (target.tagName !== "A" || !target.classList.contains("prefetch")) return;
target.classList.remove("prefetch");
const linkElement = document.createElement("link");
linkElement.rel = "prefetch";
linkElement.href = target.getAttribute("href");
document.head.appendChild(linkElement);
})
--
1: https://developer.mozilla.org/en-US/docs/Web/CSS/@view-trans...
2: https://developer.mozilla.org/en-US/docs/Web/API/Speculation...
Its genuinely incredible that we are more than 20 years since the takeover of HTML from the W3C and there isn't anything in the browser approaching even one tenth of the capability of XForms.
I wish the people behind this initiative luck and hope they succeed but I don't think it'll go anywhere; the browser devs gave up on HTML years ago, JavaScript is the primary language of the web.
It looks wonderful, but the adoption will be a thoroughly uphill battle. Be it from browsers, be it from designs and implementations on the web.
I'll be first in line to try it out if it ever materializes, though!
Looks really pragmatic and I'd be glad to see this succeed.
Is anyone able to credibly comment on the likelihood that these make it into the standard, and what the timeline might look like?
Good luck!
The partial page replacement in particular sounds like it might be really interesting and useful to have as a feature of HTML, though ofc more details will emerge with time.
Unless it ended up like PrimeFaces/JSF where more often than not you have to finagle some reference to a particular table row in a larger component tree, inside of an update attribute for some AJAX action and still spend an hour or two debugging why nothing works.
No, please, just no.
The idea of using PUT, DELETE, or PATCH here is entirely misguided. Maybe it was a good idea, but history has gone in a different direction so now it's irrelevant. About 20 years ago, Firefox attempted to add PUT and DELETE support to the <form> element, only to roll it back. Why? Because the semantics of PUT and DELETE are not consistently implemented across all layers of the HTTP infrastructure—proxies, caches, and intermediary systems. This inconsistency led to unpredictable failures, varying by website, network, and the specific proxy or caching software in use.
The reality we live in, shaped by decades of organic evolution, is that only GET and POST are universally supported across all layers of internet infrastructure.
Take a cue from the WHATWG HTML5 approach: create your RFC based on what is already the de facto standard: GET is for reading, and POST is for writing. The entire internet infrastructure operates on these semantics, with little to no consideration for other HTTP verbs. Trying to push a theoretically "correct" standard ignores this reality and, as people jump into the hype train, will consume significant time and resources across the industry without delivering proportional value. It's going to be XHTML all over again, it's going to be IPv6 all over again.
Please let's just use what already works. GET for reading, POST for writing. That’s all we need to define transport behavior. Any further differentiation—like what kind of read or write—is application-specific and should be decided by the endpoints themselves.
Even the <form> element’s "action" attribute is built for this simplicity. For example, if your resource is /tea/genmaicha/, you could use <form method="post" action="brew">. Voilà , relative URLs in action! This approach is powerful, practical, and aligned with the infrastructure we already rely on.
Let’s not overcomplicate things for the sake of theoretical perfection. KISS.
What is the upside of
<button action="/users/354" method="DELETE"></button>
<button action="/users/delete?id=354"></button>
?> giving buttons to ability
Might want to fix that. :)
I love these. Its the things we've been doing (or attempting to do) with our web pages for decades. I've written tons of jquery to do these exact things, lots of react code as well.
I think its an uphill battle, but I am hopeful.
[dead]
[dead]
JSON rest api are just hypermedia rest api but with the data compressed. The compression format is json and the dictionary are the hypermedia relations previously passed in the client.
It’s 2025, the client don’t need to be generic and able to surf and discover the internet like it’s 2005.
The database is consumed via APIS distributed in two parts: first the client (a lib), second the data: json.
Co-author here! I'll let the proposal mostly speak for itself but one recurring question it doesn't answer is: "how likely is any of this to happen?"
My answer is: I'm pretty optimistic! The people on WHATWG have been responsive and offered great feedback. These things take a long time but we're making steady progress so far, and the webpage linked here will have all the status updates. So, stay tuned.