Hypermedia Systems(hypermedia.systems)
hypermedia.systems
Hypermedia Systems
https://hypermedia.systems/
107 comments
Can you expand on it not being great for sites with long sessions? Why does that play into it at all, wouldn’t the tab just sit there and do nothing? Do you mean if you need interactivity when the user goes in and out of the page?
Unfortunately no, the tab doesn't sit there and do nothing.
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.
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 counter: without more details, it's hard to judge; by your description, though, it sounds to me as something you shouldn't be doing in the first place.
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.
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.
> 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.
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.
Why can't the number of rows loaded be stored in the URL?
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.
[1] https://htmx.org/attributes/hx-push-url/
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.
[1] https://htmx.org/attributes/hx-push-url/
Service workers seems like overkill
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
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
That's one of the main problems I see in frontend development nowadays.
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.
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.
I didn't understand either.
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.
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.
He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when your browser heavily unloads your tab.
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 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)
Can't see why you wouldn't be able to handle this with htmx.
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.
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.
The "HX-Request" header is automatically included for every request triggered by HTMX. You can just check that to know if you should respond with a fragment or the full page.
And now I'm stuck replicating htmx's behaviour on the server side?
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.
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.
> 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
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?
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?
In between being laid off and recently finding a new job recently, I worked my way through this book and built a website using htmx.
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!
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!
Exactly, htmx is such a pleasure to work with
:) i'm glad you found it useful
hello hn, i'm one of the authors of hypermedia systems
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
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
This is the first time I had heard of hyperview, but it seems like an interesting approach for some mobile apps. I really appreciated the chapters on it, thank you!
It's a really great library, allowing you to take advantage of native mobile features while keeping the deployment model of web applications. Technically, it's a much bigger achievement than htmx, in that Adam Stepinski, the creator, had to create not only a hypermedia format but also a hypermedia client, which I've come to understand is the really hard part of creating a hypermedia system:
https://htmx.org/essays/hypermedia-clients/
https://htmx.org/essays/hypermedia-clients/
No one appreciates this tide reversal back towards hateoas principles and semantic HTML more than me, but why does it always come with prescriptions to adopt some new tech? You can implement all this stuff using literally any framework from the past 15 years if you want.
The book starts out with a history of hypermedia, a deep dive on the components of a hypermedia system and then a Web 1.0 style application built entirely in Flask. It then incrementally improves this with htmx, because htmx extends HTML in a specific way: it generalizes hypermedia controls. It considers how to integrate scripting and JSON APIs into a hypermedia driven application. It then showcases Hyperview (https://hyperview.org) a novel hypermedia system for mobile application development.
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.
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.
The unique and very special aspect of HTMX's approach is that it changes just 4 things in browser behavior (list from the Hypermedia book):
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).
- 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).
The changes you're describing are already here in standard HTML + JS.
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.
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.
If I understand correctly, the main selling point of htmx is that _html_ is extended with the attributes from GP: the idea being that a bulk of the interactivity of SPAs can be achieved via hypertext alone
I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"
I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"
> the bulk of the interactivity of SPAs can be achieved via hypertext alone
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.
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.
You should be using the same templates/partials/fragments/components that render in your initial page load as your responses to page updates.
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.
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.
If I was to tackle a simplified view of the problem I think you're describing: your frontend devs should provide the markup template the backend would interpolate and return
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
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
with JSON, frontend devs can ignore chunks of it, or work with the backend devs to modify the payload.
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
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
In a team where the backend devs can't work with the HTML templates for whatever reason, the frontend devs would be directly managing those.
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.
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.
The backend is expected to return html. HTMX is not a markup language
Which begs the question: Why mix logic with templates?
I think this htmx essay [1] addresses the tradeoffs you may be getting at if you're thinking "why html vs js+json": the gist is that html is self-describing to the browser, so the backend can make changes to the html it produces and the browser will understand it without the frontend code needing to be updated
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
[1] https://htmx.org/essays/two-approaches-to-decoupling/
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
[1] https://htmx.org/essays/two-approaches-to-decoupling/
htmx mixes logic with "templates" in the same manner that HTML mixes logic with templates: hypermedia control information is embedded in the hypermedia in the form of attributes
Maybe I should clarify the type of logic I mean. Standard HTML contains instructions for how content should be rendered. But it has no control flow structures to control what content should be rendered.
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.
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.
You don't need to mix logic with templates. I just produce a context (result from database queries and some such) and pass it to a function that produces HTML from the data in the context. The data must not be changed in the templating function. This is something I try to avoid as well in order to maintain separation of concerns in the backend code.
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.
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.
Accessibility is a royal pain in the ass if you replace every built-in element with a custom element.
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.
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.
Except with htmx you don't have to leave your declarative html and dig into a whole other language.
You might want to read the TFA, it's describing a "whole other language" they call Hyperscript
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 meHyperscript is totally optional, you can use vanilla js or something like alpinejs for extra stuff
hyperscript is a completely separate technology from htmx, it is designed to be an alternative to javascript and is very speculative
htmx 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.
htmx 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.
All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.
<!-- 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>
i agree
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
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
I'm convinced you can get most of htmx by extending standard attributes to other elements and using the standard on* attributes. htmx basically acts as a "universal/general event handler" that translates DOM events to requests and back to DOM events and modifications. It breaks down like this:
* 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:
* 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" form="someForm" target="_self">click me</a>
yep I think you could do a lot in this direction (see Alex’s talk) I would be hesitant to hijack existing attributes for more than a proof of concept at this point but maybe that’s me being too timid.
> all of that doesn't change the fact that the code above is hyperscript, not htmx
--- start quote ---
https://htmx.org/
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
--- start quote ---
https://htmx.org/
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
sorry! Got you crossed up w sapling-ginger above and thought I was talking w the same person.
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!
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 would love for the authors to consider a book on Hyperscript.
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.
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.
i'd love to write a book on hyperscript, but i should probably get it to 1.0 first :)
maybe next summer
maybe next summer
The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.
That literally isn't what I talked about.
3 out of 4 of your examples mentioned using js or a js-like DSL.
Explain your point better
Explain your point better
It's enough to read the context of the discussion, don't you think?
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
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
[deleted]
> In reality [1] htmx defines its own non-optional DSL that you have to use.
---
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.
---
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.
It's a shame that the list is in that order (both on the htmx website and in the book). Items 1 and 3 are simply not important, whereas 4 is by far the most important feature that HTMX offers.
save the best for last!
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.
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.
The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary.
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.
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.
Quite the opposite, at least in some cases. The state lives in the HTML itself, and actual dev reports of large systems rewrites from react to htmx show faster systems as a result, not slower. In practice, it depends on what you're doing with it -- there isn't one right answer for all systems.
> every single interaction requires a separate round-trip HTTP request
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.
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.
Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend.
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.
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.
You’re absolutely incorrect.
For a lot of applications, the size of request/response interaction might be comparable with what SPA would do anyway to synchronize data.
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)
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)
Retuning the data as a json object vs sending it back with the relevant html really isn’t that much more data in the grand scheme of things. It’s more data but not very much, it’s not like you don’t need to sync with the backend with a json driven SPA.
Disclaimer, I converted some demo react app to htmx as a learning tool.
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.
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.
htmx does not require you to make a server request for every interaction:
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:
https://github.com/1cg/html-json-speed-comparison
https://github.com/1cg/html-json-size-comparison
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:
https://github.com/1cg/html-json-speed-comparison
https://github.com/1cg/html-json-size-comparison
Htmx is a very small, mostly AJAX related library with a nice structure that helps you do this in a principled way.
There’s nothing special about it other thab doing pretty much exactly what you’d want.
There’s nothing special about it other thab doing pretty much exactly what you’d want.
Yes, and htmx is basically intercooler.js with jQuery ripped out and some attributes renamed. Intercooler.js is one of these 'framework[s] from the past 15 years' that you referred to.
>You can implement all this stuff using literally any framework from the past 15 years if you want.
Do you want to do that? I'd rather use what other people have done
Do you want to do that? I'd rather use what other people have done
Feels like a missed opportunity that the online version of the book isnt a demo of hypermedia in itself? Maybe a serious student of htmx could (as a learning exercise) transcribe the book from asciidoc into htmx? :-)
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")
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")
When I look into the website source of the book I just see static HTML and CSS as well as a few media queries. Why would you want to use htmx to serve a completely static website?
Because many usage examples could be "live" as you go through the document learning about htmx functionality. Seeing is believing. The very same htmx-enhanced html pages deployed statically would (presumably) fall back to something still readable.
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.
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.
>many usage examples could be "live" as you go through the document learning about htmx functionality
The examples at htmx.org itself are like this (e.g. https://htmx.org/examples/click-to-edit/)
The examples at htmx.org itself are like this (e.g. https://htmx.org/examples/click-to-edit/)
I found Hypermedia Systems to be useful. Bought the hard copy as support/thank you to the authors, but the entire book is free online at hypermedia.systems. The documentation & essays on htmx.org further explain what you see in the book.
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.
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.
I love how you misspelled it as „gorilla marketing“. That’s exactly the kind of humor I‘ve seen on the author‘s social media posts.
HTMX is not perfect and there are many situations when you probably don't want to use it, but I think it should be considered the default answer to the question: What framework should I learn to build a dynamic frontend?
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.
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.
Is HTMX a legit solution for single-page applications? Feels like you just move the complexity to the server side. For example, the server side code for a simple TODO app is a massive programming project as seen in this repository:
https://github.com/guilycst/go-htmx-todo-list/blob/main/inte...
https://github.com/guilycst/go-htmx-todo-list/blob/main/inte...
I consider moving the complexity to server to be a net win. Never trust the client to do the right thing.
More importantly, quite often the complexity is duplicated for both front end and back end.
More importantly, quite often the complexity is duplicated for both front end and back end.
Some previous discussion including comments from the authors about the book project this was supposed to be:
https://news.ycombinator.com/item?id=34134545
https://news.ycombinator.com/item?id=34134545
This has been one of the best books I've read about web development!
I enjoyed reading this book. It inspired me to simplify some things in the app I currently work on - and from which I earn my income.
I moved away from the front-end/React world, but until a couple of years ago, Svelte was the darling and the future of F/E development and now it's htmx.
I don't want to start another framework flamewar but was it something in particular that people stopped talking about it?
I don't want to start another framework flamewar but was it something in particular that people stopped talking about it?
Hypes come and go. They rarely correlate to the real world usage. Spring, VueJS and Angular are huge, much bigger than HTMX will ever be, but nobody is raving about them.
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.
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.
Svelte is great, htmx is great. I don't think the right way to think about it is that one of them is _the_ future of F/E development. One might be getting more attention at the moment but they are both (along with others) useful tools to have in the belt depending on the use case.
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.
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.
htmx itself is not the future of anything. Businesses are not using htmx to make money and nobody is hiring for htmx. It's an ideological technology rather than a practical one. Maybe it'll inspire something that will turn out to be the future of frontend, but it won't be htmx as it is now.
> nobody is hiring for htmx. It's an ideological technology rather than a practical one.
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.
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.
yeah, well how can you explain the fact that i've made $37 today selling htmx 2.0 on floppies:
https://swag.htmx.org/products/floppy
check mate, roger
https://swag.htmx.org/products/floppy
check mate, roger
I sort of want to check this out but as someone who’s not really felt difficulty using react or a bundler I’m still not sure if it would be useful. How are the static types with something like HTMX?
htmx is a JavaScript library which interprets a set of HTML attributes and JavaScript events. It doesn't have anything to do with static typing. However, it's fairly easy to add a statically-typed layer on top of it eg https://github.com/yawaramin/dream-html
The events have types though, and if you’re pulling data dim the server that also has in theory a type.
Sure, but htmx doesn't have any opinion that those types should be statically checked. Anyone diligent enough can try to enforce it with enough work, but the juice may not be worth the squeeze.
[deleted]
What are you gonna do if you want to give a user the option to display the same search result in a html table and a map drawn on a canvas element, or maybe some info viz thing like a chart? No htmx fanboy has a nice solution for this. Im fine with making hyper media part of the synthesis but ignoring features that you have for free with modern hybrid ssr spa is not helping.
I'm assuming that you're referring to the fact that if you get the data as JSON from the server side, you can use it to render out your multiple visualisations. If this is not what you're getting at, my apologies.
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.
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.
Nice, what if I have a 3D model and I want to show extra info in a html div about a vertex, edge, face or object that I have selected?
This has nothing to with HTMX/Hypermedia, this is an issue with SSR. No pure SSR frameworks can do this.
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?
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?
This is doable, but for complex and component heavy UIs with much JS functionality and client-side-state HTMX is probably not the ideal choice. But for many other use-cases it is. It's good for probably 70% of the use-cases, the other 30% are for SPAs.
you would render the result as an HTML table and then as JSON, i would guess
https://htmx.org/essays/splitting-your-apis/
https://htmx.org/essays/mvc/
https://htmx.org/essays/splitting-your-apis/
https://htmx.org/essays/mvc/
No one is stopping you from still having a JSON API if your hypothetical use case requires it.
The Accept header is there for a reason
The Accept header is there for a reason
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.