5 ms·

I work mainly on the back end but do need to do front end stuff from time to time. Having had my eye on Htmx for quite a while, and having recently gone through

I work mainly on the back end but do need to do front end stuff from time to time. Having had my eye on Htmx for quite a while, and having recently gone through a painfully breaking NextJS update, I’m seriously considering going all in on it. From people who have made the switch: any regrets? Any sharp edges? Can I still use all my Tailwind components without issue?

hruk 3y ago
I've used HTMX quite frequently recently for internal frontends (admin pages, reporting, etc.). It's quite good. A pattern I've been using a lot is not changing the backend at all - each endpoint still returns the full page. Each hypermedia control makes liberal use of hx-select and hx-select-oob to update the elements that may have changed. This isn't super efficient, but it provides some "locality of behavior" in that you can look at a hypermedia control and know what other elements might be changed by it. It also means the backend doesn't really need to "know" about HTMX.
- whartung 3y ago
  Nice way to incrementally add capabilities to an existing app. Back in the day, with Java JSP, there was a tag library called DisplayTag, which handled tables. It did a similar thing for in place paging, albeit a bit more brute force. All JSP pages are buffered as they’re rendered. When the tag was rendered in “Ajax” mode, at the start of the tag it simply flushed the buffer, thus eliminating anything generated before, and at the end it simply aborted the remainder of the page. This effectively just returned the entire table element in isolation from the rest of the page. It was a clever mechanic at the time.
- nprateem 3y ago
  That actually sounds OK. The lede seems buried in the docs, which focus on how it works not how to do what you want to do.
jiggawatts 3y ago
I toyed around with it, but ended up using server-side rendered interactive Blazor. That’s pretty much the same concept as HTMX, but has a larger ecosystem and more flexibility in some ways.
- naasking 3y ago
  Blazor is more brittle.
  - jiggawatts 3y ago
    Yes, that is a concern, but I found that the .NET 8 version seems surprisingly robust with a decent fall-back experience.
JodieBenitez 3y ago
HTMX gets all the hype right now, but there are other tools in the same vein, my favorite being Unpoly (https://unpoly.com https://unpoly.com). Together with Shoelace (https://shoelace.style https://shoelace.style) you get nice GUIs real fast, without the burden of complicated dependency management and build steps. Also, you don't have to write a lot of JS, just what is needed for small enhancements, as it was meant to be. Some might say the main drawback is the tight coupling to your backend. In my case, this is also the main benefit as it integrates perfectly with the backend framework (Django).
- snthpy 3y ago
  Thanks for this. I was going to ask how Shoelace compares to Lit but I see it's built on top of it.
- AltruisticGapHN 3y ago
  There’s WebAwesome now too by the devs of FontAwesome.
- everybodyknows 3y ago
  Shoelace seems to subset the functionality of HTML5. There's https://shoelace.style/components/option https://shoelace.style/components/option but I did not find a wrapper for <optgroup>.
brabel 3y ago
I've used HTMX to create an internal app for us to manage Pull Requests from multiple repositories in a single page. It works great, after you get used to how it expects things to work. Basically, think like every HTML element can be a little "form" which you can submit and replace its contents with the returned HTML. In the server it's not hard to get it to work, I implemented it using Kotlin's KTor (but any server technology that lets you generate HTML would work). I still needed a very minimal amount of JS to do some things that I found annoying to do with HTMX (e.g. in-page filtering), but once I accepted that's ok, it's been working very well.
CJefferson 3y ago
One thing which worries me is GitHub issues (including mine, it’s just a doc issue) don’t seem to be getting much feedback, not sure how big the dev team is. I’m still using htmx, and enjoying it, just raising a concern as you asked.
- recursivedoubts 3y ago
  early spring is always the worst time for me because i'm in the thick of a hard semester (in spring i teach compilers), i'm helping getting youth baseball rolling, i have to get taxes worked out, etc. once june rolls around i can dedicate a lot more time to htmx good news is that most issues are fairly obscure: the htmx codebase isn't too complicated i posted a walk through of the important parts of the code here: https://www.youtube.com/watch?v=javGxN-h9VQ https://www.youtube.com/watch?v=javGxN-h9VQ 2.0 (coming soon) works pretty much the same way
  - CJefferson 3y ago
    I understand those exact issues, I'm also an academic, and sometimes the github issues and PRs on my projects build up -- and nothing I've released is near the popularity of htmx! I can understand not wanting too big a dev team, as bloat and extra features is bad in many projects, but would really hurt htmx, when the aim is to be minimal.
simonbarker87 3y ago
I use it for our internal app that staff use and it’s brilliant. The sharp edge is probably getting your head back round server side rendering if you’ve been in SPA land for a long time. I use Tailwind with out a problem, I don’t use components - assuming they are JSX components you’ll just need to investigate a server side way to turn that JSX component into html so that when the client receives it htmx can insert it into the dom and bind everything … I think? Best bet is to head over to the htmx Discord as they are very helpful in there. The thing I like the most is loading tabular data. With react you need to paginate way earlier than just a plain old html table, browsers are really fast at just displaying a tonne of html. If you do need to paginate then htmx supports infinite scroll with about 20 characters of code!
pjs_ 3y ago
We use it for a fairly chaotic internal CRUD tool together with Flask and Postgres. Basically there's stuff on my big computer, and it needs to get onto some other guys' small computers. Sometimes the small computers need just a little bit of stuff from the big computer, or they want to tell the big computer something. If you put HTMX on the small computers, they can talk to the big computer and ask for bits of stuff whenever they want. And my nice big computer can do all the thinking, and I can tell it how to think, and the small computers aren't expected to think much, they just do what the guys say mostly. This is great, and to me much better than the alternative which is that in addition to having to make the big computer think straight, I also have to install fucking npm on my own computer so that for every single feature I can write a turing-complete piece of thinking sludge which then goes onto hundreds of the other guys' small computers and tries to think for itself and breaks. Now I've got a big computer thinking, a hundred small computers thinking, and all these dumb guys thinking too. And I'm trying to think about what they all might be thinking and how that all interacts, fucking nightmare. HTMX means that only the big computer is going to do any serious thinking, and the small computer only has HTMX, so it's too dumb to think. And so when I am thinking about the computers, I don't have to imagine what two computers might be thinking - only one. Did you know that if you want to run a program in the terminal on your own computer, in order to make programs for other guys small computers, you should say "npx" not "node"? Even though they both execute code? If you don't know this innately, a priori, unfortunately you are the programmer equivalent of a stray dog or sewer-dwelling rodent. Oh and did you know that it's important to learn "type script"? Ah yes just what a language (or languages) made out of warm toffee needs, homotopy type theory. It will be so awesome when my IDE can render a little intellisense hint thing of the compound "List of List of Errors" type I just invented and finally I won't need to understand what the computer is thinking but can still commit a shit load of formally self-consistent code to prod. Statements dreamed up by the utterly deranged. Anyway HTMX is very good in my opinion. One pjs_ Top Tip is that you can write less code if you make your server-side endpoints either return the full template or a partial component depending on the whether the HX-Request HTTP header is present or not - saves writing two different endpoints for the full page vs partials.
- lioeters 3y ago
  > turing-complete piece of thinking sludge Don't let the new-born AI sentience hear this, them's fighting words. But it does illustrate the kind of power that JavaScript gives. The language and especially its ecosystem is a jungle of abstractions and complications, hard to control and easy to break. That includes React and Next.js, speaking as someone who is still deep in that world. > put HTMX on the small computers, they can talk to the big computer and ask for bits of stuff whenever they want. And my nice big computer can do all the thinking That's a nice way to describe it. HTMX is re-thinking the problem space from the ground up, starting with HTML. That's a lot simpler to reason about, directly working with the user interface as it is rendered in the browser. How that HTML is dynamically generated is left up to the server, the actual "thinking" part. > "type script"? Ah yes just what a language..made out of warm toffee needs, homotopy type theory TypeScript is brilliant though, it's the best thing that could have happened to JavaScript. For what it had to work with as a starting point, it builds on that foundation a language that's more sane and reliable. With a type system that's at least better than before - implicit/invisible types or none at all. And the language server that enables intellisense, it's an ingenious way to empower the code editor - I use it heavily and can't imagine programming without it now. > make your server-side endpoints either return the full template or a partial component depending on the whether the HX-Request HTTP header is present Good to know! I'm still learning how to use HTMX, especially on the server side. It's a different way of thinking than an API with JSON.
SJC_Hacker 3y ago
I played with HTMX for a bit. Its pretty cool and basically an easy way abstract away fetch() and swapping innerHTML. You can even send custom headers along with the request (important for 'Authorization' headers) You can also trigger behavior after the fetch by sending an 'HX-Trigger'. So on the surface, does seem your one-stop shop for all things client-server interaction. There may come a point howecer, where you hit a brick wall with HTMX. Frameworks were created for a reason, and it wassn't just the fact that fetch() and setting innerHTML were too verbose (those can be easily abstracted away) Then you're back in framework land. And can be hard to make those two place nice with each other. React, particularly, doesn't like you messing around with innerHTML.

hruk 3y ago

I've used HTMX quite frequently recently for internal frontends (admin pages, reporting, etc.). It's quite good. A pattern I've been using a lot is not changing the backend at all - each endpoint still returns the full page. Each hypermedia control makes liberal use of hx-select and hx-select-oob to update the elements that may have changed. This isn't super efficient, but it provides some "locality of behavior" in that you can look at a hypermedia control and know what other elements might be changed by it. It also means the backend doesn't really need to "know" about HTMX.

whartung 3y ago
Nice way to incrementally add capabilities to an existing app. Back in the day, with Java JSP, there was a tag library called DisplayTag, which handled tables. It did a similar thing for in place paging, albeit a bit more brute force. All JSP pages are buffered as they’re rendered. When the tag was rendered in “Ajax” mode, at the start of the tag it simply flushed the buffer, thus eliminating anything generated before, and at the end it simply aborted the remainder of the page. This effectively just returned the entire table element in isolation from the rest of the page. It was a clever mechanic at the time.
nprateem 3y ago
That actually sounds OK. The lede seems buried in the docs, which focus on how it works not how to do what you want to do.

jiggawatts 3y ago

I toyed around with it, but ended up using server-side rendered interactive Blazor. That’s pretty much the same concept as HTMX, but has a larger ecosystem and more flexibility in some ways.

naasking 3y ago
Blazor is more brittle.
- jiggawatts 3y ago
  Yes, that is a concern, but I found that the .NET 8 version seems surprisingly robust with a decent fall-back experience.

JodieBenitez 3y ago

HTMX gets all the hype right now, but there are other tools in the same vein, my favorite being Unpoly (https://unpoly.com https://unpoly.com). Together with Shoelace (https://shoelace.style https://shoelace.style) you get nice GUIs real fast, without the burden of complicated dependency management and build steps. Also, you don't have to write a lot of JS, just what is needed for small enhancements, as it was meant to be. Some might say the main drawback is the tight coupling to your backend. In my case, this is also the main benefit as it integrates perfectly with the backend framework (Django).

snthpy 3y ago
Thanks for this. I was going to ask how Shoelace compares to Lit but I see it's built on top of it.
AltruisticGapHN 3y ago
There’s WebAwesome now too by the devs of FontAwesome.
everybodyknows 3y ago
Shoelace seems to subset the functionality of HTML5. There's https://shoelace.style/components/option https://shoelace.style/components/option but I did not find a wrapper for <optgroup>.

brabel 3y ago

I've used HTMX to create an internal app for us to manage Pull Requests from multiple repositories in a single page. It works great, after you get used to how it expects things to work. Basically, think like every HTML element can be a little "form" which you can submit and replace its contents with the returned HTML. In the server it's not hard to get it to work, I implemented it using Kotlin's KTor (but any server technology that lets you generate HTML would work). I still needed a very minimal amount of JS to do some things that I found annoying to do with HTMX (e.g. in-page filtering), but once I accepted that's ok, it's been working very well.

CJefferson 3y ago

One thing which worries me is GitHub issues (including mine, it’s just a doc issue) don’t seem to be getting much feedback, not sure how big the dev team is. I’m still using htmx, and enjoying it, just raising a concern as you asked.

recursivedoubts 3y ago
early spring is always the worst time for me because i'm in the thick of a hard semester (in spring i teach compilers), i'm helping getting youth baseball rolling, i have to get taxes worked out, etc. once june rolls around i can dedicate a lot more time to htmx good news is that most issues are fairly obscure: the htmx codebase isn't too complicated i posted a walk through of the important parts of the code here: https://www.youtube.com/watch?v=javGxN-h9VQ https://www.youtube.com/watch?v=javGxN-h9VQ 2.0 (coming soon) works pretty much the same way
- CJefferson 3y ago
  I understand those exact issues, I'm also an academic, and sometimes the github issues and PRs on my projects build up -- and nothing I've released is near the popularity of htmx! I can understand not wanting too big a dev team, as bloat and extra features is bad in many projects, but would really hurt htmx, when the aim is to be minimal.

simonbarker87 3y ago

I use it for our internal app that staff use and it’s brilliant. The sharp edge is probably getting your head back round server side rendering if you’ve been in SPA land for a long time. I use Tailwind with out a problem, I don’t use components - assuming they are JSX components you’ll just need to investigate a server side way to turn that JSX component into html so that when the client receives it htmx can insert it into the dom and bind everything … I think? Best bet is to head over to the htmx Discord as they are very helpful in there. The thing I like the most is loading tabular data. With react you need to paginate way earlier than just a plain old html table, browsers are really fast at just displaying a tonne of html. If you do need to paginate then htmx supports infinite scroll with about 20 characters of code!

pjs_ 3y ago

We use it for a fairly chaotic internal CRUD tool together with Flask and Postgres. Basically there's stuff on my big computer, and it needs to get onto some other guys' small computers. Sometimes the small computers need just a little bit of stuff from the big computer, or they want to tell the big computer something. If you put HTMX on the small computers, they can talk to the big computer and ask for bits of stuff whenever they want. And my nice big computer can do all the thinking, and I can tell it how to think, and the small computers aren't expected to think much, they just do what the guys say mostly. This is great, and to me much better than the alternative which is that in addition to having to make the big computer think straight, I also have to install fucking npm on my own computer so that for every single feature I can write a turing-complete piece of thinking sludge which then goes onto hundreds of the other guys' small computers and tries to think for itself and breaks. Now I've got a big computer thinking, a hundred small computers thinking, and all these dumb guys thinking too. And I'm trying to think about what they all might be thinking and how that all interacts, fucking nightmare. HTMX means that only the big computer is going to do any serious thinking, and the small computer only has HTMX, so it's too dumb to think. And so when I am thinking about the computers, I don't have to imagine what two computers might be thinking - only one. Did you know that if you want to run a program in the terminal on your own computer, in order to make programs for other guys small computers, you should say "npx" not "node"? Even though they both execute code? If you don't know this innately, a priori, unfortunately you are the programmer equivalent of a stray dog or sewer-dwelling rodent. Oh and did you know that it's important to learn "type script"? Ah yes just what a language (or languages) made out of warm toffee needs, homotopy type theory. It will be so awesome when my IDE can render a little intellisense hint thing of the compound "List of List of Errors" type I just invented and finally I won't need to understand what the computer is thinking but can still commit a shit load of formally self-consistent code to prod. Statements dreamed up by the utterly deranged. Anyway HTMX is very good in my opinion. One pjs_ Top Tip is that you can write less code if you make your server-side endpoints either return the full template or a partial component depending on the whether the HX-Request HTTP header is present or not - saves writing two different endpoints for the full page vs partials.

lioeters 3y ago
> turing-complete piece of thinking sludge Don't let the new-born AI sentience hear this, them's fighting words. But it does illustrate the kind of power that JavaScript gives. The language and especially its ecosystem is a jungle of abstractions and complications, hard to control and easy to break. That includes React and Next.js, speaking as someone who is still deep in that world. > put HTMX on the small computers, they can talk to the big computer and ask for bits of stuff whenever they want. And my nice big computer can do all the thinking That's a nice way to describe it. HTMX is re-thinking the problem space from the ground up, starting with HTML. That's a lot simpler to reason about, directly working with the user interface as it is rendered in the browser. How that HTML is dynamically generated is left up to the server, the actual "thinking" part. > "type script"? Ah yes just what a language..made out of warm toffee needs, homotopy type theory TypeScript is brilliant though, it's the best thing that could have happened to JavaScript. For what it had to work with as a starting point, it builds on that foundation a language that's more sane and reliable. With a type system that's at least better than before - implicit/invisible types or none at all. And the language server that enables intellisense, it's an ingenious way to empower the code editor - I use it heavily and can't imagine programming without it now. > make your server-side endpoints either return the full template or a partial component depending on the whether the HX-Request HTTP header is present Good to know! I'm still learning how to use HTMX, especially on the server side. It's a different way of thinking than an API with JSON.

SJC_Hacker 3y ago

I played with HTMX for a bit. Its pretty cool and basically an easy way abstract away fetch() and swapping innerHTML. You can even send custom headers along with the request (important for 'Authorization' headers) You can also trigger behavior after the fetch by sending an 'HX-Trigger'. So on the surface, does seem your one-stop shop for all things client-server interaction. There may come a point howecer, where you hit a brick wall with HTMX. Frameworks were created for a reason, and it wassn't just the fact that fetch() and setting innerHTML were too verbose (those can be easily abstracted away) Then you're back in framework land. And can be hard to make those two place nice with each other. React, particularly, doesn't like you messing around with innerHTML.