6 ms·

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in

by wqtz 3y ago

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I understand that it is just a simple framework and it addresses an industry-related issue, but migration is a lot of effort. Does HTMX really provide enough value to justify the engineering investment required?

shouldcode 3y ago
You might want to check out https://hypermedia.gallery https://hypermedia.gallery Disclosure: I built it (without HTMX).
mr90210 3y ago
For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere. I totally get your sentiment.
- jonathanberger 3y ago
  By “sit on” do you mean “keep using” or “avoid”?
  - mr90210 3y ago
    Keep using… Apologies for the lack of accuracy.
ysleepy 3y ago
The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path. There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment. It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.
stavros 3y ago
I don't know if HTMX is an alternative to React/Vue/etc, it always struck me as an alternative to a purely HTML site, which I think 95% of web apps should be. I don't know what we get from avoiding full page loads that we don't then lose when we make sites janky and taking ages to load.
- dinkumthinkum 3y ago
  Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).
  - stavros 3y ago
    I don't know if you've computed in 96, but computing now is orders of magnitude more frustrating than then.
    - dinkumthinkum 3y ago
      Yeah … that’s why I put the “86” in the parenthetical but I think it’s worse then 1986 too. I worry about it getting more orders of magnitude worse!
  - hirvi74 3y ago
    I've mainly been a full stack dev for most of my career, though I do have a some experience in low-level domains. Lately, I have been mulling over if I want to jump into different field of development. I know Rust is gaining traction, and I have always found languages like assembly, C/C++ to be more enjoyable than the higher level languages. So, I might try and take a stab at Rust and see where it can take me. I'm just so fatigued from all the web dev stuff. The whole field feels too scatter-brained to me. Instead of trying to solve useful problems, I feel like much of web dev's frameworks are just focused solving an already solved problem with slightly differing and dogmatic opinions.
mlhpdx 3y ago
I’ve been using HTMX on a greenfield project (not reimplementing something) and I’ve found it easy to work with and effective. Nothing magical, but simpler. Less effort, not more. After being reminded of the importance of supporting low-spec clients[1] I’ve been testing without the HTMX library loading as well, and mostly that works like it should. I say mostly because I didn’t get the markup right everywhere yet. I can see why some wouldn’t like it. But, it’s not a good/bad or works/doesn’t thing - it’s just different. [1] https://danluu.com/slow-device/ https://danluu.com/slow-device/ Edit: typo, HTML -> HTMX
merpnderp 3y ago
Isn’t this really just going back to the server side templating days and using jquery to load html snippets?
- ForHackernews 3y ago
  Yes, it's an implementation of the radical idea that we should deliver HTML (rather than a giant blob of JS) to clients purpose-built for rendering HTML. See also https://hotwired.dev/ https://hotwired.dev/
- mejutoco 3y ago
  But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.
- lebean 3y ago
  Yes it's that, but more. I enjoy the out-of-bound swaps and triggering hx events or specific targets of render via response headers.
- andybak 3y ago
  The problem was that on the whole people didn't use jQuery to "load html snippets" and the architecture of jQuery tended to push people towards client-side spaghetti. htmx encourages you to put most of the logic on the server and to keep the client lean and clean.
ledgerdev 3y ago
I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.
- tomcam 3y ago
  Super balanced & informative writeup, thank you. Can you tell me what you mean by tab sleep restoration?
  - ledgerdev 3y ago
    Last year chrome started discarding background tabs to save memory, probably should have said discard rather then sleep it's been a while since I worked on that. Our user base keeps tabs in background often in mobile devices and we saw some reports of it. https://arstechnica.com/gadgets/2023/02/chrome-110-will-automatically-discard-background-tabs-heres-how-to-stop-it/ https://arstechnica.com/gadgets/2023/02/chrome-110-will-auto... When you do an htmx navigation to a new page, a discarded tab will "restore" only the last htmx fragment loaded, not the entire html page with style tags. Fix is to use unique url on push that isn't in local cache which forces a server reload on tab wake from discard.
    - wmanley 3y ago
      Try adding the response header: Vary: HX-Request
blopker 3y ago
I'm using HTMX with Django for totem.org[0]. My over all experience is good. I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast. The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?). Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller? [0]: https://github.com/totem-technologies/totem-server https://github.com/totem-technologies/totem-server
- jwells89 3y ago
  > The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-swap, hx-swap-oob, hx-target?). Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?
  - blopker 3y ago
    Maybe. I think it's just a high-level library for a specialized domain. It's not like imperatively coding JavaScript, spelling out each action step-by-step. The fact that I just need a little of it to do a lot means I just don't need to use it that much, and then I forget how. I could see a better tutorial experience with live examples for common patterns. Something like SolidJS does (https://www.solidjs.com/tutorial/introduction_basics https://www.solidjs.com/tutorial/introduction_basics). That would be a good reference. Alternatively, a copy/paste pattern library, like what a lot of people are doing with Tailwind (https://daisyui.com/components/ https://daisyui.com/components/).
- 3y ago
andybak 3y ago
This feels like the wrong way to look at things. It's not that it's "difficult" to switch from React/Vue to htmx - it's that it's easier to build with htmx in the first place. I wouldn't throw out completed code, but I'd seriously consider using it next time you start something new. The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.
mamcx 3y ago
Htmx is what you want for making websites. This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if you are serving HTML, then htmx. When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop). (and in short amounts like creating complex widgets like maps, selects, etc). --- I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side. For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.
- leptons 3y ago
  Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260 https://github.com/bigskysoftware/htmx/issues/2260
  - pfraze 3y ago
    I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server
  - Terretta 3y ago
    Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.
    - leptons 3y ago
      That sounds like an irrational fear of front-end.
    - 3y ago
hendi_ 3y ago
We use htmx (mostly via our django-livecomponents) on our production website, for several public facing features. We've initially replaced numerous small things that were built with Alpine before, and once we've gained confidence we rewrote our whole messaging app from reason/react app. Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching. Give htmx a try, it's worth a shot!
- halfcat 3y ago
  > django-livecomponents Sounds cool. This one? https://github.com/om-proptech/livecomponents https://github.com/om-proptech/livecomponents
  - hendi_ 3y ago
    Yes :)
thom 3y ago
It depends on your options for managing state. If you can build a largely stateless UI, that can update from the server via a form submission or query parameters, then it’s a big win, both in terms of your code complexity and the complexity of the team you need to build it. You can still have lots of widgets on your page and even fancy CSS transitions to make it feel like an SPA if you really want. But if you’re making something very highly interactive or canvas based, with complex stateful UI components and gestures, then you probably have nothing to gain. Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure. All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.
sibit 3y ago
I help maintain a user-facing ASP.NET project running .NET Framework 4.5 that uses jQuery 1.0 for most of the UI. We launched our first new feature using HTMX back in November and it worked out pretty well for us and we plan to continue using it moving forward. I also work on a React site and I wouldn't want to move away from it unless someone dared to utter the word rewrite.
rougemine 3y ago
It’s possible to build quite dynamic user interfaces with htmx - even games :-) —> https://zakuchess.com/ https://zakuchess.com/ One benefit I found to it is that it allows developers to keep the business logic entirely on the backed side, without having to duplicate any effort on the frontend side.

by wqtz 3y ago

shouldcode 3y ago

You might want to check out https://hypermedia.gallery https://hypermedia.gallery Disclosure: I built it (without HTMX).

mr90210 3y ago

For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere. I totally get your sentiment.

jonathanberger 3y ago
By “sit on” do you mean “keep using” or “avoid”?
- mr90210 3y ago
  Keep using… Apologies for the lack of accuracy.

ysleepy 3y ago

The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path. There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment. It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.

stavros 3y ago

I don't know if HTMX is an alternative to React/Vue/etc, it always struck me as an alternative to a purely HTML site, which I think 95% of web apps should be. I don't know what we get from avoiding full page loads that we don't then lose when we make sites janky and taking ages to load.

dinkumthinkum 3y ago
Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).
- stavros 3y ago
  I don't know if you've computed in 96, but computing now is orders of magnitude more frustrating than then.
  - dinkumthinkum 3y ago
    Yeah … that’s why I put the “86” in the parenthetical but I think it’s worse then 1986 too. I worry about it getting more orders of magnitude worse!
- hirvi74 3y ago
  I've mainly been a full stack dev for most of my career, though I do have a some experience in low-level domains. Lately, I have been mulling over if I want to jump into different field of development. I know Rust is gaining traction, and I have always found languages like assembly, C/C++ to be more enjoyable than the higher level languages. So, I might try and take a stab at Rust and see where it can take me. I'm just so fatigued from all the web dev stuff. The whole field feels too scatter-brained to me. Instead of trying to solve useful problems, I feel like much of web dev's frameworks are just focused solving an already solved problem with slightly differing and dogmatic opinions.

mlhpdx 3y ago

I’ve been using HTMX on a greenfield project (not reimplementing something) and I’ve found it easy to work with and effective. Nothing magical, but simpler. Less effort, not more. After being reminded of the importance of supporting low-spec clients[1] I’ve been testing without the HTMX library loading as well, and mostly that works like it should. I say mostly because I didn’t get the markup right everywhere yet. I can see why some wouldn’t like it. But, it’s not a good/bad or works/doesn’t thing - it’s just different. [1] https://danluu.com/slow-device/ https://danluu.com/slow-device/ Edit: typo, HTML -> HTMX

merpnderp 3y ago

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

ForHackernews 3y ago
Yes, it's an implementation of the radical idea that we should deliver HTML (rather than a giant blob of JS) to clients purpose-built for rendering HTML. See also https://hotwired.dev/ https://hotwired.dev/
mejutoco 3y ago
But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.
lebean 3y ago
Yes it's that, but more. I enjoy the out-of-bound swaps and triggering hx events or specific targets of render via response headers.
andybak 3y ago
The problem was that on the whole people didn't use jQuery to "load html snippets" and the architecture of jQuery tended to push people towards client-side spaghetti. htmx encourages you to put most of the logic on the server and to keep the client lean and clean.

ledgerdev 3y ago

I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setting up loading indicators, error display, keeping step/form state on browser history back/forward, tab sleep restoration after htmx navigation(especially tricky), and injection of third party form elements that had to be injected/remove and re-injected on back/forward between steps. I would be surprised if these sorts of edge cases weren't already handled by a popular js-frameworks but can't say for sure. The site load is very fast and we haven't even rolled out client side js validation on forms the server validation responds so fast. We are planning to use more htmx across other apps at present, so overall positive hypermedia for the win.

tomcam 3y ago
Super balanced & informative writeup, thank you. Can you tell me what you mean by tab sleep restoration?
- ledgerdev 3y ago
  Last year chrome started discarding background tabs to save memory, probably should have said discard rather then sleep it's been a while since I worked on that. Our user base keeps tabs in background often in mobile devices and we saw some reports of it. https://arstechnica.com/gadgets/2023/02/chrome-110-will-automatically-discard-background-tabs-heres-how-to-stop-it/ https://arstechnica.com/gadgets/2023/02/chrome-110-will-auto... When you do an htmx navigation to a new page, a discarded tab will "restore" only the last htmx fragment loaded, not the entire html page with style tags. Fix is to use unique url on push that isn't in local cache which forces a server reload on tab wake from discard.
  - wmanley 3y ago
    Try adding the response header: Vary: HX-Request

blopker 3y ago

I'm using HTMX with Django for totem.org[0]. My over all experience is good. I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependencies change. I just don't write many JS tests because stuff changes so fast. The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-select, hx-swap, hx-swap-oob, hx-target?). Aside from that, it's also a pretty large dependency. I'm also using Solidjs to mount web components (which is a pattern I love) and HTMX is a majority of the JS bundle. That was surprising to me. Maybe version 2 will be smaller? [0]: https://github.com/totem-technologies/totem-server https://github.com/totem-technologies/totem-server

jwells89 3y ago
> The main downside I have with it though, is I just can't seem to remember how to use it. Every time I need HTMX I have to look at code I've written or go to the docs. There's just too many options with names that are confusing (hx-swap, hx-swap-oob, hx-target?). Perhaps this could be smoothed over with snippets or an autocomplete extension for whichever text editor is being used?
- blopker 3y ago
  Maybe. I think it's just a high-level library for a specialized domain. It's not like imperatively coding JavaScript, spelling out each action step-by-step. The fact that I just need a little of it to do a lot means I just don't need to use it that much, and then I forget how. I could see a better tutorial experience with live examples for common patterns. Something like SolidJS does (https://www.solidjs.com/tutorial/introduction_basics https://www.solidjs.com/tutorial/introduction_basics). That would be a good reference. Alternatively, a copy/paste pattern library, like what a lot of people are doing with Tailwind (https://daisyui.com/components/ https://daisyui.com/components/).
3y ago

andybak 3y ago

This feels like the wrong way to look at things. It's not that it's "difficult" to switch from React/Vue to htmx - it's that it's easier to build with htmx in the first place. I wouldn't throw out completed code, but I'd seriously consider using it next time you start something new. The general philosophy is that "React etc are great for some things, but they are being used way outside of their sweet spots". There will always be a gray area - and your existing habits and skills are also a factor but for some of us - the "SPA framework" approach always smelt fishy for typical web builds.

mamcx 3y ago

Htmx is what you want for making websites. This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if you are serving HTML, then htmx. When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop). (and in short amounts like creating complex widgets like maps, selects, etc). --- I work for eCommerce, and there is terrible to use React: It is too easy to make "hacker-friendly" websites when using it: INSTEAD, you MUST validate, format, process, render, and display all on the server side. For me, I retain all the logic on Rust, display HTML, and just put some extra interactivity with htmx, that because at the server-side is the same as without, means I CAN'T INTRODUCE A SECUIRITY BUG.

leptons 3y ago
Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260 https://github.com/bigskysoftware/htmx/issues/2260
- pfraze 3y ago
  I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server
- Terretta 3y ago
  Actual hackers, the ones who try to hack your e-commerce site. For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.
  - leptons 3y ago
    That sounds like an irrational fear of front-end.
  - 3y ago

hendi_ 3y ago

We use htmx (mostly via our django-livecomponents) on our production website, for several public facing features. We've initially replaced numerous small things that were built with Alpine before, and once we've gained confidence we rewrote our whole messaging app from reason/react app. Fun thing, customers find the new version (htmx/django-livecomponents) to be more responsive than the old version (react+REST). New version is less lines of code and easier to hack on die to fewer context switching. Give htmx a try, it's worth a shot!

halfcat 3y ago
> django-livecomponents Sounds cool. This one? https://github.com/om-proptech/livecomponents https://github.com/om-proptech/livecomponents
- hendi_ 3y ago
  Yes :)

thom 3y ago

It depends on your options for managing state. If you can build a largely stateless UI, that can update from the server via a form submission or query parameters, then it’s a big win, both in terms of your code complexity and the complexity of the team you need to build it. You can still have lots of widgets on your page and even fancy CSS transitions to make it feel like an SPA if you really want. But if you’re making something very highly interactive or canvas based, with complex stateful UI components and gestures, then you probably have nothing to gain. Anywhere I could conceivably get away with HTMX over React I would (and tbh I’d launch with no JavaScript at all before that). But if you’ve got a massive React codebase then you’re already in quite deep, both codebase and team structure. All that said, some really high level apps are moving to WASM anyway, so I don’t know that an investment in React is safe for the long term.

sibit 3y ago

I help maintain a user-facing ASP.NET project running .NET Framework 4.5 that uses jQuery 1.0 for most of the UI. We launched our first new feature using HTMX back in November and it worked out pretty well for us and we plan to continue using it moving forward. I also work on a React site and I wouldn't want to move away from it unless someone dared to utter the word rewrite.

rougemine 3y ago

It’s possible to build quite dynamic user interfaces with htmx - even games :-) —> https://zakuchess.com/ https://zakuchess.com/ One benefit I found to it is that it allows developers to keep the business logic entirely on the backed side, without having to duplicate any effort on the frontend side.