this will probably get nuked since it's just a point release (no hard feelings dang), but there is an interesting new feature: it now has View Transitions support, an experimental browser feature available in Chrome 111+ that makes visual transitions between DOM states much easier to animate.
This seems like a big leap forward for web apps! Proper view transitions are one of the biggest gaps in usability and perceived smoothness between web and native/Flutter apps at the moment.
If you are on the fence about using htmx in production. my startup[0] uses it exclusively for our frontend (with like 2 lines of hyperscript. It’s sister library). No complaints and boy, it’s such a fresh breath of increased productivity and still excellent user experience.
We still had to build an API anyway for external organizations using our product, but you still skip a ton of unnecessary JS code.
It took me a second to get the hang of it but your app is cool as hell. I recommend everyone click it.
One comment on the UI, on my phone it was not obvious that adding the topic tags was working, because they get added off screen. I was just clicking "ancient-greece" like an idiot for 30 seconds then I accidentally scrolled down and saw what was happening.
Echoing another commenter, your app is super cool. Bookmarked.
One UI note, the layout jumping around when typing or clicking on things is a little jarring. E.g., the "Word is too short" message pushes the field the user is typing in down the page.
What's the back-end? Do you generate those HTML responses via a normal template engine, or is there some sort of deeper integration with HTMX on the backend?
Wish htmx supported WASM - ie instead of sending a request to the server, you send the request to the hosted WASM module and render the response. Ideally, one could then use Rust web-frameworks such as Axum on the client side.
It seems to just be a simulated delay and should probably mention that if that's the case. Running the first example locally does indeed attempt to send a network request when clicking the edit button.
> Unfortunately for HTML, CSS transitions are only available if you use JavaScript: you have to change elements dynamically in order to trigger the transitions, which “vanilla” HTML can’t do. In practice, this meant that only the cool kids using JavaScript to build SPAs got to use these tools, further cementing the aesthetic superiority of SPAs.
I'm sorry if my question is not sufficiently informed, but how does HTMX not "use JavaScript" to trigger animations?
Have followed the library and approach for a while and tend to compare it to Alpine, which I find a bit more intuitive.
But that's probably exactly because Alpine isn't shy about the fact that you're writing JS in the end.
I found such solutions (Alpine) a grrat joy to start working with (e.g. a complex form with nested fields, custom autocomplete...) and a nightmare to extend or generalize.
The Chrome transition API is very interesting. Also, there certainly is a place for controlling JS via HTML.
But for the risk of sounding inpolite:
Having read a couple of posts by htmx team, the "htmx is hypermedia, SPAs were invented because X and are a crutch" style intro starts to feel a little repetitive and dated to me. Every post starts with a bashing of "SPAs", it gets tiresome very quick. SPAs can be simple, they can be complex nightmares.
So can HTML-centric "sprinkles of JS" that outgrow their purpose.
Also, who are these "cool kids writing SPAs"? It's 2023 and it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.
That's the problem React solves, not just fluffy page transitions.
> it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.
Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.
Before I begin to ramble; I don't see where your "just" comes from, in other words, where is the difference between our two statements?
> > it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.
> Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. > Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.
Sure, I agree with you!
What I don't like is the contrarian attitude of htmx team and the pretence of not using JavaScript. It's just progressive enhancement, a valuable and very old approach.
IMO, an approach best implemented without a "framework" like HTMX.
I mentioned Alpine, because I think in combination with blade "components" (which are just fancy template partials), I think it's better than HTMX (subjective opinion).
Still, I'd advise against Alpine and for a simple external JS file for anything more serious than an MVP or a landing page.
Kudos to the htmx developers, who made a library out of their idea of progressive-enhancement JS.
My point is just that I don't like two things which seemingly repeat in each of their blog posts:
- They define their own language around REST and hypermedia to explain a string-language in HTML-attributes, which is then executed by JS. It's really not much different from Alpine. It's called "progressive enhancement" and a DSL in HTML attributes is not needed to implement it
- They start most posts about their library with a lengthy ramble about "cool kids and SPAs" vs "good old server-rendered HTML". This is a tiresome trope.
The first time I read their "HATEOAS / Rest is for humans" article, I found it witty.
The second time I read an article explaining their appproach, I found it interesting.
By now, I just skip all the htmx stuff and jumped to the meat of the post, the new (JS!) API for page transitions.
I'm not really interested in learning a new "JS-in-HTML"-language.
TL;DR: Have you ever heard of frontend-fatigue-fatigue? :D
I wrote lots of vanilla JS which abused HTML attributes in similar ways.
For a simple landing page, I'll probably try htmx some day instead of writing this myself.
But I tend to not like this whole approach of "magic strings in HTML". When I do this in my own code, the point where an internal alarm rings is usually when HTML attributes start referencing comma-separated lists of unchecked... somethings (usually IDs).
what I'm saying there is that CSS Transitions aren't integrated into the normal hypermedia flow of HTML, which is what htmx tries to address
we have never said that SPAs are a crutch, our (really, my, there isn't much of a team and I don't speak for anyone else) claim is that SPAs are as popular as they are for advantages that are not inherent to them when compared to hypermedia, and htmx tries to narrow that gap
i am sympathetic that people reading the various essays on the htmx website might get worn out by my repetitive beating on hypermedia, but consider that for every repeat reader, there are tens or hundreds of new readers who haven't heard much about or thought much about hypermedia. Repetition is a key to teaching, and I teach, so maybe that influences how I write as well.
regarding abstraction and modularization being key to large front ends, I sort of agree to an extent, but I think that at the system level that abstraction can be hypermedia and that the modularization can be done server side
of course it always depends on the app, htmx/hypermedia isn't right for everything, etc. etc. as we try to point out in an essay on our site:
do I get a little punchy about SPAs at times? Sure, it's the internet after all. I've been fighting for the hypermedia-oriented approach for web development for a decade now, and I've been called "old", "irrelavent", "pointless" and "stupid" many times along the way by SPA fans. There is obviously some conflict between my views on web development and the larger front end world's perspective.
But I try to be reasonably balanced about the tradeoffs, even while I think that the SPA approach is dramatically overused today.
First of all congrats on creating a project that people want to use. I hope to one day join your ranks!
First impressions from someone who's had a hand in many large scale consumer centric UI's.
- I have a decent grasp on hypermedia as a concept. Not sure why I should care
- The focus on hypermedia strikes me as dogmatic
- it brings me back to the holy wars of gatekeeping "restfulness"
- or the battle to strictly adhere to semantic web
- Nooo, style classes can't be used in markup! that's what selectors are for and I'll literally die on this hill
- In the middle of the restful holy wars at least everyone could agree allowing clients to query data was insanity. Insanity i say!
- ok maybe graphql makes a little sense
- The htmx value prop seems to be scattered
- people who value "hypermedia"
- devs who have "javascript fatigue"
- based on sentiment I've seen users tend to be the latter
- As far as the tech itself (again quick first impression)
- i feel like the "api" is somewhat over-abstracted
- seems like much of the functionality would be a jquery one-liner but with the syntactic sugar of using html
- this pattern taken to the extreme reminds me of coldfusion markup and I don't mean that disparagingly!
- jquery is popular bc the api strikes a great balance between over/under abstraction
- syntactic sugar, effective primitives, plugins for the rest
- to contrast htmx seems to emphasize high-level functionality
On the ideological grounds of "semantic web" having logic and tags sprinkled thru the UI feels questionable and challenging from a unit testing perspective.
- Given a code sample with the exact same syntax what benefit is there to template/interpolate on the server vs the client side? The downsides seem pretty big. Strings with "X time ago" become stale. More network round trips. Interpolated data has to be parsed to be queried locally, but I guess you could add another network request. Given the typical react/SSR setup I don't even have to think about server vs client side and benefit from both worlds. Anyways sorry for the ramble - I'll be following!
I know this is tangential but I was trying to decide what I wanted to use to make an app that could be accessed from android, ios, and desktop in a convenient way. I am not a fan of how churny the js world is, and I come from a background in Swing/Qt/GTK/etc desktop development.
I evaluated HTMX as a not-js way to do modern web apps. It was fine, it was certainly interesting. I had some concern about how much pain I would be in for when I inevitably wanted to borrow something from the js ecosystem, like a charting library or something.
I actually ended up deciding on godot with gdscript and while I'm not done yet, I'm having a pretty dang good time. I'm a little annoyed that I have to pay apple to get it on iOS, but I have to pay apple anyway because safari is such an annoying odd one out from how firefox and chrome's renderers work. It's always safari that has weird things it doesn't like, in my experience. And I have hope that either Epic Games or Europe will manage to force Apple to let people sideload apps.
From what I could tell the sweet spot for HTMX would be much more targeted at adding some JS magic to an existing backend server based web app (i.e. Django, Flask, Rails) where the developer primarily is a Python/Ruby, HTML/DOM and database expert and doesn't want to get bogged down into supporting a full fledged frontend like React, Angular, etc. to add some UX flair to their mostly CRUD based app.
Native apps (i.e. iOS, Android, MacOS) purely in HTMX is probably not its sweet spot. Probably Electron (or Godot) would be better.
IMO the killer feature of htmx is quick prototyping. You can have an application really quick, only with some html templates in views. Maybe tailwind too, and you can skip css and js.
Doesn't godot refresh the entire screen at X fps? That would kill battery life, no? Asking cuz I considered this route before but decided against it for battery and app loading time reasons.
Godot does have a low CPU mode that limits screen refreshes until something is interacted with on screen or animated, it's what the actual editor uses. I'm not sure whether it works on web exports though.
godot ticks at that rate, but if you don't transform UI things, they don't get redrawn.
so maybe the framebuffer is switched every frame, but draw calls shouldn't be reissued unless needed.
also, I think it is possible to make it not tick from time updates, but only from input event updates, or maybe an animation actually running. similar to what the editor does.
gotdot's editor itself is built in godot, it has an entire suite of Swing/Qt/etc-feeling components and GUI layout stuff.
A long-standing frustration for me is that I always felt like it was really easy to make a responsive layout with Swing (I know desktop apps don't deal with quite the gamut of weird aspect ratios that websites do, but for the apps I built users typically tiled them and resized them between portrait/landscape and various sizes based on need and if they were actively using them or just passively monitoring them. So a lot of the considerations felt very similar compared to modern web design), whereas in CSS it's such a struggle comparatively (though flexbox and css grid and several other similar things have improved it a lot).
Now that, compared to godot, godot feels a lot more like the productivity/design experience I got out of Swing and friends.
I would be much more comfortable with the Epic Games App Store if they just let me pay to submit my app instead of micropurchase a bunch of loot boxes hoping for a submission crystal.
Woah--I stumbled upon "Hypermedia Systems"[0] from the View Transitions essay linked on this release page. If, like me, you're sympathetic to the htmx philosophy, but not really an expert, it looks like a great read. (And it's beautifully presented, too.)
Seems it was discussed a few months ago[1]; I missed it then.
What's the consensus on using custom HTML attributes such as "hx-post", "hx-trigger" and so on, which are "invalid" according to the spec? I don't mind prepending data- to custom attributes but it's still a minor nuisance.
my hope is that, at some point, the browser developers notice htmx and decide to fold its functionality into HTML itself, which is where most of this stuff belongs
Readit News
I discuss it in an essay here:
https://htmx.org/essays/view-transitions/
Chrome's docs on the feature are here:
https://developer.chrome.com/docs/web-platform/view-transiti...
MDN:
https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
will be exciting to see this feature rolled out across the major browsers, as it will make vanilla HTML a lot smoother.
but it's not finalized yet. View the very interesting dashboard here: https://mozilla.github.io/standards-positions/
you have a typo on that page under https://htmx.org/essays/view-transitions/#the-css : @keframes instead of @keyframes
We still had to build an API anyway for external organizations using our product, but you still skip a ton of unnecessary JS code.
0. GalenAI.co
One comment on the UI, on my phone it was not obvious that adding the topic tags was working, because they get added off screen. I was just clicking "ancient-greece" like an idiot for 30 seconds then I accidentally scrolled down and saw what was happening.
One UI note, the layout jumping around when typing or clicking on things is a little jarring. E.g., the "Word is too short" message pushes the field the user is typing in down the page.
I don't see any network requests being sent.
i intentionally introduced an 200ms delay so that you can see things like request indicators:
https://github.com/bigskysoftware/htmx/blob/master/www/stati...
I'm sorry if my question is not sufficiently informed, but how does HTMX not "use JavaScript" to trigger animations?
Have followed the library and approach for a while and tend to compare it to Alpine, which I find a bit more intuitive.
But that's probably exactly because Alpine isn't shy about the fact that you're writing JS in the end.
I found such solutions (Alpine) a grrat joy to start working with (e.g. a complex form with nested fields, custom autocomplete...) and a nightmare to extend or generalize.
The Chrome transition API is very interesting. Also, there certainly is a place for controlling JS via HTML.
But for the risk of sounding inpolite:
Having read a couple of posts by htmx team, the "htmx is hypermedia, SPAs were invented because X and are a crutch" style intro starts to feel a little repetitive and dated to me. Every post starts with a bashing of "SPAs", it gets tiresome very quick. SPAs can be simple, they can be complex nightmares.
So can HTML-centric "sprinkles of JS" that outgrow their purpose.
Also, who are these "cool kids writing SPAs"? It's 2023 and it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.
That's the problem React solves, not just fluffy page transitions.
Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.
> > it's irrelevant if you generate your HTML in PHP, JS, Rust or Python: you need abstraction and modularization for large frontends.
> Yes, it's just that some of us prefer to leverage our existing stack (ie. abstract and modularize with Django/Twig templates) than adding yet another layer to the lasagna. > Nothing against SPA frameworks (ex: we do use Vue/Vuetify for some apps with complex user interface), but there are many cases where it's actually just bloat.
Sure, I agree with you!
What I don't like is the contrarian attitude of htmx team and the pretence of not using JavaScript. It's just progressive enhancement, a valuable and very old approach.
IMO, an approach best implemented without a "framework" like HTMX.
I mentioned Alpine, because I think in combination with blade "components" (which are just fancy template partials), I think it's better than HTMX (subjective opinion). Still, I'd advise against Alpine and for a simple external JS file for anything more serious than an MVP or a landing page.
Kudos to the htmx developers, who made a library out of their idea of progressive-enhancement JS.
My point is just that I don't like two things which seemingly repeat in each of their blog posts:
- They define their own language around REST and hypermedia to explain a string-language in HTML-attributes, which is then executed by JS. It's really not much different from Alpine. It's called "progressive enhancement" and a DSL in HTML attributes is not needed to implement it
- They start most posts about their library with a lengthy ramble about "cool kids and SPAs" vs "good old server-rendered HTML". This is a tiresome trope.
The first time I read their "HATEOAS / Rest is for humans" article, I found it witty. The second time I read an article explaining their appproach, I found it interesting.
By now, I just skip all the htmx stuff and jumped to the meat of the post, the new (JS!) API for page transitions.
I'm not really interested in learning a new "JS-in-HTML"-language.
TL;DR: Have you ever heard of frontend-fatigue-fatigue? :D
I wrote lots of vanilla JS which abused HTML attributes in similar ways.
For a simple landing page, I'll probably try htmx some day instead of writing this myself.
But I tend to not like this whole approach of "magic strings in HTML". When I do this in my own code, the point where an internal alarm rings is usually when HTML attributes start referencing comma-separated lists of unchecked... somethings (usually IDs).
we have never said that SPAs are a crutch, our (really, my, there isn't much of a team and I don't speak for anyone else) claim is that SPAs are as popular as they are for advantages that are not inherent to them when compared to hypermedia, and htmx tries to narrow that gap
i am sympathetic that people reading the various essays on the htmx website might get worn out by my repetitive beating on hypermedia, but consider that for every repeat reader, there are tens or hundreds of new readers who haven't heard much about or thought much about hypermedia. Repetition is a key to teaching, and I teach, so maybe that influences how I write as well.
regarding abstraction and modularization being key to large front ends, I sort of agree to an extent, but I think that at the system level that abstraction can be hypermedia and that the modularization can be done server side
of course it always depends on the app, htmx/hypermedia isn't right for everything, etc. etc. as we try to point out in an essay on our site:
https://htmx.org/essays/when-to-use-hypermedia/
do I get a little punchy about SPAs at times? Sure, it's the internet after all. I've been fighting for the hypermedia-oriented approach for web development for a decade now, and I've been called "old", "irrelavent", "pointless" and "stupid" many times along the way by SPA fans. There is obviously some conflict between my views on web development and the larger front end world's perspective.
But I try to be reasonably balanced about the tradeoffs, even while I think that the SPA approach is dramatically overused today.
First impressions from someone who's had a hand in many large scale consumer centric UI's.
- I have a decent grasp on hypermedia as a concept. Not sure why I should care
- The focus on hypermedia strikes me as dogmatic
- The htmx value prop seems to be scattered - As far as the tech itself (again quick first impression) On the ideological grounds of "semantic web" having logic and tags sprinkled thru the UI feels questionable and challenging from a unit testing perspective.- Given a code sample with the exact same syntax what benefit is there to template/interpolate on the server vs the client side? The downsides seem pretty big. Strings with "X time ago" become stale. More network round trips. Interpolated data has to be parsed to be queried locally, but I guess you could add another network request. Given the typical react/SSR setup I don't even have to think about server vs client side and benefit from both worlds. Anyways sorry for the ramble - I'll be following!
I evaluated HTMX as a not-js way to do modern web apps. It was fine, it was certainly interesting. I had some concern about how much pain I would be in for when I inevitably wanted to borrow something from the js ecosystem, like a charting library or something.
I actually ended up deciding on godot with gdscript and while I'm not done yet, I'm having a pretty dang good time. I'm a little annoyed that I have to pay apple to get it on iOS, but I have to pay apple anyway because safari is such an annoying odd one out from how firefox and chrome's renderers work. It's always safari that has weird things it doesn't like, in my experience. And I have hope that either Epic Games or Europe will manage to force Apple to let people sideload apps.
Native apps (i.e. iOS, Android, MacOS) purely in HTMX is probably not its sweet spot. Probably Electron (or Godot) would be better.
https://hyperview.org/
which is discussed in depth in our book:
https://hypermedia.systems/book/hyperview-a-mobile-hypermedi...
also, I think it is possible to make it not tick from time updates, but only from input event updates, or maybe an animation actually running. similar to what the editor does.
A long-standing frustration for me is that I always felt like it was really easy to make a responsive layout with Swing (I know desktop apps don't deal with quite the gamut of weird aspect ratios that websites do, but for the apps I built users typically tiled them and resized them between portrait/landscape and various sizes based on need and if they were actively using them or just passively monitoring them. So a lot of the considerations felt very similar compared to modern web design), whereas in CSS it's such a struggle comparatively (though flexbox and css grid and several other similar things have improved it a lot).
Now that, compared to godot, godot feels a lot more like the productivity/design experience I got out of Swing and friends.
Asking because of my limited knowledge. If you happen to have a blog post or something on that, would be helpful.
Seems it was discussed a few months ago[1]; I missed it then.
[0]: https://hypermedia.systems/
[1]: https://news.ycombinator.com/item?id=34134545
> It’s worth mentioning that, if you prefer, you can use the data- prefix when using htmx:
> <a data-hx-post="/click">Click Me!</a>
I only ask because I kind of wish such a thing existed.
I still can’t find a happy medium between no JS and “browser as an entire OS”.